Commit graph

11 commits

Author SHA1 Message Date
AzaezelX ad216abc02 cleans up a few more spots of various variables that ammount to the "PBRConfig" in the end, as well as a MFT_isDeferred test for determining if that's stored off as a temp-val or in the gbuffer. though seem to have forgotten a catch, as it's not finding the MFT_PBRConfigMap feature and falling back to recreation come time to process MFT_ReflectionProbes 2019-10-23 14:59:29 -05:00
AzaezelX bfccfca0ce more conversionwork from specular entries to pbrconfig ones, adds backend glowmul and glowmap var tracking, as well as pbrconfigmap composite slip-in for the glowmap (sans shaderfeatures just yet). seems to have busted forward lit application though... 2019-10-22 15:11:39 -05:00
AzaezelX 65cbf49c4a backend specularMap to PBRConfigMap alts.
left:
     addField( "specularMap", TypeImageFilename, Offset(mPBRConfigMapFilename, Material), MAX_STAGES,
scripthook till last since that *will* break all current materials.
2019-10-16 15:51:02 -05:00
AzaezelX 98a3ff604a nonbreaking 'specularcolor' to 'pbrConfig' var conversion. (TODO: specularMap entries) 2019-04-29 19:40:22 -05:00
Tim Barnes 9e65e940d0 lighting single buffer 2018-11-21 15:53:02 +10:00
Areloch b4a1d18f42 Core implementation of Physical Based Rendering. 2018-09-15 20:19:57 -05:00
Areloch edd1e0a270 Removes Direct3D9 functionality. 2017-05-28 16:51:31 -05:00
Areloch af8fbf0e3a Goes and replaces the references/names that use Prepass to be Deferred, since we're actually using deferred. 2017-04-11 00:23:14 -05:00
rextimmy 41e5caf22b Direct3D11 Engine/source changes 2016-03-20 21:52:11 +10:00
Azaezel 9472bfd3ca addresses https://github.com/GarageGames/Torque3D/issues/1537 via the following:
908be4818f/Engine/source/materials/materialDefinition.cpp (L261) denotes power as sharpness, reflected in the size/falloff of a highlight halo *

908be4818f/Engine/source/materials/materialDefinition.cpp (L264) denotes strength as overall brightness of highlights. **

*and sharpness of reflection if using a cubemap.
**  reflected in cubemapped objects as also degree of 'reflection' vs diffuse/albedo coloration.
2016-03-01 20:25:52 -06:00
Azaezel 196b214eae 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:
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
2016-02-16 02:23:23 -06:00