PointInstancer update issue with prototypes are instanceable

Hi,
I have a scene with a class to define the asset (made of 1 cube for now), like this

class "_class_"
{
    def Xform "assetCubes" (
        kind = "component"
    )
    {
        def Cube "cube_0"
        {
            matrix4d xformOp:transform = (
                (1, 0, 0, 0), 
                (0, 1, 0, 0), 
                (0, 0, 1, 0), 
                (0, 0, 0, 1) )
            uniform token[] xformOpOrder = ["xformOp:transform"]
        }
    }
}

and I also have a class to drive instanceability

class "_class_instanceable" (
    instanceable = true
)
{
}

Then in the scene I’ve got 3 elements referencing the assetCubes and inheriting the _class_instanceable and I’ve got 3 PointInstancers (with 2 instances each) with their internal prototypes doing something similar to the 3 elements.

With instanceable enabled, updating the main assetCubes only updates the individual elements (or better, their HdInstancer basically), but the PointInstancers (or their HdInstancers) aren’t updated.

I’ve tested this in Solaris and also in usdview, if you load the attached file, you can then run the following in the python interpreter:

from pxr import UsdGeom, Gf
stage = usdviewApi.stage
c = UsdGeom.Cube.Define(stage,"/_class_/assetCubes/cube_1")
op = c.AddTransformOp()
op.Set( Gf.Matrix4d(1,0,0,0, 0,1,0,0, 0,0,1,0, -3,0,0,1 ) )

which is going to create a new cube under assetCubes, and you can see the elements updating, but not the PointInstancers, which you have to update manually for example toggleing their visibility.

NOTE: I’d like to discuss this in the next usd-wg meeting, as there is a Hydra-behaviour I’d like to review with you guys, to understand how we can handle it moving forward (shared prototypes).

Screenshot 2023-12-10 102839

instancing_v01.usda (3.2 KB)

NOTE that disabling instanceable on the _class_instanceable prim, this works as expected.

Hi Paolo,

This sounds like a bug in our point instancer handling code. When UsdImaging 2.0 is rolled out, I expect this to be fixed (you can try yourself by setting “USDIMAGINGGL_ENGINE_ENABLE_SCENE_INDEX” to 1 in env before running usdview). If you want to file a github issue with your repro steps, we can look at fixing it in UsdImagingDelegate as well.

Our semantic goal is for behavior to be the same whether or not “instanceable” is true or not. “instanceable” will de-duplicate the data at the USD level, and it’s a hint for hydra to de-duplicate the data as well, if it can do so in a way that doesn’t break the USD evaluation semantics. (Of course, sometimes this is a challenging goal to achieve :slight_smile: ).

I missed this in December, but do let me know if I should drop into one of the upcoming WG-USD meetings to talk USD evaluation semantics.

Hope that helps,
Tom

Hi Tom,

First of all, Happy new year! :slight_smile:

and thanks for your reply.
Yes, I think I wanted to bring this up (with the example) and a couple of other related things, to the next usd-wg meeting.
There is packed agenda for next usd-wg meeting, so not sure if I can do it the 18th of Jan, and if not, I’ll def do it on the 1st of Feb usd-wg meeting.

Cheers,
Paolo

Paolo, thanks for demonstrating this today. I can’t recall if you mentioned it in the meeting, did you try the 2.0 scene indexing flag to check if the behavior is fixed there?

Hey Nick,
I haven’t specifically tried with SceneIndex enabled. It could very well be fixed there.
In the presentation I’ve mentioned that we can’t enable SceneIndex in Solaris, so we are gonna stay with Hydra 1.0 for the next movie probably, but we’ll see.
I will confirm whether this works with Hydra 2.0 though or not, and I’ll let you know :slight_smile:
cheers!