Is it possible to have multiple Instance LOPs pointing to the one set of Prototypes?
Currently, because the Prototypes are parented beneath the Instancer Prim in the Scene Graph Tree, to access the same source prototypes, you need to plug the same source assets into a new Instancer - which then creates its own Prototypes prim and puts the source assets beneath it.

This (I believe) leads to duplication of the source Prototype assets in RAM. Can anyone confirm if this will duplicate in RAM? Or is it smart enough to look into the current USD data and see that it's already stored the Prototype assets used in InstancerA and not load it again for InstancerB?

Hamilton Meathouse
is it smart enough to look into the current USD data and see that it's already stored the Prototype assets used in InstancerA and not load it again for InstancerB?

What your're describing is USD native instancing which is not automatic. If you enable the instanceable metadata (configureprimitive lop) on the prototype prims you'll get a shared representation, otherwise they will be duplicates, at least from a USD scenegraph perspective. Low level parts of the software like the underlying file format plugin or render delegate might de-duplicate data in some cases, however it's never super easy to know when that is/isn't happening effectively. Making a prim instanceable makes things explicit and is more efficient.

This is not clear to me... Let's say we have prototypes in some shared location on the stage, outside of any PointInstancer namespace.... if I make those prototypes instanceable, no matter what I do, the PointInstancer copies them to its own namespace. What I want to know is.... do those represent unique instances in memory, i.e. duplicates of the original prototypes, are they simply pointers to the shared prototype? If check the USD file created from this, it's not clear at all.

Tim Crowson
This is not clear to me... Let's say we have prototypes in some shared location on the stage, outside of any PointInstancer namespace.... if I make those prototypes instanceable, no matter what I do, the PointInstancer copies them to its own namespace. What I want to know is.... do those represent unique instances in memory, i.e. duplicates of the original prototypes, are they simply pointers to the shared prototype? If check the USD file created from this, it's not clear at all.

In the Scene Graph Tree panel, native instances are colored blue whereas regular references show up as green.

So below is a regular reference of the scenario you described:



The SphereAsset prototypes in pi1 and pi2 both reference the root-level SphereAsset prim so there are now three copies of the asset (the two references could, for example, both get different overrides since they are unique). Put another way, a regular reference in USD doesn't share between other references of the same source, which is what makes overrides possible.

Now set each prototype to instanceable:



The light blue color represents the root prim of an instance and the darker blue/purple represents a non-root prim. Non-root instance prims can't be modified in a way that makes them unique however since they are just pointing at an implicitly generated prototype.

I'm not sure if the SceneGraphTree is able to show prototypes but in usdview they can be displayed via the "Show" menu of the browser (the prim named "__Prototype_1")



The main catch with native instancing overall is there has to be at least one composition arc on the prim being made instanceable. My example sets up a reference (which is the most common) but any arc is valid. USD then uses the arc criteria to decide if two prims being made instanceable are actually the same (e.g. two references with the same target).

That's super helpful, thank you!

One thing I'm struggling with is stage organization. Let's say I want all my prototypes grouped under some shared prim rather than out in the root. If I try to do that, the PI uses that shared prim as the sole prototype, meaning each instance is essentially ALL the prototypes. Trying to find a way to organize this in a production-friendly way.

Tim Crowson
One thing I'm struggling with is stage organization. Let's say I want all my prototypes grouped under some shared prim rather than out in the root. If I try to do that, the PI uses that shared prim as the sole prototype, meaning each instance is essentially ALL the prototypes. Trying to find a way to organize this in a production-friendly way.

Are you using the first or second input on the instancer lop to generate the prototypes? The second input doesn't really work when the prototypes are to be made instanceable because the node copies the prims directly below the pointinstancer leaving no composition arc for USD to de-duplicate. Using the first input however, I can more or less get the right thing to happen using multiple non-root source assets:





The only wrinkle I can see is that the instancer lop has inserted the top-level "library" prim into the prototype hierarchy. While not the end of the world that could get annoying if the source references were in a deeper hierarchy. I think a new checkbox on the instancer lop to ignore ancestor prims could solve that easily enough though. I guess it would also be nice if the instancer lop had an "Instanceable Reference" option so that a configureprimitives lop isn't needed.

Overall though I'd suggest *the* most production friendly way is to write the asset to disk. That way you can have the prototype simply reference the asset file, and don't need to find a place on the stage to stash it. Going that route though I think you'll want the second input on the instancer lop to pull in the prototypes as individual references. e.g

Thanks! This mirrors my findings too. One other wrinkle I found with the first input's behavior of inserting the entire hierarchy is that the resulting protos under the PI lose all their drawing mode options and revert to full geo (even if the protos I specify are properly configured with the full parent hierarchy of the source protos being something like group-kind and bbox mode). So if I have a scatter system of trees, the PI draws them as full geo (since they lose their 'kind' setting maybe, and I can't find a way to get bboxes back.

But I don't get this behavior using any other PI approach.

Anyway, can't thank you enough for your help with this. I think I have a couple of options.

There doesn't seem to be a way to do this with the point instancer, it copies the prototypes as children no matter what.

You can replicate the intended behavior manually using an edit properties/attribute wrangle.

Hi all!

There is an existing RFE for this workflow (i.e., "external"/"shared" prototypes).

One thing to be aware of, if you set it up manually, is the visibility of the prototypes. When the prototypes exist as a child of the instancer, they will not show up in the viewport/render (i.e., only the instances show up). If you have an arbitrary location in your scenegraph, you'll need to explicitly make a parent of the prototypes invisible if you don't want them showing up.

- Rob

Thanks Rob! Is that RFE in active development? And if so would that be the sort of thing to make it's way back into 18.5?

Tim Crowson
Thanks Rob! Is that RFE in active development? And if so would that be the sort of thing to make it's way back into 18.5?

Hi Tim!

It is not currently active, no. There are a small cluster of instancer-related RFEs I've been collecting, but it's realistically not going to be an area of focus for at least the next few months.

And it's too early to comment on backporting, sorry.

I apologise that all I have to offer at this point is "this is not a crazy request, and it's on our radar".

- Rob

robp_sidefx

Tim Crowson
Thanks Rob! Is that RFE in active development? And if so would that be the sort of thing to make it's way back into 18.5?

Hi Tim!

It is not currently active, no. There are a small cluster of instancer-related RFEs I've been collecting, but it's realistically not going to be an area of focus for at least the next few months.

And it's too early to comment on backporting, sorry.

I apologise that all I have to offer at this point is "this is not a crazy request, and it's on our radar".

- Rob

Is there another way with the released Houdini version to achieve what I did in my example that is more straightforward and doesn't rely on manually generating arrays in VEX? Is there a way to go from a point cloud in sops to a point instancer prim with the right attribute mapping?

Hello guys !

Is there some news on this topic ?
I found this thread : https://www.sidefx.com/forum/topic/91752 [www.sidefx.com] which is very helpfull, but did SideFx implemented a way to do this ?

And is there a way to hide the original primitive prototype without hiding the point instancer ?

Thank's in advance for your answer !

Paul.

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.

Thank you very much !

Hello,

I'm digging this old thread up to see if anything has changed?

I did a test where I use 1 instancer with 100 points vs 10 instancers with 10 points and the render time goes up 50% and the RAM usage by 20%. The PI are pointing to a primitive in the stage using the first input.

Would the only way to get better performance still be to manually create an instancer that points to the same prototype as mentioned in the other post? It looks like the USD issue has been addressed earlier in the summer.

Cheers,
Beat