Deferred Shading
by Andrew Mac · in Torque 3D Professional · 06/22/2014 (9:38 am) · 116 replies
About 2 weeks ago Azaezel, Timmy and myself set out to bring Physical Based Shading to Torque. One of the biggest hurdles we ran into is the lighting information we need is not available at the stages we need it. This is due to Torque's prepass lighting (aka deferred lighting).
How does deferred lighting work?
Everything is rendered twice. Once to calculate lighting, and then everything is rendered again + the previously obtained lighting information for your final lit scene. This is why a 30k poly model loaded into Torque will show 60k.
This may sound very expensive but it's made in a way that the light prepass is as cheap as possible. It's by no means a bad method of doing things, nor was it a poor choice at the time. In fact, most engines around that time frame used deferred lighting. It also has the advantage of running better on older hardware.
How does deferred shading work?
Everything is rendered once, but it's done in a rather clever way. When rendering, a pixel shader is used to write all the data needed to different buffers. One for depth/normals, one for lighting (specular info, etc), and one for color. Then at the end a shader is used to combine all the information from the different buffers into a final picture.
This reduces rendering to once, but puts more stress on the graphics card and uses more video memory. This was not necessarily considered the better choice until recent years when graphics hardware has gotten better.
Why make the switch?
I hate to say "because the other guys are doing it" but if you look into it the big players that were using deferred lighting have made the change to deferred shading ( see: UE4 ). This will allow us to easily implement different lighting models like cook-torrance.
It also has the advantage of allowing some additional shaders and postfx that we couldn't really do before. Take for instance Lukas' SSGI shader. One big issue he ran into is the lack of an available albedo (or color) buffer to read just color data from. This is available with deferred shading.
What's the status?
We've been working on the conversion for about a week now and everything seems to be working quite well. There's a few missing features, and a handful of broken things but it's functional and working. Performance is about the same as before, which we consider to be a good thing since we haven't attempted any kind of optimization yet.
Conclusion
It's a pretty big change and will have a huge impact on materials, material shaders, and lighting. While we plan to continue working on this regardless for personal use, we would like to know if this is something the community is interested seeing make it's way into the main repo. This wouldn't be a 3.6 or 3.7 change, but further down the line (perhaps 4.0?).
Links
Link to the development repo:
github.com/andr3wmac/Torque3D/tree/deferred_shading
A guy's benchmarking of deferred lighting vs shading:
frictionalgames.blogspot.ca/2010/10/pre-pass-lighting-redux.html
An article that evaluates Deferred Lighting VS Deferred Shading:
gameangst.com/?p=141
How does deferred lighting work?
Everything is rendered twice. Once to calculate lighting, and then everything is rendered again + the previously obtained lighting information for your final lit scene. This is why a 30k poly model loaded into Torque will show 60k.
This may sound very expensive but it's made in a way that the light prepass is as cheap as possible. It's by no means a bad method of doing things, nor was it a poor choice at the time. In fact, most engines around that time frame used deferred lighting. It also has the advantage of running better on older hardware.
How does deferred shading work?
Everything is rendered once, but it's done in a rather clever way. When rendering, a pixel shader is used to write all the data needed to different buffers. One for depth/normals, one for lighting (specular info, etc), and one for color. Then at the end a shader is used to combine all the information from the different buffers into a final picture.
This reduces rendering to once, but puts more stress on the graphics card and uses more video memory. This was not necessarily considered the better choice until recent years when graphics hardware has gotten better.
Why make the switch?
I hate to say "because the other guys are doing it" but if you look into it the big players that were using deferred lighting have made the change to deferred shading ( see: UE4 ). This will allow us to easily implement different lighting models like cook-torrance.
It also has the advantage of allowing some additional shaders and postfx that we couldn't really do before. Take for instance Lukas' SSGI shader. One big issue he ran into is the lack of an available albedo (or color) buffer to read just color data from. This is available with deferred shading.
What's the status?
We've been working on the conversion for about a week now and everything seems to be working quite well. There's a few missing features, and a handful of broken things but it's functional and working. Performance is about the same as before, which we consider to be a good thing since we haven't attempted any kind of optimization yet.
Conclusion
It's a pretty big change and will have a huge impact on materials, material shaders, and lighting. While we plan to continue working on this regardless for personal use, we would like to know if this is something the community is interested seeing make it's way into the main repo. This wouldn't be a 3.6 or 3.7 change, but further down the line (perhaps 4.0?).
Links
Link to the development repo:
github.com/andr3wmac/Torque3D/tree/deferred_shading
A guy's benchmarking of deferred lighting vs shading:
frictionalgames.blogspot.ca/2010/10/pre-pass-lighting-redux.html
An article that evaluates Deferred Lighting VS Deferred Shading:
gameangst.com/?p=141
About the author
#102
With Andrewmac's focus on other things, working branch is presently in github.com/Azaezel/Torque3D/tree/Deferred_Shading2 based on devhead as of 20Aug2014 to ensure it can be pulled once folks sign off on it (Though given the scope of potential side-effects. the preference would be similar to the consolerefactor branch so we can absolutely ensure no side-effects are left.). At time of writing, unaware of any new bugs unadressed.
Relevant changelog since last status update:
>Cut off terrain culling during the prepass to allow reflections to have some data to work with.
>Cubemaps now support mips.
>Translucency entry of the 3rd render target for the gbuffer given a fallback scenario to ensure materials properly generate under all combinations.
>Passthrough resolution bumped up from 8.8.8.8 to 16.16.16.16f (corrects that banding we were getting from lighting under extreme conditions.)
>Last bit of the linear correction mark 2 work completed (for directx), including
>>A) clamping the brightness and contrast sliders to reasonable values (strictly gui entries there, so folks are free to decide on a wider range),
>>B) exposing those same values to the HDR postfx chain.
>Basicclouds corrected similar to other sky-based objects, so that they no longer draw in front of other things in-scene.
>Scattersky sun output clamped in the percentile range to prevent banding.
>Diffuse texture blending and muti-layer support corrected.
>Removed the last traces of the MFT_Imposter code that was use for the linear rev 1.0 code in order to ensure they weren't being linearized twice.
>Glossmap banding cleanup.
>GammaP.hlsl cleaned up and conformed to close to parity for the HDR postfx chain output brightness wise.
>Material feature triggers shifted within prepass so that they aren't being flipped on for dedicated servers unnecessarily.
>GuiObjectview was given access to the postfx output. (Needed it to render period. Also ensures it matches gamma-corrected outputs when used in-game.) On the wishlist in that regard would be filtering the background back to translucent for that and the object-editor.
>Given that was the last of the list anyone has reported, in order to ensure compatibility with the opengl port (or at least put in as much conversion as possible to make Luis's life a little easier) Tim Newell and I went ahead and began the porting process. Most of the results of which you'll find github.com/Azaezel/Torque3D/tree/DS_OGL.
TODO for opengl porting:
>Review the implications of github.com/BeamNG/Torque3D/commit/e8614f28f6872f175f627e23ea1465a62e140e18 on github.com/Azaezel/Torque3D/commit/e8c7f61633d5b515a3fd5b0294a5d3b67048ecc8#diff... and try to find a workaround.
>Review cubemap miplevel code.
>Review terrain with more than 4 texture layers corrupting.
>Review near objects such as groundcover and forrests with alpha generating black squares with the HDR postfx chain flipped on.
09/24/2014 (8:30 am)
Status Update:With Andrewmac's focus on other things, working branch is presently in github.com/Azaezel/Torque3D/tree/Deferred_Shading2 based on devhead as of 20Aug2014 to ensure it can be pulled once folks sign off on it (Though given the scope of potential side-effects. the preference would be similar to the consolerefactor branch so we can absolutely ensure no side-effects are left.). At time of writing, unaware of any new bugs unadressed.
Relevant changelog since last status update:
>Cut off terrain culling during the prepass to allow reflections to have some data to work with.
>Cubemaps now support mips.
>Translucency entry of the 3rd render target for the gbuffer given a fallback scenario to ensure materials properly generate under all combinations.
>Passthrough resolution bumped up from 8.8.8.8 to 16.16.16.16f (corrects that banding we were getting from lighting under extreme conditions.)
>Last bit of the linear correction mark 2 work completed (for directx), including
>>A) clamping the brightness and contrast sliders to reasonable values (strictly gui entries there, so folks are free to decide on a wider range),
>>B) exposing those same values to the HDR postfx chain.
>Basicclouds corrected similar to other sky-based objects, so that they no longer draw in front of other things in-scene.
>Scattersky sun output clamped in the percentile range to prevent banding.
>Diffuse texture blending and muti-layer support corrected.
>Removed the last traces of the MFT_Imposter code that was use for the linear rev 1.0 code in order to ensure they weren't being linearized twice.
>Glossmap banding cleanup.
>GammaP.hlsl cleaned up and conformed to close to parity for the HDR postfx chain output brightness wise.
>Material feature triggers shifted within prepass so that they aren't being flipped on for dedicated servers unnecessarily.
>GuiObjectview was given access to the postfx output. (Needed it to render period. Also ensures it matches gamma-corrected outputs when used in-game.) On the wishlist in that regard would be filtering the background back to translucent for that and the object-editor.
>Given that was the last of the list anyone has reported, in order to ensure compatibility with the opengl port (or at least put in as much conversion as possible to make Luis's life a little easier) Tim Newell and I went ahead and began the porting process. Most of the results of which you'll find github.com/Azaezel/Torque3D/tree/DS_OGL.
TODO for opengl porting:
>Review the implications of github.com/BeamNG/Torque3D/commit/e8614f28f6872f175f627e23ea1465a62e140e18 on github.com/Azaezel/Torque3D/commit/e8c7f61633d5b515a3fd5b0294a5d3b67048ecc8#diff... and try to find a workaround.
>Review cubemap miplevel code.
>Review terrain with more than 4 texture layers corrupting.
>Review near objects such as groundcover and forrests with alpha generating black squares with the HDR postfx chain flipped on.
#103
09/26/2014 (3:25 am)
what happens with terrains with more than 4 texture layers?
#104
09/26/2014 (9:34 am)
Same flaw as with earlier editions of that 3-blend fix, though only opengl side. Mangled alpha.
#105
Background on that one:
The initial gbuffer layout used specular gloss in material alpha, specular power in material blue, and specular map (greyscaled) in color alpha. This turned out to conflict with the terrain layers blending during multiple passes directx side (due to: enum GFXBlend define list), which in conjunction with the alpha used for blending effectively shut off detail drawing entirely.
So, since we needed to resolve that anyway, removed the specular power storage value, and retooled the gbuffer as follows:
col = ShaderFeature::DefaultTarget = usual nromal/lighting data for deferred shaders. (defaults to normal rendering for things like translucent objects, since those are forward shaded)
col1 = ShaderFeature::RenderTarget1 = color rgb+a for blending routines.
col2 = ShaderFeature::RenderTarget2 = r(material flag storage),g(translucency map), b(specular greyscaled), a(specular power/gloss).
Of the rest of the high-points: Tim Newell found quite a boost from removing texture target recreation when those targets remain unchanged in size or format, so that's now filtered out.
Added opengl debugging colorization by severity:
GL_DEBUG_SEVERITY_HIGH-Con::errorf
GL_DEBUG_SEVERITY_MEDIUM-Con::warnf
GL_DEBUG_SEVERITY_LOW-Con::printf
Should help in tracking whats a real problem, and what can be put in the pure cleanup bin.
Cleaned up a few ImplementFeatureType order of operations errors (the last number determines in what order hlsl/glsl code insertion happens)
removed void DeferredEmptySpecGLSL::processVert. was giving us uv coordinate errors.
courtesy of Tim Newell: specified alpha blend for stateblock support
ARB_explicit_attrib_location is no longer checked against and skiped if it is unfound. We require it.
cleaned up ReflectCubeFeatHLSL::processPix massively.
Hunted down the pixspecular equasion used for the fullscreen pixel specular variant found here whish was derived from here as near as we can tell
Also re-implemented the 3-texture blending fix.
10/02/2014 (6:25 pm)
OK. So. Those following the repo-forking probably noticed a DSL_OGL_Registers and DS_OGL_GbufferRedux fork this week. Large change, so deserves some explanation.Background on that one:
The initial gbuffer layout used specular gloss in material alpha, specular power in material blue, and specular map (greyscaled) in color alpha. This turned out to conflict with the terrain layers blending during multiple passes directx side (due to: enum GFXBlend define list), which in conjunction with the alpha used for blending effectively shut off detail drawing entirely.
So, since we needed to resolve that anyway, removed the specular power storage value, and retooled the gbuffer as follows:
col = ShaderFeature::DefaultTarget = usual nromal/lighting data for deferred shaders. (defaults to normal rendering for things like translucent objects, since those are forward shaded)
col1 = ShaderFeature::RenderTarget1 = color rgb+a for blending routines.
col2 = ShaderFeature::RenderTarget2 = r(material flag storage),g(translucency map), b(specular greyscaled), a(specular power/gloss).
Of the rest of the high-points: Tim Newell found quite a boost from removing texture target recreation when those targets remain unchanged in size or format, so that's now filtered out.
Added opengl debugging colorization by severity:
GL_DEBUG_SEVERITY_HIGH-Con::errorf
GL_DEBUG_SEVERITY_MEDIUM-Con::warnf
GL_DEBUG_SEVERITY_LOW-Con::printf
Should help in tracking whats a real problem, and what can be put in the pure cleanup bin.
Cleaned up a few ImplementFeatureType order of operations errors (the last number determines in what order hlsl/glsl code insertion happens)
removed void DeferredEmptySpecGLSL::processVert. was giving us uv coordinate errors.
courtesy of Tim Newell: specified alpha blend for stateblock support
ARB_explicit_attrib_location is no longer checked against and skiped if it is unfound. We require it.
cleaned up ReflectCubeFeatHLSL::processPix massively.
Hunted down the pixspecular equasion used for the fullscreen pixel specular variant found here whish was derived from here as near as we can tell
Also re-implemented the 3-texture blending fix.
#106
1) Need to decide at this point whether to pursue an opengl specific solution for the sampler state simplification conflicting with the inGammaSpace state, or revert to using hlsl/glsl insertions to ensure data comming into the lighting et al system matches the data required for proper calculations (aka: linear space corrections)
2) need to correct https://github.com/Azaezel/Torque3D/blob/DS_OGL/Engine/source/shaderGen/GLSL/shaderFeatureGLSL.cpp#L1839 specifically to get cubemaps with level of detail functioning properly opengl side (directx side already functions to reduce fidelity based on roughness when used in conjunction with a specular map or slider)
3) need to backport the directx corrections to deferred_shading2 assuming anyone particularly cares for just those fixes in isolation.
Should be all that's left in terms of bugs we've introduced on the opengl end, or deal-breaking flaws on eirther side that would get in the way of moving right along to the PBR end of things.
10/02/2014 (6:36 pm)
Still on the to-do list:1) Need to decide at this point whether to pursue an opengl specific solution for the sampler state simplification conflicting with the inGammaSpace state, or revert to using hlsl/glsl insertions to ensure data comming into the lighting et al system matches the data required for proper calculations (aka: linear space corrections)
2) need to correct https://github.com/Azaezel/Torque3D/blob/DS_OGL/Engine/source/shaderGen/GLSL/shaderFeatureGLSL.cpp#L1839 specifically to get cubemaps with level of detail functioning properly opengl side (directx side already functions to reduce fidelity based on roughness when used in conjunction with a specular map or slider)
3) need to backport the directx corrections to deferred_shading2 assuming anyone particularly cares for just those fixes in isolation.
Should be all that's left in terms of bugs we've introduced on the opengl end, or deal-breaking flaws on eirther side that would get in the way of moving right along to the PBR end of things.
#107
on point 2: still under review. at this point in time, opengl and directx diverge, with the former simply rendering a cubemap blended, and the latter doing the blend and the smear based on roughness/specularpower.
on point 3: preliminary port up.
10/07/2014 (5:20 pm)
on point 1: github.com/Azaezel/Torque3D/commit/3cc762c48505ddfe39acf1a06a63d9d447aadea8 Felt it was more important to have clean parity between the opengl and directx sides of things, so went with shadergen insertions on the ogic that we do expect folks to extend, modify and retool things if they want, so best to make that as painless as possible. Also got around to adding a shutoff for linearization in the form of a TORQUE_STOCK_GAMMA define for backwards compatibility. do note that at time of writing, we do still have a bug specifically with decals with transparancy in opengl where it's colorshifting from black to green.on point 2: still under review. at this point in time, opengl and directx diverge, with the former simply rendering a cubemap blended, and the latter doing the blend and the smear based on roughness/specularpower.
on point 3: preliminary port up.
#108
10/09/2014 (10:23 pm)
Keep up the good work Azaezel!
#109
mean time:
Found and corrected a flaw with rendering #sometargetname tagged render targets on object materials (stand ins for diffuse maps. those with certain extension tech know what I mean there), and corrected the gammaP.hlsl/glsl calcs. (Prior HDR settings threw off the results. Pardon for the confusion there folks.)
10/11/2014 (7:06 am)
Still looking into the two opengl issues. (greenshift on decals with transparency enabled that cropped up during the linear work, and cubemap mips that cropped up during the gbuffer retool, respectively.)mean time:
Found and corrected a flaw with rendering #sometargetname tagged render targets on object materials (stand ins for diffuse maps. those with certain extension tech know what I mean there), and corrected the gammaP.hlsl/glsl calcs. (Prior HDR settings threw off the results. Pardon for the confusion there folks.)
#111
Did need to cut off specular sliders and specular maps working in conjunction, because, well... they weren't so much interacting as conflicting. Would be nice to hunt that on down at some point, but bigger fish to fry. Should also give folks a good notion of where we're at once we ramp on up to PBR.
10/13/2014 (7:30 pm)
I'll just leave i.imgur.com/tpWPSKD.jpg here.Did need to cut off specular sliders and specular maps working in conjunction, because, well... they weren't so much interacting as conflicting. Would be nice to hunt that on down at some point, but bigger fish to fry. Should also give folks a good notion of where we're at once we ramp on up to PBR.
#112
10/13/2014 (7:37 pm)
I still have no idea what I'm looking at in that picture. But... yay!
#113
You're also looking at the shading still being a bit off vs modern toolsets, and likely remaining so till we shift over to full-bore pbr pipeline. There's the downside. (*might* be able to justify a bit more hacking around without creating yet another branch to track, but that starts getting into breaking one thing to support another territory)
10/13/2014 (7:47 pm)
What you're lookin at is the engine and art tools looking in the same places for the same data, instead of playing channel bingo. There's the upside.You're also looking at the shading still being a bit off vs modern toolsets, and likely remaining so till we shift over to full-bore pbr pipeline. There's the downside. (*might* be able to justify a bit more hacking around without creating yet another branch to track, but that starts getting into breaking one thing to support another territory)
#114
Can we see some pictures of the implementation in action?
Good luck my friend.
11/25/2014 (12:30 am)
Hello. How is the work going on?Can we see some pictures of the implementation in action?
Good luck my friend.
#115
As for screenshots, honestly, for *this phase* of things, most of the work has been in ensuring that as much as humanly possible the front-end and end-results are backwards compatible, so aside from the linearity work shown earlier, not much should change aside from data storage and retrieval capacity, except perhaps a bit of a boost to lower end cards (from the reports I've been getting at least).
Once those are knocked out, then we can start getting moving on the type of stuff that will no ifs ands or buts about it require art pipeline alterations.
In short: This particular project has been about making the tools to make a new set of tools to make fo de moar pretteh.
11/25/2014 (10:17 pm)
There's PRs in the queue to be addressed once opengl is fully incorporated. A few last second touches here or there. Slated for 3.7 incorporation at time of writing.As for screenshots, honestly, for *this phase* of things, most of the work has been in ensuring that as much as humanly possible the front-end and end-results are backwards compatible, so aside from the linearity work shown earlier, not much should change aside from data storage and retrieval capacity, except perhaps a bit of a boost to lower end cards (from the reports I've been getting at least).
Once those are knocked out, then we can start getting moving on the type of stuff that will no ifs ands or buts about it require art pipeline alterations.
In short: This particular project has been about making the tools to make a new set of tools to make fo de moar pretteh.
Azaezel
accidentally slipped in a couple extra tex2dlinear references, removed those.
(on a related note, imposters were getting hit twice by that. Once on generation, and again on application. Cooked up a new MFT_Imposter feature that serves as nothing more than a value to be checked in order to swtich off HDR during imposter capture)
pixspecular flag wasn't properly getting triggered to allow for specular values sans maps. thanks tim for the fix there.
particle emitters were rendering out of order with other objects leading to sorting artifacts. another one caught by tim.
objects with color but no texture weren't rendering correctly partly due to the colorization, and partly due to fouled specular defaults. corrected those.
shadows for objects with alpha weren't passing that alpha along. corrected.
new gamma correction shows banding: old bug made more obvious with new code that shows under extreme conditions. we're still hashing that one out.
mew terrain rendering in reflected surfaced seems to be mangled texture and normal wise: i.imgur.com/RQ7aeLq.png