Difference between revisions of "H-Anim"

From Web3D.org
Jump to: navigation, search
(→‎5e. Conversion algorithm observations)
(→‎6. How to convert?)
Line 666: Line 666:
 
----
 
----
  
−
=== 6. How to convert? ===
+
=== 7. How to convert? ===
  
 
With a little more work, we can then combine the pieces to show corresponding animations in HAnim and BVH.
 
With a little more work, we can then combine the pieces to show corresponding animations in HAnim and BVH.

Revision as of 01:09, 20 March 2014

Humanoid Animation (H-Anim) WG Meeting

  • Regular Meetings: Wednesday at 5pm, PDT or PST for 1 hour
  • Next Meeting: March 19th (Wednesday) at 5:00pm PDT
  • Agenda and Minutes

ISO Meeting

  • 2013 ISO/IEC JTC 1/SC 24 Plenary & WG Meetings, Sydney, Australia, August 26-30, 2013.
  • H-Anim proposals at WG6 meetings

Editor's note: links to uploaded images/documents available at http://web3d.org/wiki/index.php/Special:ListFiles

New work items and working draft

NWIP's scope and responsibility

Please add responsible persons for each item. We recommend that the persons of responsibility work on draft and/or examples for conformance.

  • 1) Definition of a humanoid character model capable of generating motion from captured motion data → Myeong and Joe
  • 2) Definition of a humanoid character model capable of generating motion using 3D scanner data → Myeong and William
  • 3) Definition of a humanoid character model capable of generating motion using a general motion definition such as keyframe, interpolation, kinematics, and dynamics for human figures → Myeong and Joe
  • 4) Definition of motion parameters for transferring or exchanging motion between different human character models → Myeong and Dick
  • 5) Definition of a motion data interface for including motion data → Myeong and Dick
  • 6) Definition of a motion viewer’s functionality → Myeong and Joe
  • 7) Definition of interoperable human behavior prototypes → Don, Myeong and William
  • 8) Guidelines for adding 3D skinning to humanoid characters → Joe and Don
  • 9) Definition of a recording interface for human motion such as gait → Don and William
  • 10) Provision for easier exchange of characters from design systems to H-Anim systems. → Myeong and Joe

This work is intended to define a standard model for humanoid animation including motion interfaces. It is an enhancement to the original H-Anim model of ISO/IEC 19774, and ISO/IEC 19774 Working Draft Amendment (WDAM) 1 in progress.

Document plan

  • The motion-related work is expected to be integrated with the 19774 specification and the 19774 WDAM 1 documents into a new document.
  • It may become appropriate and necessary to split the revised 19774 specification into multiple parts.

Formal submission of the H-Anim NWIP to ISO depends on working-group preparation of

  • Initial Committee Draft (CD) specification text
  • At least one draft implementation (with plans for a second)
  • Working examples, validation, quality assurance (QA)

New proposals submitted to H-Anim WG

  • 2013-07-21, H-Anim Facial Animation, Prof. Jung-Ju Choi (Ajou Univresity, Korea) FA_HAnim_LA20130721
  • 2013-07-21, Modeling and Animation of Hands and Feet, Prof. Kwan-Hee You (Chungbuk National University, Korea) HandAndFeetAnimation130821

Procedure for H-Anim character design

H-Anim wrl to x3d converter

H-Anim LOA Figures

Previous work

Resources

H-Anim Behavior Prototypes

Prototypes for HAnimBehavior node, which collects OrientationInterpolators for aggregate animation of an H-Anim humanoid model, and

HAnimBodyBehaviorChooser, which selects one body and enables/disables multiple aggregate behaviors.

H-Anim examples designed with a general tool (10 H-Anim characters)

Standards Development: Specifications

Two primary specifications govern this work: the X3D and the H-Anim International Standards. The H-Anim standard describes functional information in full detail, while the X3D specification simply references this work and maps constructs into X3D nomenclature. Working group members: only refer to the official version as we confirm current capabilities and rejuvenate future work.

X3D v3.3 specification, H-Anim Component

H-Anim specification, current

H-Anim specification, incomplete draft change

  • H-Anim Working Draft Amendment WDAM1
    • http://igraphics.com/Standards/ISO_IEC_19774_WAM1_2009_01_12/index.html
    • This draft amendment proposed new capabilities for H-Anim and is a reasonably complete document.
    • It was never approved by Web3D Consortium nor submitted to ISO.
    • We are interested in learning whether any implementations exist that demonstrate these proposed changes.
    • It stalled when working group activity ceased circa January 2009.
    • Added items in this draft "change document" can be reconsidered by the reactivated working group.
H-Anim specification, historical efforts
Note: the following versions have no official standing and are no longer active.
* Intermediate draft version, ISO/IEC 19774:2005
** http://www.web3d.org/x3d/specifications/ISO-IEC-19774-HumanoidAnimation/HAnim/HAnim.html
* H-Anim 200x specification (ISO_IEC_FCD_19774)
** http://h-anim.org/Specifications/H-Anim200x/ISO_IEC_FCD_19774
* H-Anim working group version 1.1, unofficial 
** http://h-anim.org/Specifications/H-Anim1.1
* H-Anim working group version 1.0, unofficial 
** http://h-anim.org/Specifications/H-Anim1.0

H-Anim WG Charter

WG Members

  • Myeong Won Lee (Chair)
  • William O. Glascoe III (Co-Chair)
  • Joe D. Williams (Subject Matter Expert)
  • Sandy Ressler
  • Keith Victor
  • David Bruner
  • Anita Havele
  • Richard F. Puk
  • Don Brutzman
  • Jung-Ju Choi
  • Kwan-Hee Yoo

Use Cases

Working Group chairs keep the following pages up to date:

  • We estimate there are upwards of 1,000 H-Anim Use Cases to fully characterize the human experience from the time all the bones of a human are formed or developed through

final disposition of the human body (mummification, cremation, burial, etc.). The vocabulary for human behavior (including misbehaving in all cultures, societies, etc.) serves as our baseline. Ontologies, taxonomies, classifications, encyclopedia and handbooks for human behavior are starting points for deriving the skeletal and skin motions for each concept, term and are categorized by:

1. duration of animation (measured in seconds: 3 - 30,000) 2. total joint angle displacement (displacement spectrum-percent of total possible displacement per joint) 3. angular rate of displaced joints (displacement speed spectrum - percent of maximum displacement) 4. simultaneity of joint displacement (percent of total joints in motion)

Moreover, this Working Group shall bin Use Cases in to those the WG are 1) likely to prototype 2) not likely to prototype and 3) will not prototype.

The complexity and duration of H-Anim scenes will correlate with the (actions) terms, (motions) concepts and (movements) behaviors of humans in natural and man-made environments with and without constraints of hand-held objects, clothing, etc.

Below are sample H-Anim Customer Segments (Authors and Consumers):

  • Use Cases (titles only) by Customer Segment (Authors and Consumers):

High Schoolers (half gross and half fine motor control) 

Animate individual performance on sport team using official contest
times (and/or video footage, body sensors, MoCap, etc.) <6 minutes
Animate a schoolyard fight between only two students (<4 minutes)
Animate his/her character in a school play's scene (< 5 minutes)

Undergraduates (some fine motor control)

Animate assembly of consumer product requiring three or more tools
and the assistance of another person (<15 minutes)
Animate the operation of a motor vehicle's controls while the vehicle
is in motion (<15 minutes)
Animate the operation of a human powered vehicle on various surfaces
(<10 minutes)

Graduates (a lot of fine motor control)

Animate playing a musical instrument during a concert performance (<
15 minutes)
Animate folding a load of functionally realistic clothes (< 20 minutes)
Animate hunting wild game (<20 minutes)

Post-Graduates

Animate four classes of surgical procedures with Bio-CAD and
patients' images (replacement, implantation, ...tetomy and
transplantation) [<60 minutes]
Animate a job interview for a white collar position (e.g., Chief
Executive Officer of a mid-size corporation) [<30 minutes]
Animate dying (fratricide, suicide and homicide) [<15 minutes]

Professionals

Animate long duration spaceflight effects [<180 minutes; representing
18,000 minutes]
Animate the bends (scuba diving incident) [<60 minutes]
Animate drug addiction [<60 minutes]

Current Work

Working group chairs keep the following pages up to date:

Joe and Don are working each Monday night [1700-1900 pacific, Web3D teleconference line) on

  • As those issues get sorted out, we are re-visiting all the important details regarding H-Anim skinning
    • Definitions, example test scenes, tool support
    • Proposing an improved H-Anim component for X3D v3.4
    • Editing a corresponding update to H-Anim ISO 19774 Specification

The larger group is also working on

  • interoperable, swappable behaviors
  • motion capture
  • facial animation

Anthropometry

Published References for review and citation

Ergonomic Models of Anthropometry, Human Biomechanics and Operator-Equipment Interfaces: Proceedings of a Workshop ( 1988 )

Professional Societies: Professional Certifications, Licenses in Anthropometry International Standards: ISO - Basic human body measurements for technological design -- Part 1: Body measurement definitions and landmarks IEEE -

North American Standards:

ANSI

South, Central, Latin American Standards:

European, Middle Eastern and African Standards:

Asian Standards:

Before

This wiki page is the site for the recently renewed Humanoid Animation (H-Anim) Working Group.

Humanoid Animation (H-Anim) WG Meeting

March 2012: H-Anim Working Group Draft Charter materials by Web3D Korean Chapter

Links of interest:

There has been previous work by the H-Anim working group during 2008-2009 that was not completed. Here are some additional links on the members-only wiki:

Much additional work has been proposed by the Korea Chapter.

  1. Definition of a humanoid character model capable of generating motion from captured motion data
  2. Definition of a humanoid character model capable of generating motion using a general motion definition such as keyframe, interpolation, kinematics and dynamics for human figures.
  3. Definition of motion parameters for transferring or exchanging motion between different human character models
  4. Definition of motion data interface for including motion data
  5. Definition of behavior modeling data
  6. Definition of motion viewer’s functionality
  7. Video human functionality and gestures will be considered in AR/MR working group efforts

We agreed on the 1 Feb 2012 teleconference that it is a good idea to document work on these many good ideas using this H-Anim public wiki. Further comment is welcome about this.

The main thing that is needed next is to get the H-Anim Working Group restarted and rejuvenated.

  • H-Anim WG Charter
  • TODO: we need 1-2 members who are willing to volunteer to serve as working group co-chairs.
  • Working Draft for the H-Anim motion definition (in preparation) H-Anim Motion Definition

William's Section!

Human joint articulation of any type (there are six: ball & socket, elbow, gliding, hinge, hip, and saddle joints) can be expressed using Euler angles or quaternions. The word quaternion is modified based on how it is used--rotation, orientation or attitude modifiers are germane but there are others for different use cases. There are multiple approaches to convert Euler angles into quaternions (http://en.wikipedia.org/wiki/Hamilton_product#Hamilton_product, http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation).

BVH conversion issues

Myeong Won Lee example: http://web3d.org/wiki/images/4/4b/197_a.bvh.txt

Proposed investigation procedure: divide and conquer! Let's take each skeleton apart and put them back together again.

1. Is there an X3D H-Anim skeleton that corresponds to the BVH ROOT/JOINT HIERARCHY?

The structures used by BVH and H-Anim are different. There is not a direct correspondence between them. Differences include:

  • The hierarchical nesting of parent-child relationships is different
  • Values are therefore in different coordinate frames (one might be relative to parent joint, the other absolute coordinates for the human)
  • Formats are quite different
  • (others will be listed here)

2. However many similarities also exist. Maybe they can be exploited?

Perhaps we can build a mapping between the two. If we perform rotation transformations, a conversion algorithm can be computed for each hierarchy and corresponding units.

Here is a possible set of correspondences between a BVH model and an X3D H-Anim LOA-1 model.

  • BVH :: X3D H-Anim
    • ROOT :: HAnimHumanoid
    • JOINT :: HAnimJoint
      • JOINT name:: HAnimJoint name
      • OFFSET :: HAnimJoint center
    • CHANNEL definitions :: HAnimJoint rotation, translation
      • MOTION array of Euler-degree rotations :: OrientationInterpolator MFRotation array with ROUTE connections
      • CHANNEL array of position translations :: PositionInterpolator MFVec3f array with ROUTE connections
    • End Site :: HAnimSite
    • Anything else?

TODO

  • map the BVH names to the approved H-Anim X3D names.

3. Once we have the skeleton mapping, we can work on the animation values.

Let's look at the BVH file next. Hypothesis:

  • BVH MOTION arrays providing Zrotation Xrotation Yrotation values

to

  • corresponding MFRotation arrays with 4-tuple SFRotation values

Example reconstruction follows. First is an extract from the BVH file, then a counting exercise of how many floats appear. 

 * ROOT Hips
   CHANNELS 6 Xposition Yposition Zposition Zrotation Xrotation Yrotation
   * JOINT Chest
     CHANNELS 3 Zrotation Xrotation Yrotation
     * JOINT LeftCollar
       CHANNELS 3 Zrotation Xrotation Yrotation
       * JOINT LeftShoulder
         CHANNELS 3 Zrotation Xrotation Yrotation
         * JOINT LeftElbow
           CHANNELS 3 Zrotation Xrotation Yrotation
           * JOINT LeftWrist
             CHANNELS 3 Zrotation Xrotation Yrotation
     * JOINT RightCollar
       CHANNELS 3 Zrotation Xrotation Yrotation
       * JOINT RightShoulder
         CHANNELS 3 Zrotation Xrotation Yrotation
         * JOINT RightElbow
           CHANNELS 3 Zrotation Xrotation Yrotation
         * JOINT RightWrist
           CHANNELS 3 Zrotation Xrotation
     * JOINT Neck
       CHANNELS 3 Zrotation Xrotation Yrotation
       * JOINT Head
         CHANNELS 3 Zrotation Xrotation Yrotation
   * JOINT LeftHip
     CHANNELS 3 Zrotation Xrotation Yrotation
     * JOINT LeftKnee
      CHANNELS 3 Zrotation Xrotation Yrotation
      * JOINT LeftAnkle
        CHANNELS 3 Zrotation Xrotation Yrotation
   * JOINT RightHip
     CHANNELS 3 Zrotation Xrotation Yrotation
     * JOINT RightKnee
       CHANNELS 3 Zrotation Xrotation Yrotation
       * JOINT RightAnkle
       * CHANNELS 3 Zrotation Xrotation Yrotation

Defines a MOTION array consisting of numeric values: 

 3 floats [Hip location]
 3 floats [Hip rotation]
 3 floats [Chest rotation]
 3 floats [LeftCollar rotation]
 3 floats [LeftShoulder rotation]
 3 floats [LeftElbow rotation]
 3 floats [LeftWrist rotation]
 3 floats [RightCollar rotation]
 3 floats [RightShoulder rotation]
 3 floats [RightElbow rotation]
 3 floats [RightWrist rotation]
 3 floats [Neck rotation]
 3 floats [Head rotation]
 3 floats [LeftHip rotation]
 3 floats [LeftKnee rotation]
 3 floats [LeftAnkle rotation]
 3 floats [RightHip rotation]
 3 floats [RightKnee rotation]
 3 floats [RightAnkle rotation]
 = 19*3 = 54 floats

Each line of the MOTION data has 19 triples. Therefore we do have a good match.

4. Units

Length

  • BVH position units: author-defined, arbitrary - no fixed units, apparently (TODO confirm)
  • X3D position units: 3-tuple x-y-z meters relative to point between feet on floor

Some scaling may be needed to get from BVH to X3D, either by a Transform scale or by a UNIT statement.

Angle

  • BVH orientation units: (Zrotation Xrotation Yrotation) Euler angles in degrees. Note that order may vary. (TODO confirm)
  • X3D rotation units: SFRotation 4-tuple (normalized x-y-z axis vector, angle in radians)

Given these definitions, we will need to convert the BVH orientation to X3D rotation. Ordinarily in 3D graphics this is performed using a 3x3 or 4x4 transformation matrix.

5. Converting BVH Motion Arrays to X3D Interpolators

The goal is to determine an algorithm to take BVH MOTION arrays to create PositionInterpolator and OrientationInterpolator.

First some definitions, then conversions, step by step.

5a. Computation of duration value

BVH excerpt: 

 MOTION
 Frames: 482
 Frame Time: 0.016667

Note that these units are seconds. Frame time matches 60 frames per second.

The first entry in the time array is at time zero. Therefore there are (482 - 1) = 481 intervals between each frame.

Thus total duration = (# intervals)(frame duration) = (481 * 0.016667) = (481 / 60) = 8.01667 seconds.

Using this computation, the derived X3D arrays can then be driven by a TimeSensor and key values at appropriate frame-time increments.

X3D TimeSensor duration is expressed by a value like 

  cycleTime="8.01667"

5b. Interpolator key array

In X3D, an interpolator key is typically a fraction from 0 to 1.0.

  • take total time interval of BVH file, example 8.01667 seconds
  • divide by number of intervals, for example 481
  • resulting key array would have fractions incrementing by (1.0 / 481) = 0.016667 (looks familiar)
  • add increments, result is
 key = "0 1/481     2/481       3/481      ...etc... 1" or
 key = "0 0.002079  0.002079*2  0.002079*3 ...etc... 1"
 key = "0 0.002079  0.004158    0.006237   ...etc... 1"

Note that the X3D Interpolator keyValue array will have same length as rotation array

  • must convert each triple of Euler angles to a corresponding SFRotation (see preceding section 4)
  • result will be something like
 keyValue="0 1 0 0.0, 0 1 0 0.111, 0 1 0 0.123 ...etc..." etc.

5c. TimeSensor and ROUTE

TimeSensor fraction_changed output is ROUTEd to OrientationInterpolator set_fraction. Result: 

 <TimeSensor DEF="AnimationClock" cycleTime="8.01667" />
 
 <OrientationInterpolator DEF="X3dMotionArray"
        key = "0 0.002079  0.004158    0.006237   ...etc... 1"
    keyValue="0 1 0 0.0, 0 1 0 0.111, 0 1 0 0.123 ...etc..." />
 
 <ROUTE fromNode="AnimationClock" fromField="fraction_changed"
          toNode="X3dMotionArray" fromField="set_fraction"    />

Informational note: the time values corresponding to the key values above do not have to be included in the scene. Nevertheless they are computed by a browser as follows: 

 key = 0       1/481         2/481         3/481 ...         481/481
 time: 0 8.01667/481 8.01667*2/481 8.01667*3/481 ... 8.01667*481/481  ==> 0 0.016667  0.016667*2  0.016667*3  ... 8.01667

5d. Computing keyValue arrays

This section examines how BVH values are excerpted and converted into various keyValue arrays. In other words, we take two frames of a BVH file to produce PositionInterpolator and OrientationInterpolator nodes.

Below is an example of two unmodified, unmarked BVH frames: 

 BVH Motion
 Frame 0:
 1.662 31.427 60.304  -1.249 -4.859 -3.582  4.463 1.354 0.075   -13.732 3.052 3.999  
 95.677   1.705 -1.512   5.541 -3.491 0.339   1.259 -3.022 1.790   6.765 2.405 -4.446  
 -91.027 -7.187 4.910   -3.633 0.867 0.043   -2.879 0.120 -5.688   -1.132 -1.858 0.809 
 -2.969 -8.472 1.461   -1.304 3.919 -2.045   1.054 9.006 -0.191   2.695 -1.341 -0.615 
 0.361 4.452 4.756   0.484 8.095 0.193   -6.340 -0.815 1.224
 
 Frame 1:
 1.659 31.427 60.307  -1.268 -4.835 -3.588  4.487 1.352 0.080   -13.802 3.059 3.999
 95.651   1.737 -1.609   5.541 -3.521 0.340   1.298 -3.030 1.974   6.795 2.410 -4.418 
 -90.999 -7.145 4.917   -3.633 0.825 0.043   -2.862 0.151 -5.736   -1.141 -1.863 0.806  
 -2.988 -8.482 1.455   -1.283 3.890 -2.157   1.055 9.042 -0.193   2.781 -1.350 -0.638 
 0.381 4.430 4.692   0.484 8.102 0.194   -6.266 -0.819 1.206

Next we will use excerpts from the above BVH frame values to show example conversions into X3D PositionInterpolator and OrientationInterpolator.

  • The keyValue array for the PositionInterpolator are obtained from the first three values at all frames.
  • The keyValue array for each OrientationInterpolator per joint are obtained by Euler-to-SFRotation conversion from the corresponding three values at all frames for each corresponding joint.
  • We do not yet perform the Euler-to-SFRotation conversion, but we show where it will occur.

Color codes: translation values, joint 1 rotations, joint 2 rotations, and joint 3 rotations 

 BVH Motion
 Frame 0:
 1.662 31.427 60.304  -1.249 -4.859 -3.582  4.463 1.354 0.075   -13.732 3.052 3.999 ...

 Frame 1:
 1.659 31.427 60.307  -1.268 -4.835 -3.588  4.487 1.352 0.080   -13.802 3.059 3.999  ...
 
 <PositionInterpolator DEF='HumanoidRootTransInterp' key='0 1/481 2/481 3/481 ...' keyValue='1.662 31.427 60.304,  1.659 31.427 60.307, ...' />
 <OrientationInterpolator DEF='HumanoidRootRotInter' key='0 1/481 2/481 3/481 ...' keyValue='f(-1.249 -4.859 -3.582), f(-1.268 -4.835 -3.588), ...'/>
 <OrientationInterpolator DEF='sacroiliacRotInterpo' key='0 1/481 2/481 3/481 ...' keyValue='f(4.463 1.354 0.075), f(4.487 1.352 0.080), ... '/>
 <OrientationInterpolator DEF='l_hipRotInterpolator' key='0 1/481 2/481 3/481 ...' keyValue='f(-13.732 3.052 3.999), f(-13.802 3.059 3.999), ...'/>
 
 where
 f(phi,theta,psi) means euler-to-SFRotation conversion. (Might need to check order of BVH rotations to match phi,theta,psi).

Using other expressions, here is a pattern for the conversion mapping from BVH to X3D keyValue arrays.

The meaning of these BVH value labels are as follows:

  • "0-tz" means "frame time 0, translation along z axis"
  • "1-rotz2" means "frame time 1, single Euler-rotation angle about z axis, for joint 2"
 BVH Motion
 Frame 0:
 0-tx 0-ty 0-tz, 0-rotx0, 0-roty0, 0-rotz0, 0-rotx1, 0-roty1, 0-rotz1, 0-rotx2, 0-roty2, 0-rotz2, ...
 
 Frame 1:
 1-tx 1-ty 1-tz, 1-rotx0, 1-roty0, 1-rotz0, 1-rotx1, 1-roty1, 1-rotz1, 1-rotx2, 1-roty2, 1-rotz2, ...

 <PositionInterpolator  DEF='HumanoidRootTransInterp' key='0.0 1/481 2/481 3/481 ...' keyValue='0-tx 0-ty 0-tz, 1-tx 1-ty 1-tz, ...'/>
 <OrientationInterpolator DEF='HumanoidRootRotInterp' key='0.0 1/481 2/481 3/481 ...' keyValue='f(0-rotx0, 0-roty0, 0-rotz0), f(1-rotx0, 1-roty0, 1-rotz0), ...'/>
 <OrientationInterpolator DEF='sacroiliacRotInterp'   key='0.0 1/481 2/481 3/481 ...' keyValue='f(0-rotx1, 0-roty1, 0-rotz1), f(1-rotx1, 1-roty1, 1-rotz1), ... '/>
 <OrientationInterpolator DEF='l_hipRotInterp'        key='0.0 1/481 2/481 3/481 ...' keyValue='f(0-rotx2, 0-roty2, 0-rotz2), f(1-rotx2, 1-roty2, 1-rotz2), ...'/>

5e. Conversion algorithm observations

In essence this work tries to duplicate the BVH animation expressions using X3D.

As shown in the above example, there are differences in the orders of position and orientation values between BVH and X3D Interpolator nodes.

  • In BVH, each frame includes a position x-y-z value for the root joint, and then 3-tuple Euler-angle rotation values for each and every one of the joints.
  • In X3D Interpolator, each joint has all position and rotation values for each of the timed frames.
  • There appears to be one-to-one correspondences between the data in BVH and the keyValue arrays in X3D.
  • In effect this reordering simply resembles a matrix transposition (vertical colored columns for BVH are mapped to horizontal colored rows in X3D).

We see the following file size characteristics in this conversion of BVH data into X3D Interpolators:

  • BVH does not need key arrays, because all time intervals are equal.
  • X3D is somewhat more verbose since the same key arrays are duplicated for all joints. This duplication of key arrays can lead to larger file size, in text form, but data compression can eliminate the cost of array copies.
  • There appears to be approximately the same amount of rotation information in each representation.
  • BVH has no ROUTE definitions. Typically there is only one ROUTE statement for the output of each node for each H-Anim humanoid. (There may be multiple ROUTEs for each node if there are multiple humanoids.)

Additional notes:

  • Time-based frame-by-frame expression is appropriate for animation sequences such as BVH, i.e. a frame includes a time stamp, a single position, and orientation values of all joints.
  • X3D viewers only use axis-angle SFRotation values, not quaternions and not Euler angles. For example, in an X3D OrientationInterpolator, if (1 0 0 0.5) means x-axis rotation with 0.5 radian, then (1 1 1 0.5) means an arbitrary axis from (0 0 0) to (1 1 1) with 0.5 radian rotation about that axis, using the right-hand rule for direction.

6. Conversion algorithm details

  • Define the function f(phi,theta,psi) for converting a single BVH Euler-angle triplet into a single X3D SFRotation axis-angle value.
  As shown in the BVH hierarchy as below,
  ------------------------------------------
 HIERARCHY
 ROOT Hips
 {
  OFFSET 0.000000 0.000000 0.000000
  CHANNELS 6 Xposition Yposition Zposition Zrotation Xrotation Yrotation
  JOINT Chest
  {
   OFFSET 0.000000 5.613096 0.000000
   CHANNELS 3 Zrotation Xrotation Yrotation
   JOINT LeftCollar
   {
     OFFSET 0.003804 10.354579 1.025227
     CHANNELS 3 Zrotation Xrotation Yrotation
     JOINT LeftShoulder
     {


In this BVH file, the order of one BVH Euler angle is z, x, y, while an X3D SFRotation includes the order of axes, x, y, z. So we must be careful that the order of angles in an Euler triple is different from the order of axes in an X3D SFRotation.

TODO: verify details. ==>

The transformation from BVH Euler angles to SFRotation is considered as follow:

Simply speaking, we must transform a triple value (x-rot y-rot z-rot angles in degree) into a quadruple value (x y z w angle in radian). Therefore, our transformation algorithm is as follows:

1) Choose the largest rotation angle among the three Euler angles.

2) Define the axis value as 1 for the rotation axis with the largest rotation angle for the quadruple.

3) Convert the largest angle in degrees into angle in radian, and this will be w for the quadruple.

4) The remaining axis values are calculated from the proportion of the rotation angle against the largest rotation angle.

For example, consider Euler angles (in degrees) x=90, y=45, z=-180.

  • From the algorithm, SFRotation is x=0.5, y=0.25, z=-1, w=3.14
  • For another example, consider Euler angles x=30, y=30, z=30.
  • From the algorithm, SFRotation is x=1, y=1, z=1, w=3.14/6.

The following is the implementation code of the algorithm: 

 void HAnim::ConvertEulerToSFRotation(float& x, float& y, float& z, float& w)
 {
   #define piover180 0.01745329252f

   float fAbsoluteX = abs(x);
   float fAbsoluteY = abs(y);
   float fAbsoluteZ = abs(z);
   
   float fMaxAngle = 0;
   
   if(fAbsoluteX > fMaxAngle)
      fMaxAngle = fAbsoluteX;
   if(fAbsoluteY > fMaxAngle)
      fMaxAngle = fAbsoluteY;
   if(fAbsoluteZ > fMaxAngle)
      fMaxAngle = fAbsoluteZ; 

   float fRatio = 0.0f;
 
   if(fMaxAngle > 0.0001f)
      fRatio = 1.0f / fMaxAngle; 
  
   x = x * fRatio;
   y = y * fRatio;
   z = z * fRatio;
 
   w = fMaxAngle * piover180;
   w = abs(w);
}

7. How to convert?

With a little more work, we can then combine the pieces to show corresponding animations in HAnim and BVH. We can build an application program that uses these mappings.

  • This conversion program operates off-line, not within an X3D scene, because X3D does not allow reading files.

Wikipedia articles of interest:

It looks like choosing the right matrix operations will perform this conversion. This requires careful composition of rotation matrix operations.

BVH references of possible value

Retrieved from "https://web3d.org./wiki/index.php?title=H-Anim&oldid=8082"