Incorrect instance matrices with nested point instancers

[ix-dcourtois]

Description of Issue

When using nested point instancers, the local transforms of the intermediate point instancers seem to be omitted when computing the transforms of the final instances, at least in usdview.

See the following thread where this issue is discussed in a bit more detail: https://groups.google.com/forum/#!topic/usd-interest/vKMdr0mN3W4

Steps to Reproduce

Save the following to a .usda file, and open in usdview, then select the root Offset point instancer.
Its bounding box is correct, however the cube is not: it doesn't take the Reset transform into account.

#usda 1.0

def PointInstancer "Offset"
{
    point3f[] positions = [(0, 0, 0)]
    int[] protoIndices = [0]
    prepend rel prototypes = </Offset/Reset>

    double3 xformOp:translate = (0, 0, 4)
    uniform token[] xformOpOrder = ["xformOp:translate"]

    def PointInstancer "Reset"
    {
        point3f[] positions = [(0, 0, 0)]
        int[] protoIndices = [0]
        prepend rel prototypes = </Offset/Reset/Cube>

        double3 xformOp:translate = (-4, 0, 0)
        uniform token[] xformOpOrder = ["xformOp:translate"]

        def Cube "Cube"
        {
            double3 xformOp:translate = (4, 0, 0)
            uniform token[] xformOpOrder = ["xformOp:translate"]
        }
    }
}

Inserting an empty xform between Offset and Reset and using that one as the prototype of the Offset point instancer fixes the problem (see the answer of Spiff in the aforementioned group forum post)

[jilliene]

Filed as internal issue #USD-5928

[cameronwhite]

I recently ran into this issue as well, and the workaround mentioned of inserting an empty Xform does still work

Doing some further testing, I noticed that if the xformOp is placed on that intermediate Xform rather than the nested point instancer (variant "c" in the attached example nested_instancer.tar.gz) then transform is also ignored. This suggests that the issue might be related to the xformOp being authored on the prototype prim, when the prototype or one of its children is an instancer

[asluk]

@spiffmon , is this the same as #1663 and #2359 (or will be addressed by the fix for that)? Thanks!

[spiffmon]

Different, but a fix is coming.

On Fri, Jun 2, 2023 at 4:40 PM Aaron Luk ***@***.***> wrote: @spiffmon <https://github.com/spiffmon> , is this the same as #1663 <#1663> and #2359 <#2359> (or will be addressed by the fix for that)? Thanks! — Reply to this email directly, view it on GitHub <#1140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPOU2AETB3LRPMMG7MGK4LXJJ2WZANCNFSM4LGOEN4Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- --spiffiPhone