We are working on having a UI layer above/along the material instance editor. This is to improve artist workflow as some of our parameters can be cryptic and/or complex to edit. We have prototyped this UI layer using an editor utility widget but could consider creating a dedicated editor in c++ if necessary.
The issue we have run into is that the getters for material parameters will access any parameter exposed to the material instance, without any option of filtering parameters that should be hidden due to the outcome of a static switch. This effectively means that we cannot hide parameters that are not part of the compiled shader. The native material instance editor does hide parameters based on these static branches, so we’d like to understand and explore a way of getting that same behavior for our custom interface. How can we achieve this behavior?
A not too similar question but that is also curious to us, is there any way of accessing the meta data (category, priority) of a parameter?
Ok so I have encountered a similar issue in the past and the reason is mostly likely that the editor is parsing the exposed expressions through the full list of bound expressions, not through the activated/compile paths. There is a less direct way to check for usage which essentially involves adding a recursive loop which checks the connections from each output node and goes through each expression to test each path, what is connected, and what is activated/deactivated. This is not built into the engine currently (although will be part of our new material translator which is going into experimental for 5.7).
Could you please share with me some code samples/screenshots of what your current setup is so I have a bit more context? And in the meantime I’ll dig out the code sample I have *somewhere* (lol) which does the parsing behaviour I described above.
I’d be happy to try out the recursive approach, but I struggle to understand how to parse the graph.
I thought an alternative approach could be to programmatically run “Show HLSL Code” (as available in the material editor’s menu Window->Shader Code-> HLSL Code), and read the bottom section of it which lists all currently compiled parameters. What do you think of this approach? I’d try it but I found no way of running the “Show HLSL Code” command and access the text file.
Sure, here are some screenshots of a simplified setup. The widget setup is a bit too complicated to show but below is an explanation to the screenshots and what is going on in them.
The names of the parameters in the material hold meta data like this:
I use this meta data to create the appropriate widgets and to sort the parameters into groups/categories and by priority (order their widgets appear in the list). Ugly - I know, so I’d ideally want to get access to the meta data (group and priority) that already exists on the material editor nodes.
In this example there are two parameters, one with the CSS (Color Scheme Selector) widget prefix and one with the FT (Float Toggle) widget prefix. The color scheme selector gives the user an enum list to pick from and sends 0, 1, 2 or 3 to the material. The float toggle is simply sending 0 or 1 depending on the state of the toggle.
There are various other widget classes we have as well, such as a texture array slice selector, these are just two examples.
As you can see in the material graph there is a static switch parameter that should be filtering out the parameter “FT|Style 1|1|Multiply Color” when set to false, but I have no access to this information. This means that the editor widget must display all exposed parameters and what is worse is that they would sometimes have no effect. In this example (see screenshot with blue sphere) you find that the Multiply Color parameter (which returns 0 when the toggle is unchecked) should make the blue sphere turn black, but the static switch parameter is false so the change has no effect.
Which parameter fetching function are you using to retrieve the available params in your widget? I ask because it looks like FMaterialEditorUtilities::GetVisibleMaterialParameters already performs the recursive approach I described, fetching via enabled/disabled static switches. Have you tried using this function at all?
Sorry it’s been a bit busy lately but I was just ready to test FMaterialEditorUtilities::GetVisibleMaterialParameters and it works nicely. Thank you for the help!