Hey, this isn't technically Solaris, but eventually, the created geometry will be referenced into Solaris -

I'm unsure how one would go about creating a scatter to points setup in SOPs (pack and instance enabled) and exporting it's entirety from SOPs as a USD, which would then be referenced into the LOPs stage directly, correctly using point instancing out of the box.

What I would like to avoid is what i'm seeing in the tutorials i've found - creating the points with variation as one export in SOPs, and the source geometry as another separate import in SOPs, and then doing the actual instancing in Solaris with the instancer LOP - it feels like a more comfortable workflow for artists would be to work completely in SOPs, and just export a USD from there, avoiding jumping between the Stage and OBJ contexts.

Is this possible? I'm struggling to get this to correctly compose my scene graph on the stage, and i'm wondering whether i'm trying to do something that doesn't work within the logic of USD.


Any tips, or even "give up and just do it in LOPs" is welcome. Thanks in advance!

Do you specifically want to go SOPs -> USD -> LOPs? If you're happy to go straight SOPs -> LOPs, both the SOP Import and Scene Import LOPs can generate point instancers from packed prims.

Hey Rob, thanks for the example file, that helps know i'm on track.

I'm aiming more along the lines of SOPs > USD > LOPs for a couple of reasons (happy to hear any counter points of course)...
- Letting people work in SOPs as much as possible / not pushing people into LOPs at all if they don't need to be just yet.
- Working with the SOP create or doing a SOP Import / SOP Edit live in my LOP network seems to give me more crashes than if I don't.. I've sort of been conditioned to keep away from it after many frustrating crashes.


However, i'm happy to report that I've managed to get instancing working with geometry I made and exported in SOPs!. It seems to have come down to using relative paths (no leading "/") with my prototypes (and the SOP create node definitely helped me to quickly test stuff here).

The only real issue seems to be that I can't get it to create the prototypes in the scene graph in the same way that the LOPs instancer does. This issue applies to using the SOP create OR working in a SOP net and exporting out a usd from there.

I've attached two images to show what I mean - when creating in SOPs, it always wants to add the name attribute as a parent prim on top of my prototype's geometry path. Even if there's no name attribute, it just generates a generic obj_0 named prim as the parent. The LOP instancer seems to just not have to do this (I guess since it's not doing the same "attribute from pieces" workflow to scatter the different prototypes around?)

mrSmokey
I can't get it to create the prototypes in the scene graph in the same way that the LOPs instancer does ... it always wants to add the name attribute as a parent prim on top of my prototype's geometry path

The parent USD prim is the packed SOP "bucket of stuff". You're right that in your cube-or-sphere case it's unnecessary, but in other cases (for example if you're packing-and-instancing a cube-AND-sphere), then you need a USD prim to represent the aggregation. This would be true regardless whether you were using SOP Import or the Instancer LOP.

Ah, now that makes sense. Appreciate you taking the time to explain it with an example too, thanks!

Thinking a little deeper on this topic of outputting a USD from SOPs verses outputting a USD through LOPs (particularly with regards to instancing, and ignoring higher level concepts like payloads, purposes, materials) - can I generally assume that i'm always going to be able to author a more efficient/better composed USD through LOPs?


So although right now I might be aiming for a SOPs base instancing workflow, I should probably be aiming to move any and all instancing to LOPs as an end goal...

mrSmokey
can I generally assume that i'm always going to be able to author a more efficient/better composed USD through LOPs?

I'm not sure I would go *quite* that far ... or at least I'd drop "always".

With LOPs you're given more power and control to customise and tailor and optimise to your specific needs. This means you should have the opportunity to do at least as well (if not significantly better) as you would if you left everything in SOPs until the very last second ... but you also have the chance to shoot yourself in the foot.

Put differently, I would say "LOPs shouldn't be worse, and often yes will be better".

How and where different groups have thus far adopted Solaris has been driven by any number of motivations (be they technical, cultural, or other pragmatic concerns).

I believe that Solaris provides the best USD authoring environment, but that statement is of course just an island in an archipelago of aspects to running a successful CG/VFX pipeline.