Hello,
I wanted to ask if anybody could help me to interpret the composition behavior of the attached setup.
The goal is to have a variant ‘switch’ at the entry point usd (env.usda - ‘ENV’ prim) that switches to the respective variants of the referenced assets. There is a subtlety with respect to instanceable prims that I do not quite understand there.
The env.usda represents an environment setup and its references, where hierarchy.usda is defining the internal hierarchy. There are two important occurrences of the asset: B_001 is a direct reference, A_001 specializes a ‘source’ prim and is instanceable. The ‘instance_sources’ prim would be hidden in a production scenario.
If you switch the ‘shape’ variant from sphere to cube on the ‘ENV’ prim, you can see that ‘B_001’ and ‘source’ are changing, while A_001 stays the same.
This can be ‘fixed’ by moving the payload of the hierarchy out of the variant sets in env.usda (uncommenting line 11 and commenting lines 41 and 75). If you do that, you can see that all three are switching.
I would like to keep the hierarchy payload in the variant though because there might actually be two different hierarchy files or other nested variant sets to be taken into account.
I’m struggling to understand the decisive difference in the two compositions.
Could anybody please try to explain that to me (and possibly even give solution to that)?
Thanks a lot!
Marcel
Hi @mreinhard , so sorry for the delay here. I am seeking definite confirmation, because your setup is fairly different, and somewhat complex, but the key bits look quite similar to a problem our shading artists ran into in trying to build out their asset structure using specializes and a ton of shared libraries, variants, etc.
So, first off, when debugging composition problems, your first go to should be the “Composition” tab in usdview’s inspector - that’s what I used, here.
Now, make the variant switch at /Env. Then select /ENV/A_grp/A_001/source in the browser and go look in the “Composition” tab. You can see that the reference to asset.usda that provides a variant selection of “sphere” is stronger than the specialized “cube” variant selection in env.usda
So… that’s the “what”. The explanation for the “why” is not going to be as satisfying. Specializes is by far the most complicated composition arc, both in terms of its implementation (which we are hoping to simplify this year, which should address some known issues involving variantSets, but not this one), and in terms of how it interacts with other composition arcs, because it “violates” the otherwise lovely simple rule of recursive application of LIVRP (because at each level of nested recursion of layerStacks, the "S"s need to be “moved out” and gathered at the very end, after all the recursion unwinds.)
We were unable to find a restructuring algorithm that would yield “intuitive” results in all cases, and it turns out this construct (i.e. specializes is applied inside a variant) is the one that remains unintuitive - “fixing” it causes other, even more straightforward structures to behave in unexpected ways.
Our shading artists were able to accomplish their goals by doing precisely what you showed: moving the specializes just outside the variantSet in their compositions. You gave some reasonable reasons why this may not work for you; however I’m not able to suggest any other alternatives atm, as I don’t deeply grok your goals and constraints.
Thank you very much for this thorough and detailed explanation, @spiff !
It is really awesome to see that you are still trying to reply to every single topic.
This makes a lot of sense now and I think that I’ll be able to work around that.
Thanks again!
Marcel