[x3d-public] Basic Animataion data
Joe D Williams
joedwil at earthlink.net
Thu Nov 10 17:30:04 PST 2016
Transform rotation value
* Euler angle - typical mocap-derived
animation data = x,y,z
(x,y,z = degrees)
Mocap data represents:
* Bone or Segment orientation
* parent Joint rotation
Either interpretation represents
* matrix = axis-angle = x,y,z,a
x,y,z = radians,
a = scale factor
Easy to hand-edit
* Unit quaternion = w,x,y,z
w+x+y+z = 1 = unit q
Most common authoring tool internal and transport form
Easy to add unit quats for realtime interpolated animation
Can use hand-edit as
w=scale factor and x,y,z are axes
if careful to maintain uq
* Standards-Track Lossless conversion between forms.
First, please notice that this Animation data is
aimed at describing keyframe animation of
a set of hierarchal "Joint" nodes.
Animation data is provided as arrays of:
keyframe root position data,
keyframe rotation data for each joint,
number of keyframes,
target key time frame interval
The data is used by defining the root position and each joint rotation
at each key time. For film and video there is often no need for a list
of key times indexed to each keyvalue because the frame interval is
Notice that typically, there is no consideration for non-monotonic key
times, although it is highly unlikely to encounter an X3D browser that
does not allow non-monotonic key times. Why, allow non-monotonic key
times? Because it is usually convenient for the author to consider
each joint individually and individually define the interval between
associated keyvalue data points, and to minimize the actual number of
key times and thus keyvalues.
At this time, in order for an X3D HAnim to use most types of mocap
data it would only be required:
1. Connect the joint names
2. Convert the input data form to axis-angle,
3, Construct the interpolators and timers for each joint
This style of animation depends mainly or solely on application of
individual rotations to individual joints in a set of hierarchal
'Joint' nodes at each key time to produce the keyframe. Current best
practice for this style of animation uses unit quaternions due to
efficiency. Even though the most throughly complete technical solution
remains axis-angle matrix transformations, the unit quats are easy to
transport and used natively in many animation creation and development
So, the choice of gltf to only transport quaternions should cause X3D
and HAnim to address the idea of built-in quaternion support. As is
well-shown, the maths of these three forms are well defined and
conversion interactions are well understood.
* At this time we are creating prototype support for BVH x,y,z ffps
import, it seems only reasonable to encourage import of both Euler
angle and unit quaternion forms.
Quaternions, Interpolation and Animation
Erik B. Dam Martin Koch Martin Lillholm
erikdam at diku.dk myth at diku.dk grumse at diku.dk
Technical Report DIKU-TR-98/5
Department of Computer Science
University of Copenhagen
DK-2100 Kbh Denmark
July 17, 1998
I have a copy of a pdf.
Appendix A - Conventions
(slightly reworded by me to aim at X3D and HAnim)
X3D and HAnim use a right-handed coordinate system. In computer
graphics some use a left-handed coordinate system. This allows the
z-axis to point "into" the screen which seems natural for some styles
of authoring. However, since X3D primarily uses coordinates for
animations driven by mathematical derivations and for Humanoid
animations, VRML and X3D have chosen to use the mathematical standard,
the right-handed coordinate system.
This means that the default Humanoid pose gaze is facing +z.
The +z axis for the character points "out" of the screen,
+y is up,
and +x is towards the character's left, viewer's right.
The default X3D viewpoint is oriented to look toward -z.
The direction of positive, or increasing rotation about an axis is
obtained by the right-hand rule:
Hold the axis with right hand and the thumb pointing in the positive
direction of the axis.
Adding positive rotation will rotate in the direction of the fingers.
It just happens that HAnim Joint rotations can be vizualized in terms
of x=pitch, y=yaw, and z=roll.
Again, hold the Joint, as if you were holding the appropriate axis
with right hand and the thumb pointing in the positive direction of
A positive rotation will rotate the Joint and move child hierarchies
in the direction your fingers are wrapped around the axis.
For instance, consider a roll (positive z-axis) animation of a Joint,
as would be appropriate for HAnim right hand fingers from the default
pose.. The fingers are pointing down and thumb pointing toward +z. To
move the fingers as if grasping the z-axis, rotate the finger joint(s)
to increase their z-axis rotation.
Amazingly enough, this results in the character's right hand wrapping
around the z-axis with the thumb pointed +z, and illustrates the
right-hand rule perfectly.
Incidentally, this means that to get proper orientation for a gaze
from the 'standard' eyeball location, then you can yaw the viewpoint
In order to transport animations between 'standard' H-Anim characters,
to accomplish the HAnim 'standard' initial pose prior to animation the
Joint is defined to be at X3D default orientation, +z is out of the
screen, +y is up, and +x is towards the character's left.
The default initial value for all Joints:
X3D axis-angle (matrix) form is 0 0 1 0
and for unit quatenions is 1 0 0 0
[standard X3D default transformations
X3D coordinate axes]
z (+ out toward viewer)
y (+ up)
x (+ character's left)
Rotation about z brings x into y
Rotation about y brings z into x
Rotation about x brings y into z
Schlag, 1994] John Schlag.
Using geometric constructions to
interpolate orientation with quaternions.
Graphics Gems IV, pages 230-236, 1994.
[Shoemake & Du, 1994] Ken Shoemake & Tom Du. Matrix animation and
Shoemake, 1994b] Ken Shoemake. Quaternions.
Thanks and Best,
More information about the x3d-public