- 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]
Also restores follow-up CLs 19973746, 19973782
FStaticParameterSet::MaterialLayers can't be deprecated, since a property with the same name is included via FStaticParameterSetRuntimeData
So instead, FMaterialLayersFunctionsRuntimeData is updated with SerializeFromMismatchedTag, to allow serializing a full FMaterialLayersFunction.
When this happens, the EditorOnly portion is stored in a separate heap allocation, and then transferred to FStaticParameterSet::EditorOnly::MaterialLayers
#preflight 626c3405e31dbb512cef1e98
[Backout] - CL19973745
#fyi bob.tellez
Original CL Desc
-----------------------------------------------------------------
[Backout] - CL19964485
#fyi Ben.Ingram
Original CL Desc
-----------------------------------------------------------------
Add 'Optional' EditorOnly data for UMaterialInterface and UMaterialFunctionInterface
These are separate UObject hierarchies that store editor-only UPROPERTIES, but can be included with cooked content, which allows full editor support.
In principle, all editor-only properties could be moved over. So far, this has been limited to UMaterialExpressions, and data related to material parameters.
FStaticParameterSet, FMaterialLayersParameters, and FMaterialCachedExpressionData have all been split into separate editor-only/non-editor-only classes,
which allows the editor-only portion to be stored on the optional editor-only UObject.
#preflight 626ab21dad56c0cbbea32dc4
#rb jason.nadro, francis.hurteau
#jira FORT-463329
[CL 20043286 by Jason Nadro in ue5-main branch]
#fyi Ben.Ingram
Original CL Desc
-----------------------------------------------------------------
Add 'Optional' EditorOnly data for UMaterialInterface and UMaterialFunctionInterface
These are separate UObject hierarchies that store editor-only UPROPERTIES, but can be included with cooked content, which allows full editor support.
In principle, all editor-only properties could be moved over. So far, this has been limited to UMaterialExpressions, and data related to material parameters.
FStaticParameterSet, FMaterialLayersParameters, and FMaterialCachedExpressionData have all been split into separate editor-only/non-editor-only classes,
which allows the editor-only portion to be stored on the optional editor-only UObject.
#preflight 626ab21dad56c0cbbea32dc4
#rb jason.nadro, francis.hurteau
#jira FORT-463329
[CL 19973745 by bob tellez in ue5-main branch]
These are separate UObject hierarchies that store editor-only UPROPERTIES, but can be included with cooked content, which allows full editor support.
In principle, all editor-only properties could be moved over. So far, this has been limited to UMaterialExpressions, and data related to material parameters.
FStaticParameterSet, FMaterialLayersParameters, and FMaterialCachedExpressionData have all been split into separate editor-only/non-editor-only classes,
which allows the editor-only portion to be stored on the optional editor-only UObject.
#preflight 626ab21dad56c0cbbea32dc4
#rb jason.nadro, francis.hurteau
#jira FORT-463329
[CL 19964485 by Ben Ingram in ue5-main branch]
This represents UE4/Main @18073326, Release-5.0 @18081140 and Dev-PerfTest @18045971
[CL 18081471 by aurel cordonnier in ue5-release-engine-test branch]
This represents UE4/Main @17911760, Release-5.0 @17915875 and Dev-PerfTest @17914035
[CL 17918595 by aurel cordonnier in ue5-release-engine-test branch]
- This way we don't need to move statements around, can generate both if/else scope correctly before switching back to parent scope
- Will make it easier to track locals within the current scope
#rb none
#jira none
#ROBOMERGE-SOURCE: CL 16354735 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v804-16311228)
[CL 16354746 by ben ingram in ue5-release-engine-test branch]
Only mildly functional currently, my goal here is to get feedback on the high level direction. The new code is disabled by default; it needs to be opted-into per material (and the UI for that is hidden by default behind a CVAR), so it shouldn't affect any existing workflows.
Basic outline:
* UMaterialExpression::Compile is replaced by GenerateHLSLStatement/GenerateHLSLExpression
* GenerateHLSLExpression returns a HLSLTree::FExpression derived object. This is broadly similar to FShaderCodeChunk, except FExpression stores pointers to dependent expressions, and only generates the final HLSL string on demand (EmitHLSL method). FExpression will have many derived classes to represent various HLSL expresisons like Add, Parameter, Constant, etc.
* GenerateHLSLStatement returns a HLSLTree::FStatement. Statements represent chunk of HLSL code rather than a value. 'if(...)' is a statement for example.
* UMaterialExpression will normally override only 1 of GenerateHLSLStatement/GenerateHLSLExpression, although both are possible (for loop may override both, since the for loop index is an expression for example)
* FMaterialHLSLGenerator is the 'context' object passed to GenerateHLSLStatement/GenerateHLSLExpression. This is kind of like FHLSLMaterialTranslator. It's responsible for tracking which scope statements/expressions belong to (this can evolve as a given expression/statement is accessed from multiple UMaterialExpressions)
* HLSLTree.h contains the implementation of Expression and FStatement. I feel like it's possible this could be useful outside of the material system (for example could be shared with Niagara). Will be tricky to partition/organize the code in such a way to make this work though.
* HLSLTreeCommon.h contains derived expression/statement types. The intent is to support plugins that define additional derived types.
* MaterialExpressionHLSL.cpp contains the implementations of GenerateHLSLStatement/GenerateHLSLExpression I've added so far. Eventually all expression types will need to be converted over (this will be a big job). Once the new system is done, we can remove all the old Compile() functions in MaterialExpressions.cpp
* I haven't given any real thought to Strata or analytic derivatives yet, but I don't forsee any serious problem adapting them to this new system
#jira none
#rb arciel.rekman, sebastien.hillaire, rune.stubbe
[CL 15536071 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]
#rb none
#jira UE-89380
#ROBOMERGE-OWNER: rex.hill
#ROBOMERGE-AUTHOR: rex.hill
#ROBOMERGE-SOURCE: CL 11612429 via CL 11612432 via CL 11612438
#ROBOMERGE-BOT: (v656-11643781)
[CL 11762021 by rex hill in 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]
Texture streaming accuracy visualization now show the current state of data, and doesn't need to build the texture streaming as a prestep.
#rb alexis.matte
#jira UE-76859
#ROBOMERGE-SOURCE: CL 7223779 in //UE4/Release-4.23/...
#ROBOMERGE-BOT: RELEASE (Release-4.23 -> Main) (v367-6836689)
[CL 7223780 by uriel doyon in Main branch]
