Bug on rotation attribute?

Hello,

I have attached two usd files with the same rotation applied to a prim.
The testSeparateRot.usd expresses the rotation in the form of:

float xformOp:rotateX = 90
float xformOp:rotateY = 90
float xformOp:rotateZ = 45
uniform token[] xformOpOrder = ["xformOp:rotateX", "xformOp:rotateY", "xformOp:rotateZ"]

While the testGroupRot.usd has the rotation in the form of:

float3 xformOp:rotateXYZ = (90, 90, 45)
uniform token[] xformOpOrder = ["xformOp:rotateXYZ"]

The two files have the same rotation order and values to each component, so I expected them to be displayed the same, but as we can see on the image below, opening them in usdview they are rendered differently from each other

If I swap the x and z in the rotation order of the one that is split they get the same orientation:

uniform token[] xformOpOrder = ["xformOp:rotateZ", "xformOp:rotateY", "xformOp:rotateX"]

Am I wrong to assume that the rotation order of the combined attribute should be the same for when the rotation is split? Or this a bug?

Ps: I’m using usd 25.05

testSeperateRot.usd (3.0 KB)
testGroupRot.usda (2.8 KB)

1 Like

I guess I found my answer in the xformable.h

/// If it were important for the prim's rotations to be independently 
/// overridable, we could equivalently (at some performance cost) encode
/// the transformation also like so:
/// \code
/// float xformOp:rotateX = 30
/// float xformOp:rotateY = 60
/// float xformOp:rotateZ = 90
/// float3 xformOp:scale = (2, 2, 2)
/// double3 xformOp:translate = (0, 100, 0)
/// uniform token[] xformOpOrder = [ "xformOp:translate", "xformOp:rotateZ", "xformOp:rotateY", "xformOp:rotateX", "xformOp:scale" ]
/// \endcode
/// 
/// Again, note that although we are encoding an XYZ rotation, the three
/// rotations appear in the **xformOpOrder** in the opposite order, with Z,
/// followed, by Y, followed by X.
1 Like