Binding a material to an externally referenced part.usd

Community USD
1

Hello,

I have a shattered file structure as pictured below. The uid.usd references parts in the subfolder uid. Each part’s meshes need to have a material binded to them. My issue is when we bind a material that lives in uid.usd to a mesh in uid/part1.usd the reference becomes broken when loading the stage uid.usd. Is there a way to properly reference these materials? I also have the materials defined in the part.usd files and when loading these individually I can see the material applied properly.

├── uid.usd
└── uid
    ├── part1.usd
    ├── part2.usd
    ├── part3.usd
    ├── part4.usd
    └── part5.usd

Thank you,
Evan

2

Hi Evan,
do you have an example file to repro the issue for better understand the type of binding and the composition arcs at play ?
And are you wanting to have this running on recent/latest OpenUSD versions or are you locked on a specific version ?
Cheers,
Paolo

3

Hello Paolo, thank you for the reply. Yes, here is an example of a shattered file where materials work when loading the part files but not when loading the assembly file (uid.usd from my illustration). I guess the issue here is we cannot override materials on the part level (xforms that have meshes beneath them) in the uid.usd file because our materials are per mesh and not per part. Let me know if you have other questions.

Thanks in advance,
Evan

fishing_reel.zip (154.4 KB)

4

Yes, you identified the problem, @evanburkert . If one prim in a layer contains a relationship or connection to another prim in the layer, then you can only safely reference a common ancestor of the two prims, so that USD has enough information to “remap” the relationship target into the referencer’s namespace. This is a common pitfall of “sub-root referencing” (like you are doing) and even just organizing an asset with separate </Geometry> and </Materials> scopes.

As you’ve noted, there’s no visible problem when viewing the asset in isolation, and TBH, USD provides alot of powerful features that can be used to solve tricky production (and other) problems, but not so many guardrails that prevent inadvertent misuse. With an official validation framework coming online, it will be easier for us and others (e.g. ASWF wg-usd-assets) to provide validation suites that can point out such potentially problematic constructs.

At Pixar, our only sanctioned “parts assembling” asset structure references entire models into/under another model’s </Model/Geom> scope, so that not only all its geometry, but also its Materials, come in as a unit. We haven’t solved the “pull out individual mehses without losing their materials” problem.

The only thing I can offer, which is not awesome, is that even though all the material bindings are broken in fish.usd, I see that you have re-established Materials in that layer, and you can rebind your meshes as overrides in that layer.