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.
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.
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.
Keep us updated, Personally I am very passionate about graphics creations in general!
Scawen, you can also explore one of the rising open source engine if you are curious or in need ideas from other approaches, the code is open source so you can explore or integrate some parts of it as you see fit.
Thanks for the updates Scawen! Always an interesting read.
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).
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).