Deferred shading #1519
Merged
Deferred shading #1519
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Phase 1: buffers engine: provides the following hooks and methods A) render target "color", and "matinfo". these correspond to texture[0] = "#color"; texture[2] = "#matinfo"; entries in scripts B) utilizes the independentMrtBitDepth method added GarageGames#857 to set color to an 8RGBA if cards support it C) adds an RenderPrePassMgr::_initShaders() method to support void RenderPrePassMgr::clearBuffers(). This operates as a pseudo-postfx by rendering a veiwspace plane which fills the screen, then calls a shader which fills both the introduced rendertarget buffers and the prepass buffer to relevant defaults (white with full alpha for prepass, black with full alpha for color and material respectively) script: \game\tools\worldEditor\main.cs adds additional hooks similar to GarageGames#863 for colorbuffer, specular map, and backbuffer display \game\core\scripts\client\lighting\advanced\deferredShading.cs adds the clearbuffer shader, visualizers, and the ShaderData( AL_DeferredShader ) + PostEffect( AL_DeferredShading ) which combine the various buffers into the output which reaches the screen under normal conditions, as well as the extended debug visualizers. again, note the lines texture[0] = "#color"; texture[1] = "#lightinfo"; texture[2] = "#matinfo"; target = "$backBuffer"; in particular for the core tie-in. shader: \game\shaders\common\lighting\advanced\deferredColorShaderP.hlsl \game\shaders\common\lighting\advanced\gl\deferredClearGBufferP.glsl the previously mentioned shaders which clear the buffers to specified colors \game\shaders\common\lighting\advanced\deferredShadingP.hlsl \game\shaders\common\lighting\advanced\gl\deferredShadingP.glsl the tie-in shaders the rest are visualizers purpose: to expose methodology that allows one to render color, lighting and material information such as specular and gloss which effect the result of both when combined long term intent: the previous prepass lighting methodology while serviceable, unfortunately had the side effect of throwing out raw color information required by more modern pipelines and methodologies. This preserves that data while also allowing the manipulation to occur only on a screenspace (or reflected speudo-screenspace) basis.
defines and alters a series of material features for deferred shading in order to define a fully fleshed out multiple render target gbuffer patterned after the general principles outlined http://www.catalinzima.com/xna/tutorials/deferred-rendering-in-xna/creating-the-g-buffer/ (though I cannot stress enough *not* using the identical layout) script: removes dead material features (ie: those that never functioned to begin with) shader: bool getFlag(float flags, int num) definition for retreiving data from the 3rd (matinfo) gbuffer slot's red channel (more on that shortly) purpose: _A)_ Small primer on how material features function: When a https://github.com/GarageGames/Torque3D/search?utf8=%E2%9C%93&q=_determineFeatures call is executed, certain conditions trigger a given .addFeature(MFT_SOMEFEATURE) call based upon material definition entries, be it a value, a texture reference, or even the presence or lack thereof for another feature. In general terms, the first to be executed is ProcessedShaderMaterial::_determineFeatures followed by ProcessedPrePassMaterial::_determineFeatures. The next commit will provide the bindings there. For now it's enough to understand that one of those two will trigger the shadergen subsystem, when rendering a material, to check it's associated list of features and spit out a shader if one is not already defined, or reference a pre-existing one that includes codelines determined by that list of features. Relevant execution of this is as follows: DeclareFeatureType( MFT_DeferredDiffuseMap ); - Name ImplementFeatureType( MFT_DeferredDiffuseMap, MFG_Texture, 2.0f, false ); - Codeline Insertion Order FEATUREMGR->registerFeature( MFT_DeferredDiffuseMap, new DeferredDiffuseMapHLSL ); - Hook to class which actually generates code alternately FEATUREMGR->registerFeature( MFT_Imposter, new NamedFeatureHLSL( "Imposter" ) ); - a simple feature that serves no purpose further than as a test of it's existence (to modify other features for instance) class DeferredDiffuseMapHLSL : public ShaderFeatureHLSL - Class definition { getName -embeded in the proceedural shader as a remline both up top and before actual code insertions processPix - pixel shader codeline insertions getOutputTargets - used to determine which buffer is written to (assumes only one. depending on branched logic, older features that may be run for either forward or deferred rendering depending on circumstance may have a logical switch based on additional feature flags. as an example: TerrainBaseMapFeatHLSL::getOutputTargets) getResources - associated with the Resources struct, closely aligned with the hardware regestry getBlendOp - used to determine what blend operation to use if a material requires a second pass (defaults to overwriting) setTexData - ??? processVert - vertex shader codeline insertions }; _B)_ The resultant Gbuffer layout defined by the previous commit therefore is as follows: defaultrendertarget (referred to in shaders as out.col or col depending on GFX plugin) contains either lighting and normal data, or color data depending on if it is used in a deferred or forward lit manner (note for forward lit, this data is replaced as a second step with color. why custommaterials have traditionally had problems with lighting) color1 (referred to in shaders as out.col1 or col1 depending on GFX plugin) RGB color data and an A for blending operations (including transparency) color2 (referred to in shaders as out.col2 or col2 depending on GFX plugin) contains: red channel comprising material flags such as metalness, emissive, ect, green channel for translucency (light shining through, as oposed to see-through transparency), blue for blue for specular strength (how much light influences net color) alpha for specular power (generally how reflective/glossy an object is) long term purpose: further down the line, these will be used to condition data for use with a PBR subsystem, with further corrections to the underlying mathematics, strength being replaced by roughness, and power by metalness
by and large, Opengl branch compatibility alterations, though do again note the inclusion of sampler["lightBuffer"] = "#lightinfo"; sampler["colorBuffer"] = "#color"; sampler["matInfoBuffer"] = "#matinfo"; and samplerNames[5] = "$lightBuffer"; samplerNames[6] = "$colorBuffer"; samplerNames[7] = "$matInfoBuffer"; entries. This is where the engine knows to pass along a given rendertarget for input into a predefined shader, as opposed to the prior phase's output to targets within procedural ones. Shader: the XXXLight.hlsl/glsls account for alterations in inputs, check for emissive and translucency, apply Felix's Normal Mapped Ambient. and pass the results along to AL_DeferredOutput for final computation before returning the result. the lighting.hlsl/.glsl consissts of removal of the overridden engine-specific phong specular variant, and defines the AL_DeferredOutput method, which equates to the previously used pixspecular feature defined along the lines of http://books.google.com/books?id=GY-AAwAAQBAJ&pg=PA112&lpg=PA112&dq=blinn+phong+specular+gloss+hlsl&source=bl&ots=q9SKJkmWHB&sig=uLIHX10Zul0X0LL2ehSMq7IFBIM&hl=en&sa=X&ei=DbcsVPeWEdW1yASDy4LYDw&ved=0CB4Q6AEwAA#v=onepage&q=gloss%20&f=false also includes visualizers Long term impact: This area, along with the \game\shaders\common\lighting\advanced\lightingUtils.hlsl/.glsl pair will be where we plug in properly attenuated Cook-Torrence later, presuming the impact is not to hefty.
…ors, and of course, rolling in dependencies already submitted as PRs) consists of: renderPrePassMgr.cpp related: A) shifting .addFeature( MFT_XYZ); calls from ProcessedShaderMaterial::_determineFeatures to ProcessedPrePassMaterial::_determineFeatures B) mimicking the "// set the XXX if different" entries from RenderMeshMgr::render in RenderPrePassMgr::render C) fleshing out ProcessedPrePassMaterial::getNumStages() so that it shares a 1:1 correlation with ProcessedShaderMaterial::getNumStages() D) causing inline void Swizzle<T, mapLength>::ToBuffer( void *destination, const void *source, const dsize_t size ) to silently fail rather than fatally assert if a source or destination buffer is not yet ready to be filled. (support for #customTarget scripted render targets) Reflections: A) removing reflectRenderState.disableAdvancedLightingBins(true); entries. this would otherwise early out from prepass and provide no color data whatsoever. B) removing the fd.features.addFeature( MFT_ForwardShading ); entry forcing all materials to be forward lit when reflected. C) 2 things best described bluntly as working hacks: C1) when reflected, a scattersky is rotated PI along it's z then x axis in order to draw properly. C2) along similar lines, in terraincellmaterial, we shut off culling if it's a prepass material. Skies: scattersky is given a pair of rotations for reflection purposes, all sky objects are given a z value for depth testing.
|
Contributor list: Andrew Mac |
|
@ - @ Yeaaaah! |
…e water shader over-exposing it's reflections.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.