Ambiguity of nodes with omitted inputs about materialx HOT 11 OPEN

@ld-kerley that's just how we tend to author things in Houdini, as it helps reduce future updates from changing things unexpectedly.

from materialx.

I was experimenting a little with Houdini 20, exporting MaterialX files, and it appears that SideFX get around this problem by always writing all of the <input> tags on each node - which leads to a larger than necessary mtlx file, but removes the ambiguity.

Tagging @crydalch incase he has any insight here.

from materialx.

Another way to remove the ambiguity is to write out the nodedef=<> attribute on the node which I believe is similar to what is done for USD with info:id but this doesn't solve the issue.

BTW, I remember that this issue occurred with other ambiguous signatures and the result was to change the node category so it not both mix so it's mix_float vs mix_color or something like that.

from materialx.

@kwokcb In this case, the ability to overload generic nodes such as mix and add is an important feature that we want to preserve in MaterialX, so that graph editors can support dynamic resolution of nodes based on the typed data to which an artist connects them.

As @ld-kerley notes, though, it seems valuable for all MaterialX tools to resolve to identical nodes when typed inputs have been omitted from a graph, and this seems like an area where we can be more precise in the MaterialX API and documentation. Would it make sense to impose a rule that the first matching node definition in the data libraries must be used when multiple matches are present? We could then validate that the MaterialX API and example applications always provide this behavior, making any required changes to the codebase to ensure this.

from materialx.

from materialx.

It is quite possible to have order change as it does depend on definition load order which can include target order and namespace order.

There are signatures with the exact same number of input parameters (as in this example). Also you could have the same matching "score". Als in this example, the definitions each have 3 inputs -- 1 which the differentiating input (float vs color3), but the node instance does not override the differentiating input.

There is already a mechanism to return "first" and an "exact" match option + logic which scans all inputs when trying to determine what definition matches.

My feeling is to try to avoid complex "matching" rules to be followed if there is ambiguity by either returning all matches and let the integration handle it properly, or just fail. I'm leaning towards the latter.

As noted in Slack, I'd still like to propose that if there are 2 or more nodefefs with differentiating inputs that must be specified that there is some meta-data to mark them as such. Then if it's missing then a failure condition can be easily found, both at creation time and at validation or definition matching time.
e.g. adding a required tag.

 <nodedef name="ND_mix_color3" node="mix" nodegroup="compositing">
    <input name="fg" type="color3" value="0.0, 0.0, 0.0" />
    <input name="bg" type="color3" value="0.0, 0.0, 0.0" />
    <input name="mix" type="float" value="0.0" uisoftmin="0.0" uisoftmax="1.0" required="true"/>
    <output name="out" type="color3" defaultinput="bg" />
  </nodedef>
  <nodedef name="ND_mix_color3_color3" node="mix" nodegroup="compositing">
    <input name="fg" type="color3" value="0.0, 0.0, 0.0" />
    <input name="bg" type="color3" value="0.0, 0.0, 0.0" />
    <input name="mix" type="color3" value="0.0, 0.0, 0.0" uisoftmin="0,0,0" uisoftmax="1,1,1" required="true"/>
    <output name="out" type="color3" defaultinput="bg" />
  </nodedef>

from materialx.

from materialx.

@kwokcb Just to provide additional motivation for the development of rigorous matching rules, it's worth noting that marking inputs as "required" would not be sufficient to resolve this issue, as we'd still need a rigorous set of matching rules to handle documents that omit the input anyway (e.g. legacy documents). While we can make sure documents in this state emit validation warnings, we still need to generate valid shading code in every language from these documents, and rigorous precedence rules will still be required.

@dbsmythe I'm open to any simple set of rules that fixes the order in which matching definitions should be considered, though it would be ideal if our existing set of MaterialX attributes is sufficient to resolve all cases, as opposed to requiring new attributes to create order.

Giving precedence to the simplest data type (e.g. float > color3 > color4) is one valid option, though selecting the first matching node might be easier for MaterialX integrations to support, and it would give pipeline developers more control over whether their custom nodes are intended to take precedence over the standard set. Just to give a real-world example, some pipeline developers will intentionally replace shading models such as standard_surface with their own custom interfaces, and in this case they will likely take control over the library import order to ensure that their version takes precedence over the standard one.

from materialx.

About allowing invalid documents still generate code. I’ve always found this to be ambiguous since some validation failures can still allow generation to continue but others do not. In this case it still feels wrong to make a calculated guess as to what is the correct definition to use. At the time of usage there should be no ambiguity. This still allows for a node to be created without a unique signature but it’s very possible to guess one signature and then have code which sets an input be nonambiguous afterwards. In this the wrong definition is created and the subsequent input setting will fail.

from materialx.

In order to keep this discussion focused, it may help to provide a concrete example to discuss, and I'll choose this one from the standard_surface_brick_procedural.mtlx example in our repository:

This clamp node is technically ambiguous, as its low and high inputs have not been stated, so they could either be 0.0 and 1.0, or they could be 0.0, 0.0, 0.0 and 1.0, 1.0, 1.0, depending on which nodedef is selected at runtime.

Following the design of the MaterialX standard libraries, though, it's important to note that this selection has no effect on rendered visuals, as these two interpretations generate identical results. This is an intentional design choice rather than an accident, and my recommendation would be to lean into this design principle, making it clear in our specification that nodes with multiple overlapping signatures are expected to generate identical visuals.

We can still provide a recommended order in which nodedefs are matched to nodes, as this will be valuable for the USD use case that originally motivated this thread, but we don't need to make ambiguous nodes such as the example above invalid in documents.

from materialx.

I wanted to highlight #1753, which addresses an inconsistency in our NodeDef lookups across compilers, without changing the expectation of declaration order in the current codebase.

I'll leave this GitHub Issue open, so that we can discuss what order for NodeDef lookups would be ideal, and the recent fix should give us a more consistent baseline to build upon.

from materialx.