I created the following simple animation in Mikoto to study the keyframe data stored in the *.mkm file.
The animation starts and ends with both bones pointing in the +Y axis direction.
The *.mkm file listing is shown below where bone2 is the child of bone1.
Mikoto Motion Ver 2 Motion { name = "motion[00]" endframe = 140 loop = 0 Vector { name = "j_bone1" class = "Locate" member = "pos" curve = "linear" 0 (0.000000 0.000000 0.000000) 20 (0.000000 0.000000 0.000000) 40 (0.000000 0.000000 0.000000) 70 (0.000000 0.000000 0.000000) 100 (0.000000 0.000000 0.000000) 120 (0.000000 0.000000 0.000000) 140 (0.000000 0.000000 0.000000) } Quaternion { name = "bone1" class = "Bone" member = "rot" curve = "linear" 0 (0.500000 0.500000 0.500000 -0.500000) 20 (-0.707107 0.000000 -0.707107 0.000000) 40 (-0.707107 0.000000 -0.707107 0.000000) 70 (-0.707107 0.000000 -0.707107 0.000000) 100 (0.500000 0.500000 0.500000 -0.500000) 120 (0.500000 0.500000 0.500000 -0.500000) 140 (0.500000 0.500000 0.500000 -0.500000) } Quaternion { name = "bone2" class = "Bone" member = "rot" curve = "linear" 0 (-0.000000 -0.000000 0.000000 1.000000) 20 (-0.000000 -0.000000 0.000000 1.000000) 40 (0.707107 0.000000 -0.000000 0.707107) 70 (0.500000 -0.500000 -0.500000 0.500000) 100 (0.707107 0.000000 0.000000 0.707107) 120 (-0.000000 -0.000000 0.000000 1.000000) 140 (-0.000000 -0.000000 0.000000 1.000000) } } Eof
The keyframe rotation data is stored as quaternions in (i j k w) form.
Calculating the rotations by the methods in this post [link] we get the following.
Note that the –0.0000 values are a result of floating point operations in the program I am using to calculate the quaternions and occur because instead of returning zero a very tiny negative number is returned.
At frames 0, 120, 140 the skeleton is in the bind pose.
- bone1’s absolute rotation = (-0.5000 -0.5000 -0.5000 0.5000)
- bone2’s absolute rotation = (-0.5000 -0.5000 -0.5000 0.5000)
- bone1’s relative rotation = (-0.5000 -0.5000 -0.5000 0.5000)
- bone2’s relative rotation = (0 0 0 1)
The relative rotations match the values stored in the file if bone1’s rotation is multiplied by –1. A quaternion multiplied x –1 still represents the same rotation.
Lets check frame 20.
- bone1’s absolute rotation = (0.7071 -0.0000 0.7071 -0.0000)
- bone2’s absolute rotation = (0.7071 -0.0000 0.7071 -0.0000)
- bone1’s relative rotation = (0.7071 -0.0000 0.7071 -0.0000)
- bone2’s relative rotation = (0 0 0 1)
The relative rotations match the values stored in the file if bone1’s rotation is multiplied by –1.
Lets check frame 40.
- bone1’s absolute rotation = (0.7071 -0.0000 0.7071 -0.0000)
- bone2’s absolute rotation = (-0.5000 -0.5000 -0.5000 0.5000)
- bone1’s relative rotation = (0.7071 -0.0000 0.7071 -0.0000)
- bone2’s relative rotation = (0.7071 0.0000 0.0000 0.7071)
The relative rotations match the values stored in the file if bone1’s rotation is multiplied by –1.
See also: http://sappersblog.blogspot.com/2014/07/keynote-mqx-file-format.html
The rotations stored in the *.mkm file are relative to the zero orientation of the bones (aligned with Z axis) and not the initial pose of the model.
To get the rotation relative to an initial pose you first need to export an *.mkm of that initial pose to get the rotations of the initial pose.
Then for each bone of your animation you perform the following calculation.
q = absolute rotation parent initial pose * q anim * inverse q local initial pose * inverse absolute rotation parent initial pose
q anim is the quaternion of the bone in your animation.
q local initial pose is the quaternion for the bone in the initial pose.
To inverse a quaternion you negate the x, y, z components.
To obtain the absolute rotation initial pose of the parent bone you multiply the quaternions of the initial pose for all the parent bones of the bone in the following order.
(q root * ... * q great grandparent * q grandparent * q parent)
To get the inverse once again negate the x, y, z components of the resulting quaternion.
Source: Mikoto2X source code.
NOTE: The order of the bones in each motion may differ. This is especially the case for motions converted from .BVH files.
No comments:
Post a Comment