Can I fake out Reference / Layer Composition?

Community USD
,
1

I keep making this mistake when setting up my layers, but I’m having trouble figuring out how to do it the right way.

Basically(I’m going to try to simplify the hierarchy just to get to the essence of my mistake/problem), I have a layer generated by a 3rd party crowd tool. Sorry this isn’t the USD xml, but I’m hoping it’s enough to get the concept across:

Let’s call this the “crowd” layer. (This is actually done in a loading procedural/plugin, but the is effectively the USD produced)

root

\___member1

    \___asset_a (includes attribute points with animation in position)

\___member2

    \___asset_a (includes attribute points for meshes in another position)

And my top layer is basically a “crowd_wrapper” layer:

root - payload "crowd" layer

(that payloading is non-negotiable - that is basically how the 3rd party tool delivers it.)

And bottom layer is essentially a rough layout::

root

\___member1

    \___asset_a (reference includes materials and geometry with attribute points in neutral)

\___member2

    \___asset_a (reference includes materials and geometry with attribute points in neutral)

So my intent here was that I author the bottom layer to be all the assets in the hierarchy in their neutral positions, and this would include the materials.

Then I use the top layer to override the points attribute for the positions of the asset_a members.

So then sublayer top over bottom and I think I’m done!

Wellll… not quite. Those more experienced people probably saw my mistake immediately.

My mistake is I keep thinking in terms of resolving the individual top and bottom layers, then sublayering top over bottom.

And it’s really more the reverse that happens. The L first get resolved, then I’ve got the crowd payload up on the root, and the individual neutral asset references deeper down on the asset_a. So when they’re resolved, the deeper reference is winning, and my crowd scene has everyone in their neutral position. Yeah, I keep thinking I know LIVERPS, but I keep making this mistake.

So I’m trying to figure out what is the right way to do what I’m trying to do? I’m hoping there’s some combination of nesting references and sublayers that will get the resolution order I’m trying to get, but I’m not optimistic.

I’m constrained with the “crowd” and “crowd_wrapper” layers, as those are basically provided from the 3rd party tool.

The only think I can think of now is something like this, that doesn’t use sublayer, but basically makes it all a reference arc:

root

\___member1

    \___asset_a (

        - reference /root/memeber1/asset_a prim of crowd_wrapper layer

         - reference includes materials and geometry with attribute points in neutral)

\___member2

    \___asset_a (

        - reference /root/member2/asset_a prim of "crowd_wrapper" layer

         - reference includes materials and geometry with attribute points in neutral)

I don’t know why, but I don’t like it. Like I worry that for each individual member reference, the crowd procedural might re-evaluate the entire crowd. But is that what I need to do?

Is there any way to force the resolution of the top and bottom(or at least the bottom) layers before the sublayer resolution?

2

So it looks like to address the problem above, we can forget about the sublayers and basically

prepend reference top, bottom.

so within the reference, it’s effectively layering.

Unfortunately, because of other details of our implementation that I left out, there are other issues/disadvantages where it’s not the clear solution for us. But I wanted to mention what did seem to address the problem I stated above.

3

Yeah, the lower-strength of ancestral prim arc contributions is not really discussed in our summarized explanation of LIVERPS, but is vital for understanding, and is inviolable. IT is, at least, in keeping with how you’d think of inheriting properties (like primvars) down the namespace hierarchy: ancestral opinions are always weaker than more “direct” ones to the prim that is being interrogated.

Regarding your concern about your first proposed solution (which is the only other thing I can think of also), I’d be pretty surprised if the vendor would be reexecuting the procedural for each asset. Despite all the individual references, they are all targeting the same loaded SdfLayer (backed by the vendor’s FileFormat). In either layer structure, the client (renderer) will be asking for data about different agents at different times - which is exactly what the composition engine would be doing in processing the multitude-of-references. So if that scenario triggers a reexecution, so would rendering. I’d expect them to be either lazy, per-agent, with a managed cache, or evaluating and caching everything up front.

1 Like
4

I’m not 100% sure that what I outlined above would trigger the whole re-evaluation - haven’t actually tried it.

But we’ve asked before if they could structure it differently, to payload each entity instead of just payloading the whole thing, and that’s when they told us each individual payload would evaluate the entire thing. Though… that is different, so maybe it would be worth it for us to try that out. Maybe next week…

Right now, I think we’re going to try the second try (in my second comment) - basically doing everything through referencing arcs instead of sublayer. There’s something specific to our implementation that we’re blocked from doing, but it sounds like we’re going to live with it. Our actual use case is a little more complicated with more internal references happening, but I’m not going into detail just to focus on the above issue.

>sigh< I guess I knew we were trying to violate LIVERPS but just needed it confirmed.

5

OK, well, please let the vendor know they can reach out to us to strategize about how to make the plugin flexible to pipeline referencing needs.