MaterialX icon indicating copy to clipboard operation
MaterialX copied to clipboard

Web Viewer: not all inputs are displayed

Open hybridherbst opened this issue 2 years ago • 3 comments

I was looking at the web version of MaterialXView: https://academysoftwarefoundation.github.io/MaterialX/ and noticed that the inputs displayed in the UI don't match the actually expected inputs.

Some examples:

standard_surface_marble_solid.mtlx

image

Expected would be two additional color slots:

    <input name="base" type="float" value="1" />
    <input name="base_color" type="color3" nodegraph="NG_marble1" output="out" />
    <input name="specular_roughness" type="float" value="0.1" />
    <input name="subsurface" type="float" value="0.4" />
    <input name="subsurface_color" type="color3" nodegraph="NG_marble1" output="out" />

myFile.mtlx

image

Expected would be two inputs, base_color and specular_roughness:

<?xml version="1.0"?>
<materialx version="1.38" >
	<nodegraph name="needle_shadergraph" >
		<combine3 name="combine_vector3" type="vector3" >
			<input name="in1" type="float" value="0.0" />
			<input name="in2" type="float" value="0.0" />
			<input name="in3" type="float" value="1.0" />
		</combine3>
		<separate3 name="Split" type="multioutput" >
			<input name="in" type="vector3" nodename="combine_vector3" />
		</separate3>
		<invert name="invert" type="float" >
			<input name="in" type="float" output="outy" nodename="Split" />
		</invert>
		<convert name="float_to_color3" type="color3" >
			<input name="in" type="float" output="outx" nodename="Split" />
		</convert>
		<output name="base_color" type="color3" nodename="float_to_color3" />
		<output name="specular_roughness" type="float" nodename="invert" />
	</nodegraph>
	<standard_surface name="needle_standard_surface" type="surfaceshader" >
		<input name="base_color" type="color3" nodegraph="needle_shadergraph" output="base_color" />
		<input name="specular_roughness" type="float" nodegraph="needle_shadergraph" output="specular_roughness" />
	</standard_surface>
	<surfacematerial name="Default" type="material" >
		<input name="surfaceshader" type="surfaceshader" nodename="needle_standard_surface" />
	</surfacematerial>
</materialx>

It looks like the UI generation code has some heuristics in place, e.g. checks if there's "standard_surface/base" before adding "standard_surface/base_color" to the UI, but I'm not sure if that's all there is to it.

hybridherbst avatar Aug 21 '23 10:08 hybridherbst

Hi @hybridherbst,

The viewer only exposed inputs which are unconnected (and editable).

Also as your nodegraph has no inputs in it to "expose" an interface no inputs to show from there in case you want to add user control there.

But this part seems to have regressed but unsure when.

@jstone-lucasfilm, unfortunately we don't test this regularly so unsure if you have any idea what might be occuring? Guessing it has to do with parsing the UI elements but don't recall any changes in a while.

kwokcb avatar Aug 21 '23 12:08 kwokcb

OK, I understand now that the second example (myFile.mtlx) should not expose any parameters.

For the first example (marble), you're saying it's by design that only toplevel editable parameters are displayed in the UI?

My understanding was that all "open ends" in the toplevel graph are user editable. In the marble example that would mean that the inputs of the NG_marble1 nodegraph would be editable too - they even have uiname and uifolder specified. Or is it a choice per application if these are displayed as user editable or not?

hybridherbst avatar Aug 21 '23 13:08 hybridherbst

Your correct in your understanding. As noted it seems direct child inputs of nodegraphs are not showing up (appears to be a regression).

kwokcb avatar Aug 21 '23 13:08 kwokcb