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).
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).
They are not very easy to resolve. Antialiasing doesn't work very well in HDR when very bright pixels are next to dark pixels. Because when the GPU takes the average of the bright and dark samples, the result is still 'very bright'. The effect is also noticeable in some of the night pictures, where there seems to be no antialiasing on the edges of the street light lens.
EDIT: Actually this doesn't seem to be the same issue. This is more about reflections on edges and I guess you can see it in the public version too (maybe less so as you don't have such bright patches on environment maps). Anyway I don't think it's that noticeable, maybe worse if you are examining a screenshot.
I like the effect of bloom in the day when there are occasional bloom effects when you see the sun reflected in the window of a building, and when the sun itself is seen, flickering in and out of brightness behind some trees. I've found it looks best when moving rather than in screenshots.