Hello,

I'm very possibly exposing my own ignorance here, but I haven't been able to wrap my noggin around why the row order in the boneCapture_pCaptData detail attribute as produced by the ‘Capture Attribute Unpack’ is the way it is (x, z then y).

I was attempting to do some manipulation of the capture position transforms in SOPs and of course casting the first 16 floats of the array to a matrix produces a lovely, nonsensical transform.

Any clues most appreciated!

Cheers,
Henry

Every time you pose a question, unless rhetorical, you're doing it because you're ignorant about the issue and no longer wish to be so and there's nothing wrong with that.
With that preachy/philosophical probably unnecessarily annoying bit aside, my possibly ignorant guess (hiccup) is that it has something to do with the preferred rotation order of the bones. Continuing with my quite possibly ignorant understanding of the issue, since objects' rotation are evaluated based on Euler angles and not quaternion, there has to be a rotation order, especially important for bones, for reasons quite obvious I'd say.

Ha… quite right, quite right I meant to be more emphatic, as in ‘have I missed something really obvious?’

EDIT: As it turns out, yes I was missing something really obvious - the alignment of the cregion… which is itself a child transform. And as the matrix represents the cregion transform, not the bone, the default z-axis alignment would produce the matrix in the attribute… I'm going to sleep now and hope that I wake up with my brain screwed in