Nested Point Instancing with Instanceable not displaying as expected

[SebSchmidtWetaFx]

Description of Issue

We're seeing an issue in usd-23.08 as well as in 24.05, when using nested point-instancing in combination with instanceable, where point-instanced point-instancers with instanceable = true are not displaying correctly in usdview.

It seems to have been introduced between 22.05 and 23.08.
This problem does not seem to show up when using hydra2 (tested with usdview)

Steps to Reproduce

In our attached file, we have a 'Asset' /ref which contains a cube and a point instancer instancing spheres at the corners of the cube
a point instancer /foo/instancer which references /ref as /foo/instancer/prototypes/exemplar
a point instancer /bar/instancer which references /ref as /bar/instancer/prototypes/exemplar , this also sets instanceable=true for that exemplar.

we have transforms on the /foo and /bar groups
When displaying this in UsdView we're seeing

• the point-instanced spheres in /foo look like we would expect (at the corners on the cube)
• the point instanced spheres in /bar are offset an dont seem to get properly offset.

#usda 1.0
(
)

# The contents of "ref" can be seen as reference with correct behaviour at origin.
def Scope "ref"
{
    def Cube "cube"
    {
    }

    def PointInstancer "instancer"
    {
        float3[] extent = [(-2.865, -2.865, -2.865), (2.865, 2.865, 2.865)]
        int64[] invisibleIds = []
        quath[] orientations = [(1, 0, 0, 0), (1, 0, 0, 0), (1, 0, 0, 0), (1, 0, 0, 0), (1, 0, 0, 0), (1, 0, 0, 0), (1, 0, 0, 0), (1, 0, 0, 0)]
        point3f[] positions = [(1.865, -1.865, 1.865), (-1.865, -1.865, 1.865), (1.865, 1.865, 1.865), (-1.865, 1.865, 1.865), (-1.865, -1.865, -1.865), (1.865, -1.865, -1.865), (-1.865, 1.865, -1.865), (1.865, 1.865, -1.865)]
        int[] protoIndices = [0, 0, 0, 0, 0, 0, 0, 0]
        rel prototypes = </ref/instancer/prototypes/exemplar>

        def "prototypes"
        {
            def Sphere "exemplar"
            {
            }
        }
    }
}

# PointInstancer prototype is native instance DISABLED.
# The transform applied to "foo" will be correctly applied to instances of the inner PointInstancer.
def Xform "foo" (
    kind = "group"
)
{
    double3 xformOp:translate = (0, 0, 10)
    uniform token[] xformOpOrder = ["xformOp:translate"]

    def PointInstancer "instancer"
    {
        quath[] orientations = [(1, 0, 0, 0), (1, 0, 0, 0)]
        point3f[] positions = [(-10, -10, 0), (-20, -20, 0)]
        int[] protoIndices = [0, 0]
        rel prototypes = </foo/instancer/prototypes/exemplar>
        float3[] scales = [(1, 1, 1), (1, 1, 1)]

        def "prototypes"
        {
            def "exemplar" (
                references = </ref>
            )
            {
            }
        }
    }
}

# PointInstancer prototype is native instance ENABLED.
# The transform applied to "bar" won't be correctly applied to instances of the inner PointInstancer.
def Xform "bar" (
    kind = "group"
)
{
    double3 xformOp:translate = (0, 0, 10)
    uniform token[] xformOpOrder = ["xformOp:translate"]

    def PointInstancer "instancer"
    {
        quath[] orientations = [(1, 0, 0, 0), (1, 0, 0, 0)]
        point3f[] positions = [(10, 10, 0), (20, 20, 0)]
        int[] protoIndices = [0, 0]
        rel prototypes = </bar/instancer/prototypes/exemplar>
        float3[] scales = [(1, 1, 1), (1, 1, 1)]

        def "prototypes"
        {
            def "exemplar" (
                instanceable = true
                references = </ref>
            )
            {
            }
        }
    }
}

System Information (OS, Hardware)

Linux

Package Versions

24.05, 24.03, 23.08

[jesschimein]

Filed as internal issue #USD-9602

[jesschimein]

Hi Seb, thanks for raising the issue and the clear documentation! Can you share how much of an impact this is having on you? And if you know, whether this issue is affecting anyone else?

We're hesitant to make changes to Hydra 1.0 since we think Hydra 2.0 is much better and our focus is getting that to parity with Hydra 1.0 so people can make the switch.

[SebSchmidtWetaFx]

Hi, thank you for getting back to me so quickly. This problem is affecting us quite a bit, and a move to Hydra2 does not seem doable at this point.
We've also seen this problem in Houdini's Viewport.
Upon investigating the commits related to PointInstancing, it appears that the change e14add22f854fc00a251aff9dbdd69357731f8d8 could be the culprit. Encouragingly, in a simple test, reverting this change successfully resolved the problem in the viewport.

[marktucker]

This is a pretty big concern for SideFX too... For one, it is a regression, so something that used to work (in Houdini 19.5) is now broken (in Houdini 20+). Waiting for Hydra2 for a fix is then a big problem because the next major Houdini release (which is the one many of our customers will still be using at 3 years from now) will also have this bug because Hydra2 isn't fully functional in USD 24.03 (the USD version shipping with the next major Houdini release).

We are of course perfectly happy to cherry pick a commit into our Houdini USD builds to fix this, but we'd really appreciate some help from the Pixar Hydra experts making sure that we are cherry picking a fix that is safe and effective. Reverting the change as suggested by Seb is a possibility, but of course that commit fixes #2359, which also sounds like an improvement we'd like to keep. Let us know if there's anything I can do to help with this. Thanks!