I might be missing something obvious here, but how could we avoid flattening of nested instancers? Right now, we’re getting a bunch of prototype copies like ForInstancer52ed…14c2, which are coming from UsdImagingPiPrototypePropagatingSceneIndex. The problem is that in scene there’s just a couple of prototypes with lots of instances, but in Hydra there’s a lots of such prototypes with just a handful instances. Admittedly, it gives visually correct result, but it’s wasting a lot of memory.
As our renderer can natively deal with nesting (up to certain level) we would like to take advantage of it and limit number of prototypes. As I understand, it would involve customizing PrototypePropagatingSceneIndex, however I’m unsure how to disable/change the default one (without patching code) and/or orchestrate with custom one within third party applications.
I’ve seen that this topic was touched in a couple of places, but I haven’t found any concrete examples. Is there something that I’m missing?
Hi Jakub. My understanding is that Hydra 2 does support nested instances, and the HdPrman render delegate makes use of this – for example, instancing a leaf prototype onto a tree prototype, and instancing the tree onto a forest. There are, however, some unresolved questions around the implementation of deep selection within nested instances.
There are two phases that determine the final number of prototypes. First, the USD scenegraph applies its instance-sharing rules to determine how many prototypes to generate to back its native instances. These are what live in the USD scenegraph at paths such as </__Prototype_NNN>. These are serially numbered but not in a deterministic order. In usdview you can see these if you turn on Show > Prototype Prims.
The next phase is that Hydra applies additional rules that may further split prototypes based on inherited state. This is what the “instance aggregation” in UsdImaging is about. You can see a list of the input fields used to split prototypes in _InstanceDataSourceNames() in usdImaging/sceneIndices.cpp: OpenUSD/pxr/usdImaging/usdImaging/sceneIndices.cpp at dev · PixarAnimationStudios/OpenUSD · GitHub
Currently this list includes:
material bindings
purpose
certain model (asset) level schemas, which may provide context for texture path resolution
Perhaps one of these is varying across your prototypes and causing Hydra to split them further, unexpectedly? Also, I know that there has been some discussion / observation that we may need some more flexibility over this policy in the future, in order to better adapt to renderer-specific capabilities. Motivating examples there include (1) some renderers such as RenderMan can vary surface (but not displacement) materials per-instance, (2) some renderers may be able to run UsdSkel vertex deformation internally, allowing crowd agent prototypes to stay shared while letting individual instances pose uniquely.
Hope this helps. More robust handling of instances has definitely been a focus for Hydra 2 but it is a large topic with a lot of converging / diverging needs.