Hi Massimo,
Thanks for the context here. Even though there isn’t a fix, we’re glad you guys are at least aware of these issues and it’s not something on our end.
Due to the way material layers store parameter data it can lead to stale data when the parent parameter assignments are changed but the child material isn’t bumped, as you mentioned. Generally, in the engine we don’t have a dependency invalidation mechanism when a base asset notifies other dependant assets that it has changed: the only type of “update” we do is within the editor itself if these assets are opened in the editor. For instance changing an open material function will trigger changes to any material also opened that calls that function. Is this the type of dependency tracking you think is missing?
Yeah, we have noticed even more issues than these when editing materials programmatically like via UMaterialEditingLibrary since as you say, some of the update logic is unfortunately coupled to the actual Material Editor UI itself, however in this case these issues are from normal interactive edits via the FMaterialInstanceEditor UI. It seems like layered materials need to do more propagation since unlike parameter values, of which child MIs don’t store inherited values even in memory, the layer values are copied to child instances.
That said, in our case at least, the Epic out-of-the-box propagation logic does work correctly, however it’s only triggered in the UMaterialInstance:::PostLoad() so you need to restart the Editor or reload the assets to see the updates. It seems like missing part is that the Parent Material needs to find all the dependent materials in memory (maybe via FObjectCacheContext::GetMaterialsAffectedByMaterials?) sort them by inheritance depth and call UpdateParameters() working from the immediate children down to the leaf children. This would run the codepath which calls FMaterialLayersFunctions::ResolveParent and update their in-memory FMaterialLayersFunctions for their parent’s data instead of leaving the in-memory material out of date until next time it’s loaded. The semantics of PostLoad maintain this ordering normally since the parent material’s package always loads before the child material since it imports it.
I think really only the part inside the if (StaticParametersRuntime.bHasMaterialLayers && Parent) block matters since the UpdateParameterSet calls aren’t needed in this case (likely why the current logic which maybe predates the layer code doesn’t do this dependent material search) but they are also harmless to call in this situation AFAIK.
Regarding EMaterialLayerLinkState::LinkedToParent you’re correct. Currently, visibility is only inherited when a layer entry is newly added. I understand this may cause confusion, but it is the way it was implemented. It’s also difficult to change these behaviours now as other existing content may depend on it working this way. We can put this on our backlog of freature requests, but we currently can’t commit to when we would be able to do it.
Thanks for the confirmation. Yeah, we have similar concerns with changing the semantics ourselves due to existing content, even if the current behavior is resulting in authoring mistakes for us. One idea we had was creating a new EMaterialLayerLinkState enum like LinkedToParentWithVisibility or adding another TArray<bool> LayerInheritVisibilityStates to FMaterialLayersFunctionsEditorOnlyData so that the new behavior it would be opt-in (and likely a project setting to control the default for new materials)
Thanks,
Lucas
[Attachment Removed]