A generic question on the internal processses of “instanceable references” (IR).
So, let’s say I have a scene with 1000 IR.
When resolving the stage let’s imagine we are traversing it: at some point the first IR will be encountred, under the hood a USD process will hash it as a potential “candidate for instancing”, and the result will be and in-memory “virtual master” (VM).
Then we contiue traversing, a second IR is found, it is hashed and compared with the first IR.
If the hash is the same, then this second IR will be an actual instance of the first virtual master.
Else if the hash is different, this second IR will be our second virtual master.
This process wil continue until all IR are compared to all VM. At this point we should know what is an instance of something else and what is not.
Obviously, if all IR are different we will have 1000 different VM and 0 instances. While if all IR are the exact same, we will have 1 VM and 999 instances.
I would like to be able to know, say from python api, how many VM actually became “True Masters” (not sure if this concept exists and what is its name, sorry for the neologysm), aswell as how many instances are associated to each true master.
My understandings could be off, I’d like to know more about this process or if you have any pointers would be great.
For a prim’s subgraph to be made an instance, it must be active, instanceable, and have at least one composition arc. All instanced prims produce “prototypes” during composition which can be accessed for the entire stage here–
A “prototype” is produced regardless of whether or not there are multiple instances. Once you have a prototype, you can get a list of all instances of that prototype here.
Thanks.
Ok, counting the instances associated to each prototype is a way, indeed.
It seems to work and the numbers seems to make sense.
As per docs GetInstances() should return 0 if the prototype has no instances (but I should really double check the meaning of 1, in case it counts itself as the first instance. I dont think so, but the scene I am dealing with is quite large, 16K prototypes, has so many prototypes with 1 single instance, nearly 8K, that I should not ignore this possibility hehehe).
The next thing I will need to verify is if instances before rendering are with 100% guarantee also istances for the render delegate and the renderer, and therefore are consolidated with the other instances in a single draw call (I am refering to rendering with storm in this case).
I’m not sure it’s possible for a prototype on a composed stage to have zero instances. I /think/ the documentation is suggesting it will return zero instances if the prim itself is not a prototype. I’d be interested to learn though if there are cases I’m not thinking of, and it’s good to check for.
Note that prototypes always exist with a special root path prefixed with __Prototype and never exist “inline” of a standard scene graph traversal. The case of a prototype also being an instance shouldn’t be possible. (Prototypes themselves however may contain instances.)