Hi
Im wondering what would be the correct workflow for:

1- SOP:> Create a piece of geometry like a rock (easy, sphere->mountain, with attribute from PDG, say `@amountOfHeight`)
2- TOPs:> Have a topnet that does wedges of it (easy, wedge setting up that attribute `@amountOfHeight`)and a waitForAll and a ROPusd pointing to a lops network:

3- LOPs, this is where Im stuck:

- sopImport-> pointing to just the base sphere, as a base asset, no mountain effect.
- Im guessing an addVariantToExistingPrimitive loop, with a addVariant node inside (the sphere above).
- point `pdg_input.N` somerewhere so that the addVariant can read the generated wedges.

I guess the simplest question would be how to load each of the resulting wedges from pdg as a variant in that loop, so I can set this up?

Encapsulating pdg results as usd variants would be quite nice, as then we could automate asset processing for usd using pdg..

Any thoughts/examples?

thanks in advance!

Hi, check out the attached hip file. It sets wedge geometry as LOP variants, using the `foreach` block to iterate over @partitionsize wedges.

This is great!

Quite interesting use of context. I would live to see this further documented, I couldn’t find many references, unless I probably missed it.

Anyhow this is great, is there a way to do the same without baking any geometry to disk as an intermediary process ?

Since this geometry is wedged on the fly, it would be great to generate the usda file directly. Does this make sense ?

Yes I think so, you could do that by using a ROP USD instead of a ROP Geometry Output TOP following the Wedge.

In that case you would be wedging out a LOP network which uses the SOP Import LOP to pull the geometry from sops. And then in the final ROP USD you would need to probably load each variant USD and reference it in the variant for each loop.

Thanks Chris, this is brilliant. I managed to do it by writing usds from component builder with proxies and all.