- Completely changed the way we evaluate and represent the material topology.
- A topology is now represented as a tree to allow any horizontal/vertical operations (almost like a kdtree).
- This allows for correct translucent material coverage/transmittance evaluation, as well as correct BSDFs luminance weight (finally).
- All the operations to be able to do that are expended in HLSLTranslator instead of letting the compiler handle it (otherwise was too slow, leading to bugs and could not even debug shaders). This means no conditional BSDF packing.
- There is no more Material/layer/BSDFs array: only a Tree or operators, some of them being BSDF at leaves.
- Parameter blending has also been updated: when enabled on a node, it will be forced on all the oprator child / in the sub tree.
- Parameter blending is applied on an inlinedbsdf on the StrataData. When it is the root of the parameter blending subtree, it is promoted to a fully fledged BSDF operator node to allow other regular operators.
- The inlinedbsdf is not longer in premultiplied mode. Horizontal/Vertical/Add parameter blending operators have been updated to reflect that. This allows for simpler/unified/clearer code.
- Vertical blending now uses the new simple "layering of two slabs with uncorelated coverage" math I have RnD'd. See GetVerticalLayeringInfo in ShadingCommon.ush.
Follow up to this CL:
- CompileStrataBlendFunction should use parameter blending.
- Add more compilation debug output
- Update material vizualisation
- Fix Rough refraction
- Fix decals
- Fix debug probes
- Pack FStrataBSDF
- Move all StrataCompilationInfoCreateSingleBSDFMaterial into into the strata tree and rework cost evaluation and material LOD
- Expand graph visit such as UpdateBSDFWeightAfterOperatorVisit to be specific to operators for the compiler to have to do less search to inline what we know already
- Fix STRATA_TODO: operation using parameter blending are not actually discarded so they still occupy a pot in the opeartion arrays in the compiler and in the shader also.
#rb charles.derousiers
#preflight https://horde.devtools.epicgames.com/job/620a5f5d803d9066e67de938
#fyi charles.derousiers
[CL 18993400 by Sebastien Hillaire in ue5-main branch]
Basic approach is to add HLSL types FLWCScalar, FLWCMatrix, FLWCVector, etc. Inside shaders, absolute world space position values should be represented as FLWCVector3. Matrices that transform *into* absolute world space become FLWCMatrix. Matrices that transform *from* world space become FLWCInverseMatrix. Generally LWC values work by extending the regular 'float' value with an additional tile coordinate. Final tile size will be a trade-off between scale/accuracy; I'm using 256k for now, but may need to be adjusted. Value represented by a FLWCVector thus becomes V.Tile * TileSize + V.Offset. Most operations can be performed directly on LWC values. There are HLSL functions like LWCAdd, LWCSub, LWCMultiply, LWCDivide (operator overloading would be really nice here). The goal is to stay with LWC values for as long as needed, then convert to regular float values when possible. One thing that comes up a lot is working in translated (rather than absolute) world space. WorldSpace + View.PrevPreViewTranslation = TranslatedWorldspace. Except 'View.PrevPreViewTranslation' is now a FLWCVector3, and WorldSpace quantities should be as well. So that becomes LWCAdd(WorldSpace, View.PrevPreViewTranslation) = TranslatedWorldspace. Assuming that we're talking about a position that's "reasonably close" to the camera, it should be safe to convert the translated WS value to float. The 'tile' coordinate of the 2 LWC values should cancel out when added together in this case. I've done some work throughout the shader code to do this. Materials are fully supporting LWC-values as well. Projective texturing and vertex animation materials that I've tested work correctly even when positioned "far away" from the origin.
Lots of work remains to fully convert all of our shader code. There's a function LWCHackToFloat(), which is a simple wrapper for LWCToFloat(). The idea of HackToFloat is to mark places that need further attention, where I'm simply converting absolute WS positions to float, to get shaders to compile. Shaders converted in this way should continue to work for all existing content (without LWC-scale values), but they will break if positions get too large.
General overview of changed files:
LargeWorldCoordinates.ush - This defines the FLWC types and operations
GPUScene.cpp, SceneData.ush - Primitives add an extra 'float3' tile coordinate. Instance data is unchanged, so instances need to stay within single-precision range of the primitive origin. Could potentially split instances behind the scenes (I think) if we don't want this limitation
HLSLMaterialDerivativeAutogen.cpp, HLSLMaterialTranslator.cpp, Preshader.cpp - Translated materials to use LWC values
SceneView.cpp, SceneRelativeViewMatrices.cpp, ShaderCompiler.cpp, InstancedStereo.ush - View uniform buffer includes LWC values where appropriate
#jira UE-117101
#rb arne.schober, Michael.Galetzka
[CL 17787435 by Ben Ingram in ue5-main branch]
