Yeah I though of this too, I think adding a SSAO (Call of Duty's GTAO for example) to the renderer would really improve the image in shadows, vertex ambient occlusion is ok for large scale AO, but can't grab the fine details.
But I think Scawen has enough things to worry about for this release not to worry about that for now, it can easily be added later on.
The big thing that is weird on the screenshot to me is the light leak under the roof of the entrance
But I think Scawen has enough things to worry about for this release not to worry about that for now, it can easily be added later on.
The big thing that is weird on the screenshot to me is the light leak under the roof of the entrance
Speaking of mirrors, @Scawen, how do you handle shadows for mirrors and environement maps ?
If I'm seeing correctly, for mirrors, you are rendering another cascade (maybe using a bounding frustum of the 3 mirrors in order render shadows 1 time instead of 3) with a max distance of around 250m. This is nice, considering a lot of game just don't render shadow maps in secondary renders (environement maps, mirrors).
For environement map I can't see much in the current screenshots and videos
Looking at the Steam hardware survey, for what its worth, DX10 GPU and less account for only 2.9% of all users. FL 11.0 is available in virtually every PC nowadays. The only "big" GPUs that I could think that are DX 10.0 / 10.1 are the GT 2xx series, released in 2008.
Last edited by nacim, .
Wow, I'm really impressed by the ammount of work put into South City, good job !
@Scawen: You moved histogram generation on the GPU, that's nice to see, and looking at the settings that you got to tweak it, I feel like we saw similar papers for it.
Did you had to move to feature level 11 for it or did you found a way to make it work in feature level 10.0 ?
Clouds can be a really long task, and really rewarding, but yeah, I'm sure that when you'll get nice clouds rendered you'll have a hard time containing yourself not to implement rain weather and simulation, so I suggest you get the tire physics ready first
Is it even possible to finish a graphics engine ? As a graphics programmer myself, I sincerly doubt it
@Scawen: You moved histogram generation on the GPU, that's nice to see, and looking at the settings that you got to tweak it, I feel like we saw similar papers for it.
Did you had to move to feature level 11 for it or did you found a way to make it work in feature level 10.0 ?
Clouds can be a really long task, and really rewarding, but yeah, I'm sure that when you'll get nice clouds rendered you'll have a hard time containing yourself not to implement rain weather and simulation, so I suggest you get the tire physics ready first
Is it even possible to finish a graphics engine ? As a graphics programmer myself, I sincerly doubt it
Thanks for the update Scawen, glad to see it still going strong
I have some questions though:
- Why don't you generate the auto-exposure histogram on the GPU ? It's a highly parallelisable operation, so perfect for the GPU, and would remove the need to transfer data back a framebuffer to the CPU. IRC you need it for the atmospheric sky on the CPU, so you'll have only a small struct containing the final exposure to send back.
- Do you have a system to have physical light units in your engine ? Like tweaking spot light by setting it to be a 100W LED at 5000K for example. Coupling physical lights units with physical camera settings (aperture, shutter speed, etc) really add another dimension to the lighting, and creating a coherent HDR range between sun light zone (at 90/100k lumens) and the dark parking (see attachements).
For your fallback ambient solution, it actually really common, we also use the last mip of specular IBL to fake the diffuse lighting on cars, and it really does the job nicely when you don't have light probes available.
I have some questions though:
- Why don't you generate the auto-exposure histogram on the GPU ? It's a highly parallelisable operation, so perfect for the GPU, and would remove the need to transfer data back a framebuffer to the CPU. IRC you need it for the atmospheric sky on the CPU, so you'll have only a small struct containing the final exposure to send back.
- Do you have a system to have physical light units in your engine ? Like tweaking spot light by setting it to be a 100W LED at 5000K for example. Coupling physical lights units with physical camera settings (aperture, shutter speed, etc) really add another dimension to the lighting, and creating a coherent HDR range between sun light zone (at 90/100k lumens) and the dark parking (see attachements).
For your fallback ambient solution, it actually really common, we also use the last mip of specular IBL to fake the diffuse lighting on cars, and it really does the job nicely when you don't have light probes available.
Last edited by nacim, .
Nor upgrading your computer ?
"RTX" is just NVIDIA's marketing name of the hardware capable of raytracing and compatible with DirectX Raytracing (DXR). I think xmlenoa simply meant ray tracing effect (or even path tracing in LFS).
I admit that it would be awesome, but that's way too far for the targeted hardware by Scawen (DX10 capable GPU, at best it would DX11).
Using DX12 feature level 11 (so compatible on a DX11 GPU) would be doable, and using FL 12.0 (to enable raytracing) could be feasable, but that would require dropping support for Windows 7, 8 and 8.1.
Hello Scawen, thanks for the heads up. Sadly I won't be able to try it as the 32:9 screen is at my workplace and I work from home due to the current situation.
Well, you don't even need to pass the result back to the CPU if the only thing using it is the tonemapper post process. You can store the result of the histogram compute in a RWStructuredBuffer and read it directly in the tonemapper's pixel shader (or even compute shader, which is a more optimised way to compute post process too, especially for things like downsampling using parallel reduction (here or here)
Well, I think it is doable, to see what compute shader features are allowed on DX10 hardware and to what extent, I suggest you check out this link
Compute shaders in D3D10 can be limiting, but if you are willing to put the time to make your shaders work on it I think you could do some nice things, but in my opinion I don't think it is worth spending time supporting GPU that are more than 12 years old now.
If you find yourself stuck corner for a new feature, I think it would't be unreasonable to either drop support of DX10/10.1 hardware, or disable that feature depending on the feature level.
Yeah, but thinking about it, it can be really hard to implement modern rendering techniques using such an old API, without compute shaders, asynchronous operations, multi-threading capabilities, etc
Scawen, I think you don't worry about minimum GPU requirement implied by the update, I'm pretty sure even the best DX9 compatible GPU couldn't handle the new update anyway, so that's a good thing for performance, stability and quality.
Is your new rendering code using command lists? If not, I suggest you really use them from the begining, as it's the only way to record work to submit to the GPU from D3D12 onwards, and to record work from other threads in D3D11, so it will save you some time in the future.
Looking forward for a new GPU based particle system using compute shaders and indirect draw calls, or a tile light clustering system to help with night rendering with a lot of lights
Keep it up !
Indeed it would make a drastic change for the games where you don't want to use the Rift
Thanks, sadly it's not my personal setup but a simrig I built at work (racing game studio, we must have a simrig
). Still, I can go play whenever I wish outside work hours. Well, apexes are sure way easier to see than with a 16:9 or my 21:9, but can still be blocked by the A pillar on some rare occasions. On LFS it's not really a problem, I see this more often on Dirt Rally 2.0.
I attached a quick photo I got from my mate trying to survive with a Group B Lancia Delta S4
I'll try to make some shots with LFS when I can If you really need the maximum visibility in corners, a VR headseat is perfect. Still, we mostly use the screen as LFS act weirdly with our HTC Vive, head movement have ghosting that Assetto Corsa doesn't have. @Scawen do you have any idea on how I can fix this btw ?
It's the Fanatec RennSport Cockpit V2 with the Sparco Pro 2000 seat so no, not a homemade solution
Hello,
I finally had some time to do some testing, and here are the results:
Default:
1 screen left and one center:
1 screen, unequal splits (1280-2560-1280):
I finally had some time to do some testing, and here are the results:
Default:
1 screen left and one center:
1 screen, unequal splits (1280-2560-1280):
Hello Scawen,
Thanks for the insight. If you could add this to a test patch I would gladly try it.
I'll try some setups in a few hours and edit this post.
I have it, it works nicely. By default LFS thinks it's a 2 screen setup, but once you go in the settings and set it to 1 screen it works nicely in race. The menus are a bit squished though
Nice find, thanks, I was wondering if I should do myself a custom build like that recently
And he isn't between his lines, just like in real life
It's because of what I told earlier, car headlights do not cast shadows, so the lights of the car behind are leaking into the interior
It's because of what I told earlier, car headlights do not cast shadows, so the lights of the car behind are leaking into the interior
Thanks for the progress report!
South City looks really nice, so does LFS in HDR mode. Cars looks stunning too with the new HDR reflections
I'm really happy that you decided to add the bloom now, I think it really starts to give the rendering a softer looks.
I hope to see headlights shadows to remove headlights going through the interio of the car in front like here:
South City looks really nice, so does LFS in HDR mode. Cars looks stunning too with the new HDR reflections
I'm really happy that you decided to add the bloom now, I think it really starts to give the rendering a softer looks.
I hope to see headlights shadows to remove headlights going through the interio of the car in front like here:
Good way to improve memory bandwith
Yep, but you can read data from the GPU asynchronously with DX11. And you also don't have compute shader or HLSL 5.0 so you'll be really limited for path tracing anyways
Sorry for the late reply
Thanks for the development update. I really enjoy reading about the development on the programming side
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 ?
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 ?
TIL about centroid sampling. Thanks Rejekt for the link
Now I'm satisfied that we know the real cause of the issue
Btw thanks for the effort to reproduce it on the public build Scawen.
I really miss that feature on my MX-5
Now I'm satisfied that we know the real cause of the issue
Btw thanks for the effort to reproduce it on the public build Scawen.
I really miss that feature on my MX-5
Last edited by nacim, .
My pleasure really
Glad to see that you fixed the problem, though now I'm wondering what's the cause for this depth value that goes above 1 on MSAA samples
You forgot to turn anisotropic filtering back on
The floodlights looks really stunning though. Do you have a system for the dynamic lighting on cars right now ? To have them light up properly by thoses floodlights
I hope when cars will be updated that they'll have physical gauges with backlighting at night
Interesting. I would try to normalize the vertex normal in the pixel shader first, and check for holes in the geometry also. If your pixel shader just returns a uniform color, do you still have the problem ?
FGED GREDG RDFGDR GSFDG