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.

what about for crowd sims, how do we instance them in lops properly?

hassancharafeddine87
what about for crowd sims, how do we instance them in lops properly?

The simple answer is to just use the SOP Crowd Import LOP (which is a wrapper around SOP Import with good defaults for importing a crowd sequence). This translates the agents into UsdSkel prims with as much scene graph instancing as possible, with a structure along the lines of https://openusd.org/dev/api/_usd_skel__instancing.html [openusd.org]

There is less instancing on the Hydra (rendering) side of things, however, so the viewport currently isn't able to do instanced GPU skinning like the SOP viewport is able to.

The Crowd Procedural LOP can also be very useful for renderers such as Karma, to convert background agents into instances of the same deformed geometry where it's safe to do so without visual artifacts. This is the same idea as the agent procedural that Mantra had enabled by default

I'm Using the crowd Import sop and crowd procedural nodes, but I thought something was wrong, because the color of the instances was gray, and usually usdskel instances are blue in the graph, also I'm new to solaris but the speed of my crowds isn't as fast as sops idk if this is normal?

If it's the "Visualize Instances" option on the crowd procedural you're referring to, then that would mean that none of the SkelRoot's will be instancing the same deformed geometry (there are also some stats about this in the render log, if verbose logging is enabled)
You could try adjusting the tolerance parameter to see what effect it has

thanks cwhite this is definitely faster but is there a way to make it as fast as sop during viewport playback in solaris? also notice that the agents are gray but the geometry is blue even thought in it's supposed to be instanced USDskel, maybe it is and in the new version it doesn't show the legend as blue?

If it's the scene graph details pane you're referring to, that's expected because each agent has its own unique `SkelAnimation` prim (which describes its pose), while the 'geometry' child prim is instanced since it contains the rest geometry that's shared between the agents

The viewport playback is not currently expected to be as fast as the SOP viewport, due to the lack of instanced GPU skinning when rendering through Hydra that I mentioned in the other comment.