I took another look at cplhenshaw's converter, and I understood how the hierarchy works, quite similar to how a skeleton would work, e.g.: first you position the neck, and then you position the head on top of it, and so on. Only weird thing is sibling handling, I guess that works OK if you imagine sibling nodes being on the same level of e.g. a binary tree, making them have the same parent (while the parent is not referencing all the children).
But when it comes to rotations, I can't quite grasp them. For example, standard rotation around a pivot would include:
- translating to pivot point
- rotating
As cplhenshaw's converter already adds the pivot's offset to the mesh position, I guess the only thing left to do is rotate.
Now for the questions:
As I understand, Grim's rotation is:
- Pitch around X
- Roll around Y
- Yaw around Z
- Is this how it works originally, or is it this way to compensate for left handed / right handed systems in ResidualVM? (Direct3D / OpenGL)
- Are the values in the files (which seem to be degrees) already added to the models (so they would need to be subtracted, or rotated in the opposite directions), or are those values that we need to rotate the mesh with, in order to get to a coherent mesh positioning?
- Are the values cumulative by parent, or individual by mesh?
e.g.: neck rotation is: 90, 0, 0. head rotation is : 90, 0, 0.
Would we need to rotate the head by: 180, 0, 0?
Frankly, I've already got some code that executes rotation transformation on vertices, but I'm unable to get them right. Any insight would be appreciated.
P.S.: I tried looking at how it's handled in ResidualVM, but the inverted up-axis for Grim (or was it EMI?) and all the math which follows because of it is giving me a headache.
