1) we do *not* in fact want to early out in the presence of MFT_ImposterVert. it mangles the position-send.
2) dx sucessfuly handles the if ( !fd.features[MFT_NormalMap] ) case, so use the same for gl
Also fixes handling of metal materials during bakes to render properly, and fixes a possible double-up return in findObjectByType, which could cause doubling when getting probes in the scene
Temporarily disabled wsNormal addition when we have no defined normal map until it's finished being integrated
Fixed the structure for the lighting/probe shadergen logic in GL so it generates correctly, resolving a crash on unix machines.
Added templated getObjectsByClass to Scene for easier engine-side polling of objects, including nested checks for subscenes
Proper init'ing of mGamemodeName in LevelAsset, as well as proper fieldType for mIsSubLevel
D3D11 added logic to handle scaling down of textures in cubemap arrays for lower texture resolution preferences
Added ability to collapse groups programmatically to GuiVariableInspector
Upped PSSM shadowmap max size to 4096
Caught GL deferred lighting/probes up to D3D11
Temporarily disabled forward lighting/probes on GL materials until conversion finished
Upped smMaxInstancingVerts to 2000 from 200 to support slightly more detailed meshes being instanced
Reordered project settings so they load ahead of core modules, so that core modules can actually use project settings
Established current preset file for PostFXManager to use for reverting
WIP logic for forcing probes to update as part of level lighting load step in loading process
Streamlined PostFXManager code, removing unnecessary/redundant files
Coverted HDR, Lightrays and SSAO and ExamplePostEffect to use new PostFX Manager/Editor paradigm
PostFX manager now enacts callbacks so that postFXs' can process their own settings as well as provide editor fields
Changed PostFX editor to work with new callbacks via using VariableInspector
Updated PostEffectAsset's template file so new PostFX's will now automatically register with the PostFXManager and have the needed new callbacks for integration
Made HDR on by default, removed enable field from editing
Made probe bake resolution a project setting
Updated many GL postFX shaders to have proper case for PostFx.glsl
Example module now loads ExampleGUI and ExamplePostEffect during init'ing
Removed unneeded autoload definitions from ExampleModule's module file
Fixed Graphics Adapter settings field to properly display as well as apply setting
Updated many referenced profiles in tools folder to use the Tools specific gui profiles to make theming more consistent
Fixed coloration of tools button bitmap to make theming more consistent
Updated a few theme settings for improved visibility with theme, particularly selected/highlighted text
Moved AssetBrowser field types to separated folder/files
Updated new module creation to properly utilize template file instead of overriding it with a programmatic script generation.
Removed unneded default autoload definitions from new modules
Added WIP for editing Module/Asset dependencies
Updated the PostEffectAsset to properly generate glsl and hlsl files from templates
Updated module editor window to display only necessary fields
Added WIP of TerrainAsset
Added shaderCache gitignore file so folder isn't lost
`Engine\source\gfx\gfxDevice.cpp(837,0): {Fatal} - GFXDevice::setTexture - out of range stage! -1>16` though the shaders themselves are now in a compling state (ostensibly)
This makes some tweaks to the engine to support this, specifically, it tweaks the hardcoded shaderpaths to defer to a pref variable, so none of the shader paths are hardcoded.
Also tweaks how post effects read in texture files, removing a bizzare filepath interpretation choice, where if the file path didn't start with "/" it forcefully appended the script's file path. This made it impossible to have images not in the same dir as the script file defining the post effect.
This was changed and the existing template's post effects tweaked for now to just add "./" to those few paths impacted, as well as the perf vars to support the non-hardcoded shader paths in the engine.
- Supports GL, D3D9 & D3D11
- Extends vertex formats & shadergen to support blend indices and weights
- Adds basic support for using 4x3 matrices for shader constants
- Supports software fallback
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
