[x3d-public] Maya/RawKee first HAnimMotion export test

Sat Oct 25 11:35:15 PDT 2025

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/20251025/a9c8008f/attachment-0001.html>