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

Sat Oct 14 11:44:13 PDT 2023

Joe > We are not using it that way because we will always interpolate.  

"always" meaning realtime may allow interpolating between key times, even if keyframes are provided at standard video/film frame rates. It is typical that through good use of interpolation, key times and keyValues can and should be much reduced.

Another issue is what to do when the dimensions for hanim model like skeleton or skin are given in cm and HAnim wants m. One solution is to simply scale by 0.01 in the user code. As you will probably see when you try to animate the thing lthat the rescale solution was too simple. 

But wait, I didn't forehead slaps when I said just move the decimal point instead of multiplying by 0.01 (to get m from cm). Recall that in authortime, which is when you want to make the conversion, we have a text file. So, for any case, moving the decimal point using a text editor in authortime is more accurate in terms of representing the author's intent, than multiply by 0.01 in runtime. 

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

> Agreed that BVH/HAnimMotion should be converted to Interpolators, hence my plea for shared keys between Interpolators.   

Don't concern yourself about the repetition. It is what it is. We just have to deal with it.The bch will probably include a key for each video frame since one objective is to not do any interpolation. We are not using it that way because we will always interpolate.  
The next step to make it usable is to process to remove extra keys and keyvalues. If small frame interval, then probably lots of extra frames when we can interpolate.

> Should I look into a single MetadataFloat for all Interpolators keys? 

No because the right way, without a script is to justeliminate unneeded keys andkeyvalues. 
Maybe a different project task than getting Grampsrunning. 

> Programming a script that won't work in view3dscene?   

Not a real help now.

> Mot Using a PROTO that may not work across all Interpolator node types?  Doing a PROTO per Interpolator type and animation sequence?  How many ProtoInstances do you want to see in your animation code?  Abandoning HAnimMotion as unworkable seems reasonable, except for bloat. 

Just don't worry about that bloat for now.

Joe 

On Fri, Oct 13, 2023 at 7:07 PM Joe D Williams <joedwil at earthlink.net (mailto:joedwil at earthlink.net)> wrote:
> Apparently BVH uses degrees for rotations. 

It is not specified. There is no spec. Degrees do not appear in any x3d user code, or any where else except these too simple to use directly random examples in random bvh archives, or defult spitout of some glorified animation tool. char. Literally any animation tool worth having does not do them in terms of degrees, junk coding. If tool cannot export quaternions or axis-angle it is not worth using. And just because the helpdesk doesn't know about it doesn't mean they don't have it.

The conversion from typical bvh to axis-angle is in Part 2.
Just do the conversion and don't worry about using angles anymore. There is no standard way to interpolate angles, and for good reason. 

A bvh file is NOT x3d user code, it is just a partially documented importation that may be adapted for use with x3d HAnim. This is true no matter if it comes from some instructor-student archive somewhere on the web, or hot off the press to represent some current character animation tool generated keyframes. Even if pretty-printed with x3d it is not x3d. 

Just convert the stuff and apply to skeleton. Don't deal with the angles bs except to convert it to x3d interpolators. It is just an import format, not standard, and not x3d. 

Just convert for most fun,
Joe

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

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/20231014/c7f26e8b/attachment-0001.html>