Dear Friends!

Is it possible to use variants for different layouts efficiently? I mean I have a set of primitives under a root primitive and I would like to have different positions for these prims under different variants. The variant would only affect the positions of the prims of the set. (Think of `tidy room` vs `messy room`)

I can achieve this result with a simple setup of the `Add Variants to New Primitive` way, but then the resulting USD file has the primitives redefined in all variants. For heavy geometry this would be really ineffective.

If I try the `Add Variants to Existing Primitive` route I'm not even able to achieve this result. Usually I get into the `weaker opinion` forest, where I really doesn't know what's wrong and how should I fix it (I read the documentation, and `tried a different source primitive` with no luck. And honestly what other primitive?). The worst is that I don't understand what is happening and why. I'm very used to the fact that flexibility comes at the price of complexity, buy here I don't see that yet.

Could someone please explain me how this supposed to work, and why it works the way it does? Isn't variants are just layers? I can publish these changes as a sublayer but not as a variants? Why?

Thanks in advance,
Mate

Dear Friends!

Finally I worked it out and I learned a lot, so it might be useful if I jot down my experiences:

1. First of all: you can not override any parameter in a variant that is already defined locally on the primitive. Based on this I find it a bit misleading that Houdini suggests you yo chose another source primitive to sidestep this problem. The real solution is to not have that property defined in the first place. See the attached screenshot that I turned of the transform property generation on the box and sphere nodes to make it work. From the USD documentation it seems that attributes have a `Clear()` method to remove an already present property. That would be useful in this case, but I can't find a similar tool in Solaris. If you know of one please let me know!

2. If you don't want the geometry to be repeatedly included with the variants you should author your changes on empty primitives (possibly coming from a manifest as in my example).

With this two information bits in place a working example was pretty straightforward to make.

Best regards,
Mate

Glad you worked it out. You're correct that USD has to basically prioritize opinions, and it happens to be that opinions in the local layer stack "win" over everything else, including opinions that come from variants. Most lops nodes author opinions into the local layer stack, which in most cases is what you want. However in the case of creating variants its not ideal.

If you don't need a default/fallback value and will always have a variant selected you can just delete the opinion from the local layer stack as you found. If you do want a default/fallback value you have to put the opinion behind a reference or specializes. Both of those are weaker than variants and so the variant opinion will override like you want. I've tried to use the source option before and not had much luck so wound up creating the reference manually.

Thanks for further clarifying things!