The online racing simulator
October Progress Report
(394 posts, closed, started , go to first unread)
Skawen, about the taillights. The most realistic option in my opinion is to make a HDR cubemap inside the rear light in the on mode, on the map of which the spot from the lamps will be clear, and make the glass transparent, multiply it by the color of the texture.
In other cases, the reflector will be chrome plated.
The only question is how to get HDR-cubecmap ...
In the interests of explaining how development goes...

Warning, totally technical and not interesting for most people!

Most of the day was on restructuring the generated sky system a bit and removing some old code that is no longer needed so that yesterday's test has now become proper code to stay instead of being rapidly hacked in for test purposes. Although generating the sky on the GPU instead of the CPU, which is much faster, there was still a quite perceptible glitch long enough to cause a click in the sound each time a new sky was generated - that can be about once every 20 seconds around sunset / sunrise. The click was in my debug version of LFS and might not have happened in the release build but it's best to make it glitch free in the debug version, then it's sure to be OK in the release build, and also won't annoy me all the time while developing. Smile

The glitch turned out to be because I started a new thread to generate the sky each time. A 'CPU sky' still needs to be generated for reasons related to lighting (in addition to the GPU sky) but now the CPU sky can be much smaller in size because it is not for direct display. Still, it's good to use a separate thread to do it to make use of our multiple core CPUs. The solution to the glitch was to have a sky generation thread running the whole time, just waiting for the command from the weather system to generate a new sky texture when required. It turns out that starting and stopping threads is quite expensive in debug builds.

Quote from Scawen :There are still some bright pixels around I can look into but they aren't causing random blooms.

While testing the updated sky I was driving around South City at sunset and started looking into the remaining white pixels, now that the worst offenders were cured by bounding the fog exponential. I applied the _centroid interpolation modifier to various inputs to the pixel shader until I located the one that was causing the white pixels. It turned out to be the ambient lighting data from artificial lights. Now I can drive around South City or visit those camera locations at Blackwood without seeing any bright pixels at all.

So, a good day's work, though not the sort of thing that sounds very exciting to most people.
Quote from Scawen :So, a good day's work, though not the sort of thing that sounds very exciting to most people.

Thanks for sharing this with us, it's always nice to read about these "behind-the-scenes" processes Smile
Indeed Thumbs up . It will be brilliant and clearly properly done as usual Big grin . Good luck and continue !
this is for me very exciting info, but then again, I'm programmer... Smile (and much less racer)
Thanks.
I'm not a programmer or a racer Big grin, but still I found it very interesting.
Quote from MandulAA :Thanks for sharing this with us, it's always nice to read about these "behind-the-scenes" processes Smile

Agree so much Smile

Always nice to know any progress or problems etc.

BTW Scawen u not only one talking to comunity as programmer Wink But I must say I don't know many Smile
Quote from Scawen :So, a good day's work, though not the sort of thing that sounds very exciting to most people.

Keep it up and inform us now and then Wink
Always like to read stuff "even when I don't understand all Wink"
Scawen forget about the forum just get an update out Thumbs up
Quote from Scawen :In the interests of explaining how development goes...

Warning, totally technical and not interesting for most people!

Most of the day was on restructuring the generated sky system a bit and removing some old code that is no longer needed so that yesterday's test has now become proper code to stay instead of being rapidly hacked in for test purposes. Although generating the sky on the GPU instead of the CPU, which is much faster, there was still a quite perceptible glitch long enough to cause a click in the sound each time a new sky was generated - that can be about once every 20 seconds around sunset / sunrise. The click was in my debug version of LFS and might not have happened in the release build but it's best to make it glitch free in the debug version, then it's sure to be OK in the release build, and also won't annoy me all the time while developing. Smile

The glitch turned out to be because I started a new thread to generate the sky each time. A 'CPU sky' still needs to be generated for reasons related to lighting (in addition to the GPU sky) but now the CPU sky can be much smaller in size because it is not for direct display. Still, it's good to use a separate thread to do it to make use of our multiple core CPUs. The solution to the glitch was to have a sky generation thread running the whole time, just waiting for the command from the weather system to generate a new sky texture when required. It turns out that starting and stopping threads is quite expensive in debug builds.



While testing the updated sky I was driving around South City at sunset and started looking into the remaining white pixels, now that the worst offenders were cured by bounding the fog exponential. I applied the _centroid interpolation modifier to various inputs to the pixel shader until I located the one that was causing the white pixels. It turned out to be the ambient lighting data from artificial lights. Now I can drive around South City or visit those camera locations at Blackwood without seeing any bright pixels at all.

So, a good day's work, though not the sort of thing that sounds very exciting to most people.

More exciting than you can believe Big grin It is moving along nicely. looks great
Thanks for the development update. I really enjoy reading about the development on the programming side Smile

What's the use of the "CPU generated sky" ? Is it used to generate the ambient Spherical Harmonic or something like that ? Can't you reuse the GPU skybox, downsample it and upload it back to CPU ?
Quote from nacim :What's the use of the "CPU generated sky" ? Is it used to generate the ambient Spherical Harmonic or something like that ? Can't you reuse the GPU skybox, downsample it and upload it back to CPU ?

Yes, the CPU sky is for:
- ambient lighting spherical harmonic (for directional ambient lighting)
- maximum brightness value (needed before the GPU sky is generated - see below)
- average sky colour (I'm trying to move away from any uses of this)

The GPU sky can still be stored as a 32-bit SRGB texture, doesn't need to be 64-bit HDR if I know the maximum value (from the CPU) before it is generated on the GPU. Each pixel is then multiplied by (1.0 / max_brightness) so the sky uses the full 24-bit range of colours.

I'd sometimes like to be able to generate things on the GPU and read the texture back into system memory for analysis by the program, and I do this, not in realtime, in a few places:
- baked ambient and artificial lighting render
- path-based echo map
- path-based ambient lighting render for cars (called 'lightmap' in LFS)
- path-based occlusion test (called 'optimiser' in LFS)
- calculating average colours from textures

But as far as I know, reading back the texture from GPU to CPU will always cause a small glitch or hesitation, because the CPU must stop and wait, when it calls GetRenderTargetData, until the GPU is ready to send the data. I'm not sure if this is the case with later versions of DirectX - I think later versions are better for getting data back from the GPU because of compute shaders and so on. But I think this is a limitation with DX9 so I've avoided using that in real time situations. Anyway the CPU sky at 64x64 only takes 3 milliseconds in the debug build, and as it's on that separate thread there is no glitch at all, so I think it's quite good now. The lighting system judges that the sun has moved enough to need a new sky, asks the CPU sky thread to make a new sky, then when the CPU sky is generated a few ms later, the main thread tells the GPU to generate the new sky (seems to take no time at all).
i hope you make it awesome in the final result scavier. again thank you for taking many ideas i and others had up in all this development. i really wish you good wind as we say in my country with it all.
i left you a pm.
regards wiz.

Quote from Evolution_R :Please don't stop communicating. I think it is better and far more interesting to know what is being worked on, some of the problems and their solutions. Smile

i agree. this is the way @scawen Smile
Open source doesn't mean you can just take code and use it an a closed source environment... (In this case you can because it's MIT licensed)
Quote from PeterN :Open source doesn't mean you can just take code and use it an a closed source environment... (In this case you can because it's MIT licensed)

Depend on the type of license as you said, tbh open source projects ( I use Blender ) are great for learning/research purpose, for those who are into soft developments.
Gpu and cpu optimization, multithreading. It sounds great.
Thanks for the updates Scawen! Always an interesting read.

Quote from Evolution_R :BeamNG: Color Space, Lighting and HDR Rendering

I still think the new graphics of Live for Speed looks better.

The devs from BeamNG are doing an awesome job as well. Their blogs are quite interesting to read, and that game is so much fun. But sorry, both the old and new graphics from BeamNG look better than LFS. Looking at the pictures and videos from the BeamNG update they have stepped it up for sure. The night mode from LFS might look better though, but can't really tell because I compare the video with some nice crisp stills from Scawen. The shadows really look weird, and the way objects suddenly get lit because of the headlights really looks weird (look at those big pillars that support a road above).
Quote from Scawen :So, a good day's work, though not the sort of thing that sounds very exciting to most people.

the work of this 'most people' themselves is not interesting. Good to read that something is being done on multi-thread/multi core level.
Quote from simon1234 :Scawen forget about the forum just get an update out Thumbs up

That is not how it works in real life. Sometimes explaining whats going on can lead to new insights or some new/other idea. Communication is pretty important.
Quote from cargame.nl :That is not how it works in real life. Sometimes explaining whats going on can lead to new insights or some new/other idea. Communication is pretty important.

That's very true. I'm sure Scawen is familiar with Rubber duck debugging Razz.
Hello,
after the redesign of the tracks have you planned a redesign of the cars?

thank you Smile
Quote from Nanex :after the redesign of the tracks have you planned a redesign of the cars?

Current patch is about new shadowing system (and maybe tires physics).

The new shadows require fixes of every track models, to have correct rendering of shadows without some kind of glitches/blinking/wrong-look/etc...

But the old car models render OK-ish with the new system. They look outdated, but they decided to not delay this patch by couple of years to update also the cars (as they already work as is), so they limited the patch to update "only" tracks.

So "no" (in this patch).

(if you are asking about future... well... can you imagine not updating the current cars if they are trying to create "best online car racing simulator"? As long as they are developing LFS, it's just question of time and priorities, but at some point either cars will be updated, or mod-tools will be released. The only other option is, that the development will stop before one of those happens).
I like how the bloom works with highlights.
Attached images
bloom_fz_highlight.jpg
It looks amazing! Heart
I hope these white 'edgy' pixels are easy to resolve -
This thread is closed

October Progress Report
(394 posts, closed, started )
FGED GREDG RDFGDR GSFDG