- Inline edit support for UPROPERTY of type float, int32, uint32, uint8, enum, bool.
- Editable UPROPERTYs with "OverridingInputProperty" metadata are created as inline widgets next to their corresponding inputs.
- Rest of the editable UPROPERTYs may specify "ShowAsInputPin" metadata to become inline edit pins, with 2 choices: "Primary" - show in primary view, "Advanced" - show in in advanced view.
- Update a bunch of material expressions to reflect the changes, rest of the expressions still need to be worked through.
#jira UE-145276
#rb kevin.Ortegren
#preflight 627a3cc8937a047d62282ba7
[CL 20122451 by Josie Yang 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]
Instead, add 'SourceIndex' directly to UEdGraphPin and remove the map
Too many edge cases where something would modify pins directly, and the map would get out of sync with actual pins
#jira UE-119861
#rb lauren.barnes
[CL 16897567 by Ben Ingram in ue5-main branch]
- Instead, use control flow materials use the regular root node, with an exec input stacked on top
- Execution begin expression remains
- Will simplify graph processing, as now we only have a single end-point
#rb none
#jira none
[CL 16331502 by Ben Ingram in ue5-main branch]
- Previously exec inputs/outputs were stored along with other (data) inputs/outpus
- Problem is, for exec pins, we want each output to only support 1 connection, but multiple connections to each input. This is the opposite of data, where we support multiple output connections, but only 1 input connection
- So we flip the representation around, and store output pointers, rather than input pointers...this also better matches the way we iterate exec connections while compiling
- This does complicate some UI logic, as now input/output graph pins no longer line up exeactly with UMaterialExpression inputs/outputs (we still have a flat list of pins, but separate lists of exec/non-exec inputs/outputs)
#jira none
#rb lauren.barnes
[CL 15361599 by Ben Ingram in ue5-main branch]
- Very WIP, not intended/ready for production use
- Hidden behind CVAR to enable support, and per-material flag to opt in
#jira none
#rb rune.stubbe
[CL 15251606 by Ben Ingram in ue5-main branch]
Add composite & pinbase expressions / nodes, which use reroutes under the hood to ensure zero material overhead.
Convert MaterialEditor to a WorkflowCentricApplication.
Generally add subgraph existence support to MaterialGraph / MaterialEditor.
#jira UE-96104
#rb Ben.Ingram Lauren.Barnes
#fyi Lauren.Barnes
[CL 14437968 by daren cheng in ue5-main branch]
#rnx
#rb none
#ROBOMERGE-SOURCE: CL 10869241 via CL 10869527 via CL 10869904
#ROBOMERGE-BOT: (v613-10869866)
[CL 10870586 by ryan durand in Main branch]
