The first series of changes relate to modifying the way that SGraphNode* inheritants are created. Previously, NodeFactory was responsible of creating the SGraphNode* inheritants based on some runtime type checking (which basically means a series of if statements checking if the passed in pointer is of a certain child class type). Now, the UMaterialGraph* inheritants (the controller classes in the MVC paradigm of the material graph) are responsible for creating their own UI components (SGraphNode* inheritants). This just means that we now polymorphically create the proper SGraphNode* for the given UMaterialGraph* inheritant.
This refactor allows us to more flexibly create a variety of nodes types instead of relying on SGraphNodeMaterialBase as a one size fits all solution, leading to the new HLSL custom node. Previously, this node didn't support showing the syntax-highlighted code inline in the node itself. Because we now use polymorphism to create the nodes, it was very easy to create new UMaterialGraph* and SGraphNode* inheritants to support this new change.
Other changes which relate to propagating changes (to affect previews) in MaterialGraphNode.cpp are needed because there previously wasn't the mechanism to do so (which may have been a bug). For instance, suppose you had a constant vector3 feeding into a custom HLSL node which just outputs the color coming from that constant vector3 node. It would be obvious that changing the vector3, requires a preview update of the HLSL node. However, that wouldn't happen - the preview on the HLSL node just stayed the same. These changes addresses that issue.
There is one last series of changes which relates to collapsing the HLSL code in the node. We want to make sure that this change doesn't mess up the layouts of artists' already made material graphs which use the custom HLSL node. In order to address this, we added the ability to collapse the code in order to hide it. Furthermore, we had to make sure that projects which previously used a custom HLSL node, have the code collapsed by default (because it wasn't there before). However, creating a new HLSL node once this change comes in, would yield an uncollapsed node. The collapsing of nodes uses the "Advanced Pins" chevron/collapser which doesn't save its state after saving and exiting the material. It was crucial, in order to preserve the layout of the material graph, that the saving happens. However, previously, the only way to save state, was to go through a recompile/regeneration of the previews. Therefore, it was necessary to add a special function in the material editor utilities which would just mark the material as dirty such that states like whether the code was collapsed save throughout sessions.
#jira UE-146779
#rb jason.nadro
[CL 26677757 by luc rosenzweig in ue5-main branch]
Optimized function UMaterialExpression::GetInputs() with highest exclusive run-time during material translation from 19.79% to 1.79% exclusive run time.
This change caches the inputs upon expression creation by default and return a TArrayView instead of always creating a new transient dynamic array. The optimization also simplifies code for some Expression types.
Also optimized ContainsInputLoopInternal() to use a linked list of stack allocated nodes instead of Pushing/Popping from a dynamic array.
#rb jason.nadro
#preflight 6478b849c26e3b2449ff8608
[CL 25735070 by massimo tristano in ue5-main branch]
[FYI] massimo.tristano
Original CL Desc
-----------------------------------------------------------------
Optimizations in Material translation code amounting to 50% speed up.
Optimized function UMaterialExpression::GetInputs() with highest exclusive run-time during material translation from 19.79% to 1.79% exclusive run time.
This change caches the inputs upon expression creation by default and return a TArrayView instead of always creating a new transient dynamic array. The optimization also simplifies code for some Expression types.
Also optimized ContainsInputLoopInternal() to use a linked list of stack allocated nodes instead of Pushing/Popping from a dynamic array.
#rb jason.nadro
#preflight 64776ef44a277ca8f0b9a538
[CL 25722294 by massimo tristano in ue5-main branch]
Optimized function UMaterialExpression::GetInputs() with highest exclusive run-time during material translation from 19.79% to 1.79% exclusive run time.
This change caches the inputs upon expression creation by default and return a TArrayView instead of always creating a new transient dynamic array. The optimization also simplifies code for some Expression types.
Also optimized ContainsInputLoopInternal() to use a linked list of stack allocated nodes instead of Pushing/Popping from a dynamic array.
#rb jason.nadro
#preflight 64776ef44a277ca8f0b9a538
[CL 25722174 by massimo tristano in ue5-main branch]
Sparse Volume Texture asset from imported OpenVDB (only a single float channel for now). Static or animated sequence.
It will be possible to generate SVT at runtime from GPU later.
Using FEditorBulkData for handling raw source without loading everything when not caching or cooking.
BulkData used at runtime for loading. No streaming yet.
Importer with dependency on OpenVDB is in a SparseVolumeTexture module only loaded when in editor
Sparse volume texture can be sampled from any materials (sample, sample parameter) and overridden on material instance and material instance dynamic.
Added support for uint in compiler (fetch from page table, see SparseVolumeTextureGetVoxelCoord)
Volume texture with u8 VirtualTextureLayerIndex!=255 (INDEX_NONE) are sparse texture. The layer index then represent what texture/attribute to sample.
#preflight https://horde.devtools.epicgames.com/job/6346a466f93be0f6345af86c
#rb Patrick.Kelly, Charles.deRousiers
[CL 22551963 by sebastien hillaire in ue5-main branch]
- 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]
