Hello,

I have a question regarding a type of “dynamic” material assignment setup that're we're trying to achieve.
I'm completely new to Solaris and USD in general so please excuse my lack of correct terminology, I'll try and explain what we're trying to do from a pipeline perspective.

Essentially we're tying to produce a setup where we have our materials and their assignments written out into a USD file which is independent from any geometry and version controlled.

Then in another network, referencing in that USD file and have that added to the scene graph with the assignments still in place.

Giving us a setup where we have the geometry and materials + their assignments in separate, version controlled, files, which are each referenced into a new scene and “combined” (grafted?) together (with a final USD write happening at the end of the network).

Is this possible? Would there be a better way to achieve something like this?

Any help is greatly appreciated!

Thanks for your time!
Jake

Hey Jake,

not sure if what you try to achieve / describe is possible. As far as I know, in order to assign a material, you need to have both the material and the primitive it goes onto present in the scene graph.

What you could work I think is saving the materials out in one file “materials.usd” and then have a layer for material assignment “material_assignment.usd”. that you can sublayer in again later down the line.

empty scene
sublayer / reference your models into the scene
reference your materials into the scene (“materials.usd”)
layer break (all edits from now onwards are on a fresh layer)
assingn all the materials
configure layer (“material_assignment.usd”) This will then (if my theory is correct) only contain material assignments.
USD ROP -> save your final result / layout (“layout.usd”).

Its not in one file as you requested, but might still be a solution that could work. You can update and version-track both files and it should work further down the line.

As an alternative to get all in one file (that might work but sounds tricky): Jeff showed how to use a anttribute wrangle to store a string comment on a material as attribute in his Houdini Hive Worldwide Asset Prep for Solaris talk (https://youtu.be/DI09YJLZ_6k?t=4863). Maybe you can use that workflow to store the material assignment information directly on the material and read it back further down the line when the materials need to be assigned. But that sounds over-complicated and I also have no idea how/if that even works. He also shows how to export materials to a separate file there if that helps.

I hope this still helps a bit, eventhough I couldn't fully answer your question. I am also still learning, so we are all in the same boat! All the best!

jake0
Then in another network, referencing in that USD file and have that added to the scene graph with the assignments still in place.

You could leverage the USD layering. Eg, save the material assignment in a .usd layer, and then reference that layer on top of the geometry layer (which can contain new geometry data). As long as the primitive paths match, the composed stage will have these material assignments.

There's nothing preventing storing materials and assignments in the same layer (file).

However, it might still be desirable to store them separately.

Thanks a lot for the replies all, very much appreciated.

It sounds promising, there's a few tricks in there I'm yet to try I think. So I'll give this and go a see if I can solve this.
I'm assuming my issue might be with the prim paths being slightly off or something.

I believe the issues I'm having maybe due to building up the hierarchy in one way, then that being slightly different once layered in. I have tried testing it manually with code.. writing a bunch of “over”s with the same prim paths down and then doing the material assign, but with no luck. Very much guess work at that point though

I'll keep trying with this new info.

Thanks again!

Jake

I would love to know if there was a good solution found to this. I’m a bit unsure how to approach this problem too. I either have to:

- Guarantee that the structure of the USD hierarchy will stay the same between the Model/Lookdev step (simpler scenes) to the lighting step (more complex scene) and this feels kind of restrictive. Artists will need to constantly think ahead to how they want to structure their lighting scenes when working in earlier pipeline steps.

- Don’t merge the asset components together into a single hierarchy, so that its components are split between /geometry and /materials at scene root. Not so bad really but it seems messier, and means we can’t live the dream of having everything related to an asset packaged beneath its own hierarchy

- ***Ideal but maybe not possible?*** Have primitive paths (for materials, assignments, collections) function relative to the asset “Top” (ie. the highest parent Group of the asset being worked on) so that if the asset is moved around in the hierarchy down the pipe, the collections or assignments are stable = I have no idea how to do this.

Perhaps all of these can be solved by referencing in USD?
https://graphics.pixar.com/usd/docs/USD-Glossary.html#USDGlossary-References [graphics.pixar.com]

1) You don't need to guarantee the structure right away. You can "reference in" particular primitives (eg, a geometry, a material), into the final structure later on.
2) Again, you can package everything later on into its own hierarchy by "referencing in" the primitives you want to have under that hierarchy
3) Once you have the "top" primitive set up along with all the childern and descendents, you can "reference in" that top primitive into a particular location in the final hierarchy.

Hey rafal thanks for the reply! Doing a simple test where I have a single, non branching network, I can see the relative material paths and assignments seem to work.

It’s when I try to “break out” each pipeline step into it’s own USD that things don’t work as well - I am aiming for every step to have its component living at scene root when I write it out to a USD file. I then reference that USD file in to a higher level “package” network/stage which puts the components together into something living under a top primitive “assetName”.

So for example
/geometry
output as its own usd by the modeller, is referenced in to the larger asset structure to become
/assetName/geometry
And same for materials
/materials
/assetName/materials

However, the assign materials doesn’t seem to like me doing this. I would ideally like the option of a lookdev artist to do their lookdev in their own working hip file (after referencing the asset “package” in) and then output their materials + assignments to a separate USD. I use a layer break before the material nodes to ensure only the /materials component hierarchy is written out, since of course I don’t want to include geo in the materials.usd

But the material assignments don’t seem to get resolved when I reference the materials.usd into the top level asset “package.

I'm not 100% sure this is the problem, but I suspect you are hitting the fact that files that are "referenced" onto a stage can't "see" anything outside the file being referenced. So multiple referenced in layers can't affect each other at all. The material assignment (which needs to know about both the geometry and the material prims) has to live "above" the material and geometry references. Alternatively, you can build your assets by sublayering the geometry and material USD files together (using path naming conventions to ensure that the prims end up in their right places). Sublayered files can affect each other, so with sublayering you can put your materials and the material assignments into the same file.

Thanks mtucker, sublayering a USD file containing both the materials + assignments seems to work from the quick test I just did, so it points to that being the issue.

So it seems like I just can’t bring in materials + assignments as a reference, and this is just due to the logic of how USD layers work?