Hi, I'm trying to wrap my head around variants in Component Builder, and at the base level, everything works as described.

What I'm trying to figure out is how do you effectively manage an asset that can have several branching variations?

The example I am working with is a chair. It can come in the following configurations:

Armrests: None, Type 1, Type 2
Wheels: 4 wheels, 5 wheels, Glides

With an HDA, I can sort this in a single SOP network, with 2 drop-down menus structured like this:



With the Component Builder, it would seem that I need to create 9 separate Component Geometry LOPs, and result in 9 different menu items for the user to select from?

1. No armrests, on 4 wheels
   
2. No armrests, on 5 wheels
   
3. No armrests, on glides
   
4. Armrests type 1, on 4 wheels
   
5. Armrests type 1, on 5 wheels
   
6. Armrests type 1, on glides
   
7. Armrests type 2, on 4 wheels
   
8. Armrests type 2, on 5 wheels
   
9. Armrests type 2, on glides
   

This does not seem very efficient or scalable, nor is it a nice experience to have to read from a list of similarly named items, and I'm hoping that there is a better way to organise this. Thanks.

You would setup your custom variants as Add Variant blocks to the Component Geometry Variants node, or you can use Add Variant blocks to add your own variants. If you have multiple variant sets, generally in production and asset would have a "model" or other variant that just makes variant selections on the other variant sets.

So the "A" model variant might set armrests to type 1, and wheels to 4; then "B" model variant would set armrests to 2, wheels to 5; and so on...

Does that make sense? You could use the Component Geometry Variants as that top level control; each input to the Component Geometry Variants would be a Set Variant node, which makes the variant selections for the wheels, armrests, etc...

If you're finding the Component Builder nodes too restricting, you can switch the Component Output's mode to "Input Primitives". Input Primitives mode is meant to let you keep using the conveniences of the Output node, but have more control on what's going on inside.

goldleaf
You would setup your custom variants as Add Variant blocks to the Component Geometry Variants node, or you can use Add Variant blocks to add your own variants. If you have multiple variant sets, generally in production and asset would have a "model" or other variant that just makes variant selections on the other variant sets.

So the "A" model variant might set armrests to type 1, and wheels to 4; then "B" model variant would set armrests to 2, wheels to 5; and so on...

Does that make sense? You could use the Component Geometry Variants as that top level control; each input to the Component Geometry Variants would be a Set Variant node, which makes the variant selections for the wheels, armrests, etc...

If you're finding the Component Builder nodes too restricting, you can switch the Component Output's mode to "Input Primitives". Input Primitives mode is meant to let you keep using the conveniences of the Output node, but have more control on what's going on inside.

Hi, to be perfectly honest, I don't understand what exactly it is you're describing.

I have attached a scene file with 2 variants of the chair I was describing (built into the same Component Geometry LOP, with different name attributes).

I'm trying to find a way to specify each "name" from SOPs as a different variant, but I don't know how that ties in with the Component Geometry LOP and how I would define proxies for each variant without needing multiple Component Geometry LOPs.

Any help deciphering this would be much appreciated, thanks.

I think I'm making some progress. The Intro to LOPs (barrel) tutorial has helped a bit (link [www.sidefx.com]).

While this approach (screenshot below) does ameliorate the pain of separate Component Geometry LOPs for each variant, it still does not address the clunkiness of a monolithic list of variants that will need to be presented to the user.

In the above scenario, I described 9 variants. If I add just one more boolean variable into the mix (say Neck Rest yes/no), the number of variants go to 18. Is there something in the works to help us build a more sane variant selector rather than just an ever-expanding list?

The drop-down menu structure that I described would work well, as would having toggle switches for variant options (again for e.g. Neck Rest? Yes/No).