engine: mipmap support for cubemaps and reflection render targets
immediate goal: none
long term goal: roughness support
TODO: opengl equivalent

engine:
gfxD3D9CardProfiler.cpp - detection for independent bit depth render targets (meaning checking to see if a card can support writing to an RGBA8 and an RGBA16 simultaneously, or it it requires setting them to the same size)
matTextureTarget.cpp - additional feedback for failed named texture targets
shaderFeature.cpp - correlates rendertargets with shadergen insertion strings so that hlsls and glsls can reference them to write to simultaneously
gfxGLShader.cpp/ shaderGenGLSL.cpp - activates the GL_ARB_explicit_attrib_location OpenGL extension in order to make use of the layout functionality (url included in-engine for full documentation, but the short version is it turns on the opengl equivalent of MRTs), and fleshes out ShaderGenPrinterGLSL::printPixelShaderOutputStruct/ ShaderGenPrinterGLSL::printPixelShaderCloser so that it operates in a similar manner to the directx side.

immediate purpose: prepwork.

long term impact: will allow shadergen and hand written files to render to send data to multiple render targets from one shader file execution, while providing a lookup mechanism for receipt

TODO: detect older versions of opengl, and utilize the array[] method?

engine:
renderPassManager.h - definition
renderPassManager.cpp - reference string

script (to be included in a secondary PR): \game\core\scripts\client\renderManager.cs will add scripted timing and an additional functionality entry.

immediate purpose: provides a render sorting mechanism specific to decal roads.

long term impact: will also include a basiconly flag used by deferred shading to denote that this will only be rendered using the basic lighting functionality, as opposed to the higher-order advanced lighting mechanisms.

engine: creates and exposes a basicOnly flag, as well as early outs in relevant spots.

script: the rest of the basicoly denotations from the prior PR

immediate purpose: The basiconly flag referenced in #850

long term impact: strictly speaking, this one is only of true beneficial use for deferred shading.

Again, used to denote rendering objects which bypass the higher order lighting subsystems.

…mposters being linearized twice.

…et alone to multiple targets, so lets see if that makes the auto-compiler happy.

script
rendermanager.cs- Like it says at the bottom of the file, PFX_PassthruShader is just that, a bottleneck through which all shaders run. The end result of that is that the lighting buffer, which at a minimum uses 16RBG becomes downsampled and bands. Steps were taken with stock torque to mitigate that, but with linearization incoming, the effect is exacerbated.
script(hlsl/glsl) - the saturate command (clamp in glsl) ensures the results fall into a 0-1 range (you'd get a black circle in the center of the sun otherwise)
source: simplicfication

immediate purpose - slightly noticeable smoothing of light banding with heavily bright lights in extremely dark environments

long term impact - shuts off a future issue with corrected lighting calculations.

source:
desc.setZReadWrite( true, false ); allows a given renderable object to test the depth buffer but not write to it.
mIsSky is a new material definition for skyboxes
void DeferredSkyHLSL::processVert( Vector<ShaderComponent*> &componentList,  (and the glsl equivalent) is a method for inserting code into programatically generated shaders. in this case vertex shaders.

script: isSky tagged materials

script(hlsl/glsl): prefabricated hlsl/glsl files reference for cloudlayer and basicclouds objects

immediate purpose: simply adds a variable

long term impact:
One of the primary differences in a prepass lighting vs a more fully parallel deferred approach is that for the former (stock) methodology, lighting is written to the backbuffer, then diffuse is written on top, while for the latter, lighting information goes in one target, and albedo in another for all intents and purposes in a simultaneous manner, then tied up later.

For stock, the lack of depth for sky assets was a non-issue, since these assets were the first thing written after lighting and before the rest of the diffuse-enabled assets. By providing depth and depth testing, this allows one to sort sky assets behind other renderable objects instead of displaying in front of them.

…feature is detected and triggered. in the actual deferred branch, we shift all other cubemaps from:

ProcessedShaderMaterial::_determineFeatures
to
ProcessedPrePassMaterial::_determineFeatures

source:
implements an MFT_Imposter shadergen feature used to filter out imposter captures and glows. otherwise when loading an albedo/diffuse texture, shadergen will insert a tex2DLinear method call to colorcorrect the loaded result

script:
the previous gamma correction slider operated closer to a brightness slider. This has been updated to correct for monitor gamma, and an actual brightness / contrast pair added.

shader:
gamma correction consists of a first and last step.
-- first: return float4(pow(abs(sampl.rgb), 2.2), sampl.a); to feed the coloration into the lighting calculations
present in torque.hlsl/glsl
-- last: color.rgb = pow( abs(color.rgb), OneOverGamma ); to turn the color range back into normal monitor color space
present in the HDR shader-chain's finalPassCombineP.hlsl/glsl, and gammaP.hlsl which the engine falls back to if the HDR postfx is disabled

short term impact: what-you-see-is-what-you-get coloration from texture tool to engine. (also brings hdr and non-hdr coloration much closer.)

long term impact: vital to correct calculations once the PBR track is fully engaged.

*special note* you may notice a few extra spaces in terrFeatureGLSL.cpp and terrFeatureHLSL.cpp. leave them. they're due to cutting out an if-switch used by deferred shading that will be put back.

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 #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 #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.

…tfx so that it combines render targets and renders to the backbuffer (which is passed along to the screen)

engine:
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:
swaps the undefined env map feature for a defined translucency one

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

…n shared properties between the forked deferred and forward rendered featuresets

Script:
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.

The final step (barring any overlooked missing bits, requested refactors, 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.

…Function Pipeline and we need a shader for render.

…cshaders' into development_opengl

…l' into development_opengl

…' into development_opengl

…erNames' into development_opengl

…development_opengl

…o development_opengl

Conflicts:
	Engine/source/gfx/gfxDevice.h

…into development_opengl

…pengl

Conflicts:
	Engine/source/gfx/gl/gfxGLShader.cpp