UsdImaging unexpectedly honoring invalid material assignments over instancing

[asluk]

ref_mat_inst.zip

In the attached layer stack, geom.usda references an Xform containing a material, and has instanceable=true.

The cube mesh in geom.usda has a material assignment to the material inside the instance, which should be invalid/ignored, since that material path doesn't exist in the composed scenegraph.

Loading this up in usdview, the material assignment seems to be honored-- the authored diffuse color on the UsdPreviewSurface comes through. I would have expected on materials, since the material assignment path doesn't exist.

If you then use the interpreter to author diffuse color on the material directly via Sdf API on looks.usda , the render will not refresh, but if you reload, you'll see the new diffuse color.

It'd be great if the user received diagnostic feedback that this material assignment isn't valid, unless I'm missing something as to why this setup kind of "works".

Thanks for looking!

[jtran56]

Filed as internal issue #USD-6342

[spiffmon]

Hi @asluk ! What you are seeing is correct and expected behavior: instancing does not remove "namespace visibility" of its sub-prims, it only prevents their editing. In fact, you can even target composition arcs beneath instance roots (and that's one way of "editing" materials, per-instance, without breaking the instancing, though usdImaging does not yet support that: specialize one of an instance's materials to a prim outside the instance, and use collection-based bindings to rebind affected prims to target the specialized material.. it's not terribly elegant, but it should (eventually) work).

I'll let you close this if you agree?

PS. If you could make usdz's out of your examples, it will sanitize the references so we don't need to edit them.

[asluk]

Thanks @spiffmon ! Oops, sorry about the references-- good tip.

I don't fully understand specializes or what's missing in UsdImaging to support material editing, but I'll do some more digging on that.

One more q before I close this-- one of our devs tried to edit the instanced materials by also adding the referenced looks.usda as a sublayer of geom.usda, and setting the edit target to that. That is, editing the content from inside the reference, similar to what I did in the usdview interpreter by editing the referenced layer directly. I get that instanced content can't be overridden from the stage that is instancing them, but was surprised that instances also don't pick up changes from the referenced content itself.

Thanks again!

[spiffmon]

Two things:

1. Adding looks.usda as a subLayer of geom.usda to be able to edit it with an EditTarget may have unintended effects on your composition. There's currently a hard-out on editing with Proxy prims, but I think we should be able to make that be EditTarget-aware, so that if you target "across the reference" into "source layers for the prototype/master", we would allow that. But since we don't yet, and may not be able to prioritize that, the best practice for "editing masters" is to actually ensure that all the prims you may reference as instances inherit from one or more classes, which you will then be able to create and edit in geom.usda to affect the prototype/master.

2. While I don't know for sure one way or the other, I would not be surprised if usdImaging is not currently properly tracking the dependency of the non-instanced cube on the instanced material. If you place another cube inside the instance that is also bound to the same material, do changes propagate to that cube? It is also possible that we're not handling changes inside masters at all - please do file separate Issues for what you find!

[asluk]

Thanks @spiffmon -- I'll close this and file follow-ups as needed with my findings from your suggestions.