[x3d-public] [h-anim] Basic Animataion data

Fri Nov 11 03:41:58 PST 2016

Hi Joe,

Great summary and references. However, one of the references you listed is
incorrect. You wrote:

Schlag, 1994] John Schlag. Using geometric constructions to interpolate
orientation with quaternions. Graphics Gems IV, pages 230-236, 1994.

In fact, the article by John Schlag you are referring to is:

John Schlag. "Using Geometric Constructions to Interpolate Orientation with
Quaternions". In Graphics Gems II, Academic Press, 1991, pp. 377-380. 

Consulting Graphic Gems IV, pages 230-236, there is an article "Fiber Bundle
Twist Reduction", by Ken Shoemake at that location.

Regards,

Roy

-----Original Message-----
From: h-anim [mailto:h-anim-bounces at web3d.org] On Behalf Of Joe D Williams
Sent: 11 November 2016 01:30
To: X3D Graphics public mailing list <x3d-public at web3d.org>; Humanoid
Animation (H-Anim) Working Group <h-anim at web3d.org>
Subject: [h-anim] Basic Animataion data

glossary:

Transform rotation value

* Euler angle - typical mocap-derived

  animation data = x,y,z

     (x,y,z = degrees)

Mocap data represents:

  * Bone or Segment orientation

      or

* parent Joint rotation

Either interpretation represents

same animation

* matrix = axis-angle = x,y,z,a

     x,y,z = radians,

     a = scale factor

X3D Default

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 fixed.

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 tools.

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.

Background

Quaternions, Interpolation and Animation Erik B. Dam Martin Koch Martin
Lillholm  <mailto:erikdam at diku.dk> erikdam at diku.dk  <mailto:myth at diku.dk>
myth at diku.dk  <mailto:grumse at diku.dk> grumse at diku.dk Technical Report
DIKU-TR-98/5 Department of Computer Science University of Copenhagen
Universitetsparken 1

DK-2100 Kbh Denmark

July 17, 1998

Interesting Material.

I have a copy of a pdf.

Appendix A - Conventions

Coordinate system

(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.

Rotation.

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 the axis.

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 

+pi radians.

Transport Animations

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

An illustration:

[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 

polar decomposition.

 <ftp://ftp.cis.upenn.edu/pub/graphics/shoemake/polar-decomp.ps.Z>
ftp://ftp.cis.upenn.edu/pub/graphics/shoemake/polar-decomp.ps.Z, 1994.

Shoemake, 1994b] Ken Shoemake. Quaternions. 

 <ftp://ftp.cis.upenn.edu/pub/graphics/->
ftp://ftp.cis.upenn.edu/pub/graphics/-

shoemake/quatut.ps.Z, 1994.

Thanks and Best,

Joe 

_______________________________________________

h-anim mailing list

 <mailto:h-anim at web3d.org> h-anim at web3d.org

 <http://web3d.org/mailman/listinfo/h-anim_web3d.org>
http://web3d.org/mailman/listinfo/h-anim_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161111/b8c9f4be/attachment-0001.html>