[x3d-public] Units for BVH vs HAnimMotion.values

[Joe D Williams]

> Freewrl has implemented HAnimMotion and is currently expecting degrees, but willing to add a field on the Motion node to specify angleUnits so will take either. 

The mocap outputs have always had the choice to output bone orientation and later with  better fidelity, joint rotation in any form they wish, given that data they have. The data is always relative to one or more standard poses to produce the desired result. Detailed high performance captures quickly found that reliance on degrees for capture and playback could and often did cause interruptions due to glock or other artifacts found using angles.

For authoring tools to default to euler angles is really only for tribute to Ray Harryhousen thoughts to somehow regularize the art of manipulating the armature, and for introductory use, to make it look more simple than it is. Later, we have computers that can do math and show pictures of using the math.

In a way it is like bones and joints. For the skeleton, the simple default 'character animation' tool may show bones as the user interface while the math uses joints as the basis for computing motion. For the animation details, the gui shows angles, the math uses unit quaternion or axis-angle as the basis for the math. Finally, l don't find gltf or any other style allows keyValues for rotation or orientation in degrees.

So, in order to take control of the bvh animation, retrieve the skeleton and set it in terms of closest HAnim loa. Maybe just run the degrees and if seems useful, convert to x3d interpolators, Eliminate excess keys and keyValues. If animation turns out to be useful and transportable, incorporate the animation into an HAnim loa4 for archiving. 

The bvh file does not have a set way to tell you its units for animation. How will you tell if the default angleUnits is wrong or what the user stated is wrong? 
 
Please keep in mind (my opinion) that in this big world, this bvh stuff might serve is as an import for discovery, development, and  adaptation; not directly for current production, transport, and delivery.  
      
All Good Fun,
Joe

-----Original Message-----
From: GPU Group <gpugroup at gmail.com>
Sent: Oct 13, 2023 12:50 PM
To: John Carlson <yottzumm at gmail.com>
Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
Subject: Re: [x3d-public] Units for BVH vs HAnimMotion.values

Freewrl has implemented HAnimMotion and is currently expecting degrees, but willing to add a field on the Motion node to specify angleUnits so will take either.-Doug
 



On Fri, Oct 13, 2023 at 1:47 PM GPU Group <gpugroup at gmail.com (mailto:gpugroup at gmail.com)> wrote:
I have the same question and posted it on h-anim. Might help to have some options and analysis of the options.1. Units statement 
Analysis: that would apply to all rotations in the file, including other scenery Transform rotations which is awkward for most workflows
2. Motion.values in radians by default
Analysis: will break some scene example data such as HAnim Annex D Motion.values which is in degrees
- would need to update Annex D
3. Motion.values in radians by default, and browsers can support degrees with a field 
Motion {
SFString [] angleUnits 'RADIANS' ['RADIANS', 'DEGREES']
//or
SFBool [] angleUnitsDegrees FALSE
}
Analysis: would still break the Annex D example which doesn't show any Motion field for angle units, and would need to update the specification for Motion to include an additional field.
4. export in degrees, and put an export option on the export option panel for Motion data in [degrees, radians] so browsers will still work either way until a more permanent solution such as 2 or 3.
Q. how many web3d browsers have implemented HAnimMotion and angle units did you use for Motion.values ?
-Doug


On Fri, Oct 13, 2023 at 12:44 PM John Carlson <yottzumm at gmail.com (mailto:yottzumm at gmail.com)> wrote:
Apparently BVH uses degrees for rotations.  Units for HAnimMotion should use radians unless otherwise specified in a UNIT statement, AFAIK. 
Comments?
 
Thanks!
 
John 
_______________________________________________
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/20231013/2d5e8d11/attachment.html>