Stage variables when instancing

Community USD
1

We have a scenario similar to this example described here, where we have some global stage variables controlling variant sets on a geometry:

https://openusd.org/release/user_guides/variable_expressions.html#flexible-variant-selections

Now, we want to instance this geometry multiple times in a scene, with each instance having it’s own variant selections and I’m not sure how to do this with stage variables.

Shot.usd

#usda 1.0
(
    expressionVariables = {
        string COLOR_GROUP_1 = "rainbow"
        string COLOR_GROUP_2 = "monochrome"
    }
)

def "Crowd_1" (references = @Crowd.usd@</Crowd>)
{
}

def "Crowd_2" (references = @Crowd.usd@</Crowd>)
{
}

Both references here share the same expression variables, so they’ll have exactly the same variant selections.

It seems we can get around this with creating an intermediate layer for each reference, but this will require O(N) such layers.

Shot.usd

#usda 1.0

def "Crowd_1" (references = @Crowd_1.usd@</Crowd>)
{
}

def "Crowd_2" (references = @Crowd_2.usd@</Crowd>)
{
}

Crowd_1.usd

#usda 1.0
(
    expressionVariables = {
        string COLOR_GROUP_1 = "rainbow"
        string COLOR_GROUP_2 = "monochrome"
    }
)

def "Crowd" (references = @Crowd.usd@</Crowd>)
{
}

This doesn’t scale when we have thousands of these instances. Is there anyway to have a scope for expression variables so we can pass one set to Crowd_1 and another set to Crowd_2, without needing an intermediate layer?

2

Hi @alantang , hmmm… I don’t think expression variables are really the right tool, here. Expression variables are best at configuring a scene from one of a set of optional configurations, in broad strokes. Because you can only vary them across references, in the targeted layer, they are not really a good match for set/scene-dressing where you are trying to scatter variation.

I can’t think of a better way to scatter variation among instances in USD than simply making a variant selection(s) on each instance as you are dressing/scattering it, i.e. where you add the reference. (and just to state it: the referenced asset can contain a variant selection keyed to an expression variable, and this will still work - the explicit selection that you author on the referencing side will just override that expression-based selection)

If somebody finds a cleverer way, I’d love to hear about it!

3

Thanks for the answer.

In essence, the problem I’m trying to solve is that I want to be able to use a large collection of assets, and I do not want asset authors to be constrained to a fixed prim hierarchy. I want to establish some protocol between the referrer and the referenced asset so that the referrer can scatter variation.

I thought that expression variables could be this protocol, but it’s obvious now that we run into multi-instancing problems.

The other thing I’ve been considering is collections. The referenced asset is free to have any prim hierarchy as long as the root prim defines several known collections. This works for material bindings, but what I really want to do is to make variant selections on the collections.

A collection-based variation selection schema would be super helpful here although I don’t know if this fits within the whole USD composition paradigm.

4

Hi @alantang , I’m sorry, I’m having a little trouble envisioning what a “collection-based variation selection schema” would be.

But more fundamentally, I’m still not understanding where variantSets published in assets falls down for you? Each variant of a variantSet can have completely different contents, so I think it satisfies your desire to give asset authors flexibility with prim hierarchy in each variant of an asset. And then your dressing of variation (referrer) is simply scattering variant selections over your instances; you can vary shading and geometry independently through the use of collection-based material bindings, as you hinted at, or you can also nest the variantSets to craft compatible pairings. It would be helpful if you could describe what this doesn’t capture!

5

If we go back to my example with the crowds, let’s suppose a crowd can have an arbitrary number of instances of people. Each instance of people have some known variant set called “color”. Furthermore, the people can be anywhere in the hierarchy of crowd.

def "Person" (
  add variantSets = ["color"]
) ...

Let’s say we want all the people in the crowd to share the same color variant selection. We wouldn’t want to do this at shot level. That would break the abstraction. So we introduce a variant set in crowd that merely forwards variant selections to the people instances.

def "Crowd" (
  add variantSets = ["color"]
) {
  variantSet "color" = {
    "red" {
      over "Person_1" (
        variants = {
          string color = "red"
        }
      }
    ) ...
  }
}

But this requires every color variant to have overs for O(N) person instances. It would be nice to use collections to just “search” a crowd for people instances and then set the variant selection for the entire collection.

I think the complicating factor might be that variants can be used as conditionals in a membership expression. It would then be possible to use a collection based variant selection schema to take a prim out of the collection membership, making the composition inconsistent.