Confusing position coordinates for nodes in gltf file

I am trying to understand the co-ordinates of nodes in a human T-pose file in particular (see Y_bot.gltf/buffer.bin attached - originally downloaded as fbx from Mixamo). From what I have gathered, the position (or translation) of a child node is expressed in terms of the local co-ordinate system of its parent node. I have visualized the file and it seems to confirm this part.

But, none of the position (translation) components (X, Y or Z) for any of the nodes seem to exceed 1. So, I am assuming all the values are normalized somehow. What is confusing is that the divisor for normalization doesn’t seem to be a constant.

For example, the Y-component of the position vector of a node (mixamorig:Hips) which is quite close to its parent (Root node/Global origin) is quite high (~0.9) as compared to that of another node (mixamorig:RightLeg) which is much farther away from its parent (mixamorig:RightUpLeg) - value of ~0.4. Although this pattern repeats throughout the file, for both these pairs, the translation along X- and Z- directions is ~0, so the discrepancy is easy to observe. I would appreciate any help for understanding/interpreting these position values.

Edit: Adding image for more clarity on observed discrepancy. (gltf_issue.jpg)

Y_Bot.gltf (53.8 KB)
buffer.bin (2.2 MB)

There’s no normalization – only relative coordinate systems affecting their descendants. It would be very hard to look at just the Y components in isolation and get anything useful from that. You could do the math, yes, but ultimately that will only tell you how this specific skeleton works — another skinned mesh in glTF or other formats might be structured quite differently.

What are you trying to do with this information? There might be an easier way, like the bone.getWorldPosition( target ) method.

Thanks for the reply. Please correct me if I’m wrong but the relative co-ordinate systems should only affect the direction and not the magnitude of descendants’ translation values. My main reason for selecting these two pairs of nodes is that the local co-ordinate systems of the parents in each of these pairs are oriented almost similarly. With almost no translation in the X- or Z- direction (locally), the translation magnitude and direction is easy to compare.
The final aim is indeed to get the world position of any node and the method you mention looks useful. But I am not using Three.js for reading/manipulating the gltf file so not sure whether this information (world position) is gettable purely from the gltf file itself.

I would strongly advise against trying to approach skinning with this fuzzy math. A node’s local transform should be represented as a matrix, and its world transform is the product of that and all parent matrices. Then world position can be extracted from the world matrix.

This is how three.js implements the calculation, but you can certainly do the same thing directly from the glTF file. The glTF Transform library does something similar: Node | glTF Transform

Hey, thanks for warning me - I’m just a coder (even that would be a stretch - I mostly copy and paste)! I guess I will have to (brush up on my math and) figure out matrix multiplication after all!

1 Like

gl-matrix is a great library if you’re in JavaScript but not using three.js here – that’s what glTF Transform does for the math, and you can see an implementation here: