Rob Pieké

frame_48
With this current approach as I understand it you would need to have every single pipe plugged into the switch match in the amount of primitives and operations correct?

It depends on what you're trying to do. If you want to have a Switch choose between three different animations for a common object/character, then yes the USD Attributes need to be identically named so as to be compatible for stitching. If you want to have a Switch choose between a sphere or a box or a cube, then no ... Solaris has some handy tech in the Cache and USD ROP to "track primitive existence to set visibility".

Thanks for the updated scene file. Your approach is conceptually very sensible, but it unfortunately runs into multiple problems.

If you're not interested in the technical details (and I don't blame you if that's the case), I'm attaching a v3 of the scene which should work for you, along with some sticky notes on that changes required to the Edit nodes and the use of a Timeshift LOP.

Okay, now the details.....

The USD ROP, when writing out a multi-frame USD file, needs to stitch together each frame's stage into a single stage containing all the data across all the frames.

A slight aside: the Cache LOP (in "Cache All Frames" mode) does this as well, and is the first debugging tool I usually reach for in cases like yours where you have animation going through a Switch that doesn't survive when writing to disk. The Cache LOP will catch a number of issues (details to follow) and report them as warnings, whereas the USD ROP doesn't (and I'm going to look into why).

For the stitching to work, we only stitch together layers that are "the same". Because you have a Layer Break just before you fan-out and put down the Edit LOPs, each Edit LOP is starting its own new layer and there's nothing that immediately ties these layers together. This is later resolved by your Configure LOP specifying a consistent Save Path. I explicitly call this out because if you use a Cache LOP for debugging, if you put the Cache LOP *above* the Configure Layer, it won't stitch together the three layers because it can't tell they're the same. It'll just stack them instead, which is legitimate and not a warning/error. If you put the Cache LOP *after* the Configure Layer, however, it will recognise these layers as something we want to stitch together, and then you'll start to get more useful warnings. Starting with...

For the stitching to work at an attribute level, we need the attributes to be consistently named from frame to frame. In your setup, however, the Edit LOPs are each generating transforms with the description "$OS" (i.e., "edit1", "edit2", "edit3"), which means they're not compatible for stitching. What *is* still consistently-named in your setup, however, is the "xformOpOrder" attribute (which lists the order of transformations to apply). It is authored as a default value, and is changing (i.e., when the Switch goes through the first input, the value will be |"transform", "edit1"|, and when it goes through the second input, the value will be |"transform", "edit2"|). This is something the Cache LOP will detect and give a warning for. Changing them to something consistent (e.g., "myEditXform") fixes this. But we're not done...

For the stitching to work at an attribute level, we expect animated data to be generated using time samples. In your setup, however, the transforms generated by the Edit LOP are not time-sampled but, rather, authored as default values. This is something the Cache LOP will detect (i.e., the transforms are animated default values) and give a warning for. Working around this basically means either not using the Edit LOP, or using a Timeshift LOP after the Switch to convert default values into time samples (you can look at the attached hip file to see how it's done).

I think the main takeaways here should be:
1 - Be very careful when using a time-varying Switch LOP ... there are lots of ways it can fail later in the pipeline
2 - Learn to love the Cache LOP as a debugging tool

Hope this helps you (and other readers). I can only apologise that so much technical knowledge is required to make something this conceptually simple work properly.

Referencing prototypes outside the instancer is still an open RFE for us. Part of our hesitation in rushing ahead to support this is that there are problems when going down this road in a Hydra 2 pipeline - https://github.com/PixarAnimationStudios/OpenUSD/issues/3011 [github.com]

The sample USD snippet there answers the question of "is there a way to hide the original primitive prototype without hiding the point instancer?" - you hide the parent of the prototype.