Confused about the rendering pipeline DCS uses. Forward vs Deferred?

[112th_Rossi]

So sometime ago, ED introduced deferred rendering, which allows for more effecient application of lighting across the scene. This allows lighting to be calculated on the final render rather than waste cycles calculating lighting for geometry that has been occluded by objects that are rendered further along in the pipeline.

 

Forward rendering -> Good performance as you render everything in one pass. Pixel shader executed once per pixel plotted; lots of overdraw and heavy pixel shaders kill you.

 

Deferred rendering -> Only once have the impact of having lots of geometry as you render all of it just once. Also reduce the impact of heavy pixel shaders as you render each screen pixel once, overdraw no longer being relevant for the heavyness of your pixel shader

 

So I am confused. Does DCS switch to forward rendering in VR (as recommended) or does it remain using deferred rendering which is not advised?

 

Also MSAA (Multi-Sample AA) is NOT compatible with deferred rendering. So if deferred is the default, why is MSAA still an option in graphics settings? Could we get some clarification?

 

And if post processing such as bloom and ambient occulusion are going to be applied how is this going to be approached for the recommended forward rendering pipeline that VR should use?

 

Or it could be the case that deferred has been quietly abandoned?

[SkateZilla]

IIRC The Current DX11 Engine uses Deferred.

 

ED would have to Confirm.

[twistking]

So sometime ago, ED introduced deferred rendering, which allows for more effecient application of lighting across the scene. This allows lighting to be calculated on the final render rather than waste cycles calculating lighting for geometry that has been occluded by objects that are rendered further along in the pipeline.

 

Forward rendering -> Good performance as you render everything in one pass. Pixel shader executed once per pixel plotted; lots of overdraw and heavy pixel shaders kill you.

 

Deferred rendering -> Only once have the impact of having lots of geometry as you render all of it just once. Also reduce the impact of heavy pixel shaders as you render each screen pixel once, overdraw no longer being relevant for the heavyness of your pixel shader

 

So I am confused. Does DCS switch to forward rendering in VR (as recommended) or does it remain using deferred rendering which is not advised?

 

Also MSAA (Multi-Sample AA) is NOT compatible with deferred rendering. So if deferred is the default, why is MSAA still an option in graphics settings? Could we get some clarification?

 

And if post processing such as bloom and ambient occulusion are going to be applied how is this going to be approached for the recommended forward rendering pipeline that VR should use?

 

Or it could be the case that deferred has been quietly abandoned?

 

 

everything that has been officially stated is that dcs post 1.5 runs in deferred shading for both VR and desktop. you would spot a difference in lighting etc. if vr would use a different pipeline.

however, you've got a point with the MSAA. it should indeed not be possible. my guess is, that it is simply something else (maybe SSAA?), but that they did not bother to change the label...

[112th_Rossi]

everything that has been officially stated is that dcs post 1.5 runs in deferred shading for both VR and desktop. you would spot a difference in lighting etc. if vr would use a different pipeline.

however, you've got a point with the MSAA. it should indeed not be possible. my guess is, that it is simply something else (maybe SSAA?), but that they did not bother to change the label...

 

Then there must be performance issues with VR because of the deferred set up. Performing lighting caculations twice (once per eye) must be taxing as well as doing the same for post processing effects

[twistking]

Then there must be performance issues with VR because of the deferred set up. Performing lighting caculations twice (once per eye) must be taxing as well as doing the same for post processing effects

 

it surely is more taxing, yes and you can see that if you compare desktop to vr performance. it is roughly (!) in line with what i would expect.

since dcs is quite often cpu/ram limited it somewhat gets away with deferred for VR, but it is maybe not ideal.

 

the thing that i don't understand is, that they have not yet managed to really make use of the strengths of deferred shading with always only having one pixel light (?) in the scene at all times (moon / sun). when they eventually finish the lighting overhaul (WIP since version 2.0 or something) the benefits of deferred will show more and it will be very difficult to argue for going back to forward rendering - even for VR...

Edited September 3, 2020 by twistking

[twistking]

it's an interesting point you raise by the way. we really know nothing about the engine that runs dcs and that makes it harder to understand performance bottlenecks etc.

 

it would be very helpful to maybe get an interview with one of the engine programmers in the newsletter to get a bit more technical insight about how things work right now and how they are supposed to work in the future...

[112th_Rossi]

it surely is more taxing, yes and you can see that if you compare desktop to vr performance. it is roughly (!) in line with what i would expect.

since dcs is quite often cpu/ram limited it somewhat gets away with deferred for VR, but it is maybe not ideal.

 

the thing that i don't understand is, that they have not yet managed to really make use of the strengths of deferred shading with always only having one pixel light (?) in the scene at all times (moon / sun). when they eventually finish the lighting overhaul (WIP since version 2.0 or something) the benefits of deferred will show more and it will be very difficult to argue for going back to forward rendering - even for VR...

 

Yes in deferred lighting you can have as many lights as you want since it works on the pixels using the depth information from the render buffer. We should have amazing lighting but we don't. We still have baked airfield lighting.

 

Deferreds advantages start to disappear the higher resolution you go though as it has to calculate for more pixels.

[Eldur]

I guess that's where single pass stereo would be nice to have...

[twistking]

I guess that's where single pass stereo would be nice to have...

 

i think there is a command-line that activates an experimental single pass culling for VR. I think it does not work correctly at the moment, but it would be a step in that direction. I'm not sure if single pass culling is not even the same as single pass stereo. Maybe you could also do shadows in a single pass, but everything else would probably need a second pass for the scene to be physically correct, or do i get this wrong?

Edited September 3, 2020 by twistking

[Taz1004]

I could be wrong but it is my suspicion that DCS uses Temporal AA rather than MSAA. Which often referred to as MSAA because part of it uses MSAA. It is more taxing but versatile.

[Mustang]

DepthMSAA.hlsl is used in Bazar\shaders\deferred

[M1Combat]

So they must be using more than one light source???

 

Watch the 2019 and beyond vid (or maybe 2018 and beyond??) and there are ground based missiles that generate their own light as they fire... Illuminating the ground. Or I don't understand the subject which is quite possible :).

[twistking]

So they must be using more than one light source???

 

Watch the 2019 and beyond vid (or maybe 2018 and beyond??) and there are ground based missiles that generate their own light as they fire... Illuminating the ground. Or I don't understand the subject which is quite possible :).

 

different type of lights. where deferred shading "shines" is pixel lights (though i'm not sure that this is the correct term technically), a.k.a. light sources that can cast shadows and can interact with pbr shaders correctly etc.

 

There are other ways of representing a light source in computer graphics, but those are simpler, less flexible perhaps, but most importantly they can be done on deferred pipelines and forward rendering pipelines with similar cost, i think.

 

again, i'm not a programmer, so my terminology might not be spot on, but i think the concept described should be more or less correct :smilewink:

[stormrider]

it's an interesting point you raise by the way. we really know nothing about the engine that runs dcs and that makes it harder to understand performance bottlenecks etc.

 

it would be very helpful to maybe get an interview with one of the engine programmers in the newsletter to get a bit more technical insight about how things work right now and how they are supposed to work in the future...

 

 

Looking at the comments in the game' system files, most of those programmers apparently already quit ED long time ago and had not documented their code properly. :music_whistling:

[stormrider]

i think there is a command-line that activates an experimental single pass culling for VR. I think it does not work correctly at the moment, but it would be a step in that direction. I'm not sure if single pass culling is not even the same as single pass stereo. Maybe you could also do shadows in a single pass, but everything else would probably need a second pass for the scene to be physically correct, or do i get this wrong?

 

 

options.graphics.stereo_mode_use_shared_parser = true

 

 

It does seem to better performance a little, but for some reason, when the TGP feed is on in the MFD, the performance starts crawling.

[BIGNEWY]

options.graphics.stereo_mode_use_shared_parser = true

 

 

It does seem to better performance a little, but for some reason, when the TGP feed is on in the MFD, the performance starts crawling.

 

 

stereo_mode_use_shared_parser is W.I.P and not ready for public use, there will be side effects.

[twistking]

options.graphics.stereo_mode_use_shared_parser = true

 

It does seem to better performance a little, but for some reason, when the TGP feed is on in the MFD, the performance starts crawling.

 

that's what i meant. thanks for the info!

 

stereo_mode_use_shared_parser is W.I.P and not ready for public use, there will be side effects.

 

roger that. just have it ready when i make the jump to vr fnally;) can you clarify if this is indeed one-pass-stereo, or something in that direction?

Edited September 4, 2020 by twistking

[BIGNEWY]

that's what i meant. thanks for the info!

 

 

 

roger that. just have it ready when i make the jump to vr fnally;) can you clarify if this is indeed one-pass-stereo, or something in that direction?

 

 

Yes that is my understanding of it.

 

thanks

[SkateZilla]

Also note, MSAA works with Deferred Shading, but Deferred Shading + MSAA has a Performance Penalty. Which is why other engines use Deferred Shading + FXAA or other AA Methods.

 

For Me, I get better Performance w/ MSAA off and just brute forcing a 4K Oversample in AMD's drivers.

[Raven (Elysian Angel)]

Also note, MSAA works with Deferred Shading, but Deferred Shading + MSAA has a Performance Penalty. Which is why other engines use Deferred Shading + FXAA or other AA Methods.

 

For Me, I get better Performance w/ MSAA off and just brute forcing a 4K Oversample in AMD's drivers.

Yes, but in VR you get insane shimmering (especially around cities) without MSAA, which basically makes turning that ON a *must*.

[BIGNEWY]

Yes, but in VR you get insane shimmering (especially around cities) without MSAA, which basically makes turning that ON a *must*.

 

It can be distracting for sure, personal preference for me is to have MSAA off and I live with a little shimmering. Probably not as bad on a higher res display, making it more bearable.

[FoxTwo]

As others have stated, MSAA is absolutely compatible with deferred rendering. It just has a horrendous penalty compared to forward + msaa, or other AA solutions.

 

https://docs.nvidia.com/gameworks/content/gameworkslibrary/graphicssamples/d3d_samples/antialiaseddeferredrendering.htm