[x3d-public] Maya/RawKee first HAnimMotion export test
Joe D Williams
joedwil at earthlink.net
Sun Oct 26 11:32:34 PDT 2025
The x y z order and intention of these euler angle forms can vary.
>From references and from the pov of the model (you looking at you),
usual set is +z up, +x is forward (default model gaze direction),
and +y increases towards model left (viewer right).
This compares with the x3d (same as default webgl) model
coordinate system with +x increase toward model left,
+y up, and model gaze toward +z.
>From pov of model, Right-hand rule for + and - axis direction
of rotation.
If you are positioned on the default Transform facing +z,
the x y z is pitch, yaw, roll.
What is the reliable transformation between these
from what is found in the BVH if confirmed to be
a set of properly labelled x and y and z angles
for each keyframe?
Incidentally, this borders on another interoperability
opportunity when it is desired to produce
conversion of a model drawn and animated in
the +z up system that is intended for use in
the +y up system.
And, it turns out, commonly from +y up to +z up.
Please remember, we need to consider all of
models, animations, and viewpoints.
First, at least the BVH will tell us what
data the file defines as x and y and z axis.
So it if comes in as z and y and x, or other,
then we sort to x and y and z order.
The next question is if the Joint centers are
given as relative to each other, or to 0 0 0.
If the DCC did not include 'center' as a standard
Transform parameter, then the joint nodes xyz may
be located relative to the first joint node, which
may be set relative to 0 0 0. Then, child nodes
translation is relative to its parent in the hierarchy.
We can mostly tell whether the joint center of rotation
value is set by absolute center relative to 0 0 0, or
relative to each other by looking at animation data.
If the effective joint center value is given as relative
to its parent, then the skeleton is really only useful
at authortime. The skeleton can be posed and the
DCC records the each joint translation and rotation
for the keyframe. The animation data for delivery then
consists of translation and rotation data for each
joint for each frame. At runtime the skeleton is
not really treated as a hierarchy, but just a
set of nodes that get positioned and rotated,
actually independently of each other for each frame.
So, if you find animation data for both translation
and rotation for each joint for each frame, then
the skeleton joint data must mostly certainly
be processed by accumulating the relative
values according to given hierarchy to find the
actual joint centers for the skeleton.
On the other hand, if the data consists only of
rotation data for each Joint, then the runtime is
using the hierarchy to do the work of positioning
child joints according to rotation of parent hierarchy.
For all to see, this points at the skill and wisdom
of the people, mainly animators, that determined
our Transform shall include a center value.
They saw that animating a hierarchy with a center
value that is relative to the translation value gave
power that extended both authortime and runtime
control capabilities.
Thanks and Always More Fun with Transform center
Joe
-----Original Message-----
From: Extensible 3D (X3D) Graphics public discussion <x3d-public at web3d.org>
Sent: Oct 25, 2025 11:36 AM
To: Don Brutzman <don.brutzman at gmail.com>, Extensible 3D (X3D) Graphics public discussion <x3d-public at web3d.org>
Cc: Bergstrom, Aaron <aaron.bergstrom at und.edu>
Subject: Re: [x3d-public] Maya/RawKee first HAnimMotion export test
Don,
To be honest, I’m surprised the HAnimMotion export actually worked as I made some educated guesses at some things based on the what I could gather from the spec and the “KoreanCharacterMotionAnnexD01Jin.x3d” example… and Holger’s related email.
The Advanced Skeleton character rigs like Conan aren’t good use-cases when it comes to standardized HAnim skeletons above LOA 0. Other than the root node, the Conan character’s pseudo “drawlabel” Maya attributes (which correspond to the HAnimJoint node’s “name” fields) aren’t filled in.
If the Maya joint’s “drawlabel” pseudo attribute is empty at export time, I have RawKee populate it using the HAnimJoint’s DEF value. This then exports the HAnimJoint’s “name” field with the same value as it’s DEF. I’m doing this just so there can be matching “name/joints” values between the joint and motion nodes for export testing the. But this only happens if “drawlabel” is empty.
Next week, Ariann (our DREAM Lab artist) will begin making original Maya characters whose joint nodes will have “drawlabel” pseudo attributes set to the proper HAnimJoint “name” values. When these characters are exported, their motion nodes will be using the standard LOA HAnimJoint “name” field values.
After sleeping on it, I decided that there is a simple technical way to setup the HAnimMotion node export with a ZXY rotation order (or any rotation order).
It will require me to change a bunch of GUI and scenegraph traversal code. So it’s simple in that it’s technically simple in Maya if I had programmed it that way in the first place, but not so simple since I have to change a bunch of code.
But it doesn’t require any real brain power on my part. It’ll just require me to grind out the coding changes. The nice-to-have features from others’ feedback on RawKee’s HAnim export are starting to stack up, so I’m going to put in the effort to make all of these changes.
And I need to make some major GUI changes anyway… the GUI changes are the tedious time-consuming part.
I hope to have those revisions completed by the end of Nov… maybe sooner, but maybe more like the end of the year depending how much time I devote to the USD-to-X3D file translator.
Aaron
From: Don Brutzman <don.brutzman at gmail.com>
Sent: Saturday, October 25, 2025 11:47 AM
To: Extensible 3D (X3D) Graphics public discussion <x3d-public at web3d.org>
Cc: Bergstrom, Aaron <aaron.bergstrom at und.edu>
Subject: Re: [x3d-public] Maya/RawKee first HAnimMotion export test
Wow Aaron this is so great! LOL! 😄 👍
Observations:
* We have seen many variations in XYZ rotation ordering over the years, and should not expect to define the "right" ordering. Rather we do have to map inconsistencies to a common approach if we want repeatable animation.
* There is a very easy, simple technique to avoid mathematical manipulations when shifting coordinate frames. Simply have three nested Transform nodes for Roll Pitch Yaw (or whatever they are being called) and set values on each individually.
* These are computationally very efficient. Browsers likely do that automatically when computing the transformation matrix.
* X3D-Edit Transform node includes a "rotation calculator" that let's an author do that at modeling time, if you want to go further and look for example code.
* The three-nested-Transform-nodes approach is described in X3D for Web Authors book chapter, slideset, and examples.
and
* HAnimMotion node carefully includes most of the structural animation found in a BVH file for the same very-good reasons
* the joints field lists names what HAnimHumanoid joints are being animated, in order
* the channels field lists has corresponding information for each joint, describing how many values are found in a row/frame and what axis they correspond to
* thus there is no ambiguity when parsing the values array of frame-by-frame data regarding exactly which rotations go where
* Example from KoreanCharacterMotionAnnexD01Jin.x3d
* <HAnimMotion DEF='hanim_motion_animation' containerField='motions'
* description='BVH-derived dance movement' enabled='true'
* channels='6 Xposition Yposition Zposition Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation 3 Zrotation Xrotation Yrotation'
* joints='HumanoidRoot l_hip l_knee l_talocrural r_hip r_knee r_talocrural vl5 IGNORED l_shoulder l_elbow l_radiocarpal IGNORED r_shoulder r_elbow r_radiocarpal IGNORED skullbase' loop='true' name='motion_animation'
Appreciate your careful diligence with these twists and turns. Such things are never easy to get exactly correct, but when we align with a shared common standard then we only have to succeed once!
p.s. endless improvement department: gee when designing HAnimMotion node, i wish we had called the names field jointNames instead for correctness.
all the best, Don
--
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting https://RelativeMotion.info
On Fri, Oct 24, 2025 at 8:03 PM Bergstrom, Aaron via x3d-public <x3d-public at web3d.org (mailto:x3d-public at web3d.org)> wrote:
I successfully implemented HAnimMotion node export from Maya using RawKee.
You can see a video of the result running in Sunrize
https://drive.google.com/file/d/1JBe6kO1UnbsXvfpMKfI-75DhpDdzng-L/view?usp=sharing
If you look closely, you will notice that the rotation values are in the following order:
Xrotation Yrotation Zrotation
This is different from the recommend rotation order of:
Zrotation Xrotation Yrotation
Here is my justification.
I’m guessing that mocap systems that use BVH to record data have a rotation order of ZXY.
However, characters in Maya, at least the ones that I have worked with, have a joint rotation order of XYZ.
Maya allows the artist to choose the rotation order of its joints. So I wrote the exporter so that it would export HAnimMotion nodes based on the joint rotation order chosen by the artist.
The Conan character’s joint rotation order in Maya is XYZ.
>From what I can tell, this is allowed by the spec, even though it might not be the recommended practice.
It’s just not worth effort for me to do all the math required to force the animator to use an ZXY joint rotation order. Because that would completely mess up the animation within Maya.
The animation in the video looks slightly different than the TimeSensor/Interpolator version of the same animation, because the HAnimMotion version doesn’t export all the joint “translation” animations used by the Advanced Skelton tool.
This is actually not a problem, as I only told it to export the joint position of the root joint node, but all the rotation values for the entire skeleton. I could have just as easily had RawKee export all the Position and Rotation information for all the joint nodes.
We can debate whether or not I should allow anything other than ZXY joint rotation order, and we can debate whether I should allow position data to be exported for all joints, but it’s essentially working
RawKee can now export HAnimMotion nodes.
I’ll make a new release available once I’ve cleaned up a couple GUI issues and I enable AudioClip and MovieTexture support.
_______________________________________________
x3d-public mailing list
x3d-public at web3d.org (mailto:x3d-public at web3d.org)
http://web3d.org/mailman/listinfo/x3d-public_web3d.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20251026/5f595ce1/attachment-0001.html>
More information about the x3d-public
mailing list