<materialassign> elements not processed in-order in MaterialXView

[pablode]

The spec says on p. 71 in "MaterialAssign Elements" that "assign declarations should be processed in the order they appear in the file, and if any geometry appears in multiple <materialassign>s, the last <materialassign> wins".

However, this behaviour can not be observed in MaterialXView.

To reproduce, load the shaderball.glb geometry and following document:

<?xml version="1.0"?>
<materialx version="1.38">

  <standard_surface name="SR_red" type="surfaceshader">
    <input name="base_color" type="color3" value="1, 0, 0" />
  </standard_surface>
  <surfacematerial name="Red" type="material">
    <input name="surfaceshader" type="surfaceshader" nodename="SR_red" />
  </surfacematerial>

  <standard_surface name="SR_blue" type="surfaceshader">
    <input name="base_color" type="color3" value="0, 0, 1" />
  </standard_surface>
  <surfacematerial name="Blue" type="material">
    <input name="surfaceshader" type="surfaceshader" nodename="SR_blue" />
  </surfacematerial>

  <look name="Look">
    <materialassign name="Blue_P" geom="/Preview_Mesh" material="Blue" />
    <materialassign name="Red_P" geom="/Preview_Mesh" material="Red" />
    <materialassign name="Blue_C" geom="/Calibration_Mesh" material="Blue" />
    <materialassign name="Red_C" geom="/Calibration_Mesh" material="Red" />
  </look>

</materialx>

The Blue material is assigned, but it should be Red.

[kwokcb]

Good catch @pablode . This was fixed for the Web viewer but I guess the desktop version needs some tweaking.
It's probably worthwhile to avoid these configs for compatibility and as look support become supplemental going forward (as USD assume responsibility for lookdev assignment logic).

[kwokcb]

I did an experiment with this, but would want to discuss this with @jstone-lucasfilm when he's back. The actual look logic is correct but it's been re-ordered based on material first. I'll leave it as is for now as I don't have bandwidth to look at this any more.

The combined code for this and the #1109 issue can be found here (branch of a branch)
kwokcb#30

[jstone-lucasfilm]

Thanks for reporting this issue, @pablode, as well as to @kwokcb for the fix in #1113.

[kwokcb]

@jstone-lucasfilm, actually #1113 only fixes parenting. Desktop ordering was not fixed, though it works on web. New PR is up for this, but there are no udim tests so please have a look as I'm unsure if this change has any side-effects. Thanks.