When building a layout one of the most controversial issue is whether to use NativeInstancing vs PointInstancers and in case how to split instances in how many PointInstancers.
We have a task that also create collections to describe the layout when loaded in a specific shot (creating various camera-based collections like frustums or distance based).
Since we can’t add individual instances of a PointInstancer in collections (right? or am I missing something?) then the question sometimes is how much can we rely on NativeInstancing, how many individual elements (instanceable) are too many for usd-composition/loading-time/etc ? How many PointInstancers are going to be too many ?
So, in case what I said above is correct, would it be reasonable to consider the ability to add individual instances of a PointInstancer to collections ?
Your current beliefs about the limitations of Collections are correct. Before we discuss whether PI instances can be identified in Collections, is it reasonable that the “collections of instances” could be associated with the PI’s themselves, rather than as ad hoc part of the collections?
Yars ago we discussed the potential utility of extending UsdGeomSubset to be able to carve up a parent PI into subsets; as prims, GeomSubsets would then easily be includable in Collections. Clients would still need to know what to do with them, but that would be true if we came up with some scheme for encoding instances in Collections, as well.
So, that means multiple UsdGeomSubsets, per PointInstancer, coming with a layer that would include the Collections for Camera Frustums and Camera Distance, and various overs for all the GeomSubsets.
Would this scale up efficiently ?
I’m not sure how to answer that You could probably envelope how many prims that would add to one of your scenes, and we can reason about that. It probably depends also on who and how will be consuming the new GeomSubsets. The Mesh adapter itself always needs (effectively) to process its materialBind GeomSubset children. Would the PI adapter always need to process all of its GeomSubset children, or are these collections primarily of use for higher-level system layers that operate less frequently than imaging?
Collections will mostly be for providing a description of the scene, and let artists potentially take action with them, like, split into passes (toggle visisibility, activation)change renderer attributes, resolution/quality, optimize bits and pieces.
Instances will probably have a very specific set of operations that can be executed on them, compared to an actual element (like, can’t change a variant for an instance, or prune shapes of one instance, etc), but if needed, for example, a new Prototype in the PointInstancers could be added, and some of those instances in a specific collection could start pointing at the new proto-id.
Usually, there is a process that generates these collections, as some could take sometime to run, and the result is brough in as a layer, and each shot could have its own layer, applied on a master layout valid for multiple shots/sequences.
Another way to express “collections” in PIs would be with primvars. It lacks any sort of connection to collections, but any process that manipulates a collection would need to know about handling PI geom subsets too, so I’m not sure primvars are significantly worse from that perspective. But they are animatable (maybe good, maybe bad). And they have quite different storage/performance characteristics (some better, some worse).
But they have the significant advantage that they exist already, and are even accessible to the renderer
You could probably envelope how many prims that would add to one of your scenes, and we can reason about that. It probably depends also on who and how will be consuming the new GeomSubsets. The Mesh adapter itself always needs (effectively) to process its materialBind GeomSubset children. Would the PI adapter always need to process all of its GeomSubset children, or are these collections primarily of use for higher-level system layers that operate less frequently than imaging?