[x3d-public] FW: BVH to X3D Conversion bug

Mon Nov 7 15:15:31 PST 2022

Joe >> However the piro bvh example is Not Level 1, or any level because the bvh skeleton is (typically) Not a legal Hanim level of articulation. 
This skeleton may be typical in bvh archives because it is a legacy artifact from before we had a world standard realistic skeleton. Just look at it. Is that the way your back works? But, the bvh skeleton is simple for simple stuffs.

A point is that the bvh skeletons I have seen are not any Hanim level because the spine is connected in a different way. There are other minor difs also. 

In the following, it is first about how to use a Standard Hanim skeleton with the bvh animation. 
Please not simply activating the bvh capture skeleton with the bvh animation because the bvh skeleton is probably not a standard hierarchy Hanim skeleton. 

➢ As far as which approach is best – not currently an issue.  At present, am simply trying to convert legacy BVH files into the most compliant X3D HAnim possible.  That path can give us a LOT of content.  Still moving forward, so far…

Which is best is not an issue because bvh is not an authoring approach, it is a transport approach. For example, data from a defined bvh capture skeleton applied to a defined playback skeleton. The main problem is that the bvh skeleton is (probably) not any Hanim skeleton. 
I think we get usable content when the bvh animation is incorporated with _your_ “Standard” Hanim skeleton. 

The animation is fully  incorporated with your skeleton when the animation is set up using x3d animation styles with reasonable keytimes and keyframe data, and therefore can be used as a basis for detailed animation of _your_ skeleton. 

Another idea for the x3d user code would be to allow construction of an interpolator that just listed the constant keytime interval instead of every keytime. That is what the gltf prefers since the rules for setting key times is more simple than x3d. However, since the bvh is aimed at video, that still leaves the problem of mostly too much keyvalue data. 

If we can provide a reasonable conversion from the bvh skeleton to Hanim loa4, then the user can edit and simplify the key and keyvalue data to finally adapt the animation to the target skeleton and integrate it with other animations.

Thanks Again, 
Joe

Again, the reason the target playback is a ‘standard’ loa4 is that the player will not complain if there is a joint that is not animated. The author can always easily add animation of joints not controlled by the bvh import. 

From: Brutzman, Donald (Don) (CIV)
Sent: Sunday, October 30, 2022 12:21 PM
To: Joseph D Williams
Cc: X3D Graphics public mailing list; Brutzman, Donald (Don) (CIV)
Subject: RE: [x3d-public] FW: BVH to X3D Conversion bug

Joe you are correct historically – but we added a third level for HAnim motion node in X3D4.  Schema, DTD are up-to-date, examples corrected too.  Am correcting other tools and diagnostics as I find them.

• X3D4 Architecture, Clause 26 Humanoid Animation (HAnim) component
• Table 26.2 — Humanoid animation (HAnim) component support levels
• https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/components/hanim.html#t-supportLevels

As far as which approach is best – not currently an issue.  At present, am simply trying to convert legacy BVH files into the most compliant X3D HAnim possible.  That path can give us a LOT of content.  Still moving forward, so far…

Building an X3D widget to follow your note and control frame-by-frame timing of HAnimMotion advancement by TimeSensor will be interesting…

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br        brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA    +1.831.656.2149
X3D graphics, virtual worlds, Navy robotics https:// faculty.nps.edu/brutzman

From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Joseph D Williams
Sent: Friday, October 28, 2022 7:04 PM
To: X3D Graphics public mailing list <x3d-public at web3d.org>
Subject: [x3d-public] FW: BVH to X3D Conversion bug

Brought out to public

From: Joseph D Williams
Sent: Friday, October 28, 2022 5:49 PM
To: John Carlson; Norbraten, Terry (CIV); X3D Graphics public mailing list
Cc: Brutzman, Donald (Don) (CIV)
Subject: RE: BVH to X3D Conversion bug

➢ The Pirouette.x3d has
➢ <component level='1' name='HAnim’/>

An error.
Hanim has basically two levels – 
skeleton with segment geometry and 
skeleton with skin. 
Check me on this. 
However the piro example is Not Level 1, or any level because the skeleton is Not a legal level of articulation. 
This skeleton may be typical in bvh archives because it is a legacy artifact from before we had a world standard realistic skeleton. Just look at it. Is that the way your back works? But, it is simple for simple stuffs.

If you play with this loa non-conformer, like for instance hook the animation up to any of the more or less standard and proven stand walk run jump twist etc. animations in the archive, then I am fairly sure you will see unexpected gestures. And, when one or some of these work in a ‘standard’ hierarchy skeleton, then add it to the “Standard” examples. 

Certainly, as you progress with authored hanim animation style, then you will wish you had started with current vs legacy skeleton, same as possible regret if you started with anything else than an loa4. 

However, this example certainly shows that out of any bvh collections, the native production is probably only a very rough starting point with lots of work left to adapt the captured motion to a usable playback character. 

So (from the Peanut Gallery), please do not run that non-conforming skeleton as a conforming hanim character anymore unless, If you really can’t get conforming x3d hanim skeleton as playback, then please don’t archive as hanim without proper bvh skeleton Disclaimer. 
Again, just convert to use the ‘standard’ loa4 as the target playback, at humanoid scale. Then, if interesting, the animations can be extracted for use in a legal skeleton and coded for realtime rather than videotime. Please don’t just simply recreate the bvh-encoded skeleton – convert directly to loa4 at human scale and then you can see what you really have.  

Please note one advantage of the typical video frame rate seen in these animation thingees, is that to make a video from these your player does not need to use interpolators since you give it the exact keyframe interval data. 

More fun with realtime hanim. 

Best regards,
Joe

From: John Carlson
Sent: Friday, October 28, 2022 2:53 PM
To: Joe D Williams; Norbraten, Terry (CIV)
Cc: Brutzman, Donald (Don) (CIV)
Subject: Re: BVH to X3D Conversion bug

Last i heard, HAnim is acceptable.  Joe can confirm, cced.

On Fri, Oct 28, 2022 at 10:00 AM Norbraten, Terry (CIV) <tdnorbra at nps.edu> wrote:
One issue is that the BVH converter is not translating the correct level for H-Anim. 

The Pirouette.x3d has

<component level='1' name='HAnim’/>

Should be

<component level='1' name=‘H-Anim’/>   <<< require the hyphen 

On Oct 28, 2022, at 05:59, Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> wrote:

Thank you John for excellent logs and sleuthing.

Terry, the error immediately jumping out at me is the following.  At least one library is not getting bundled properly.

• java.lang.ClassNotFoundException: javax.vecmath.Vector3d

Great discussion yesterday Terry, thanks.  I have created the pre-release file site at

• https://sourceforge.net/projects/x3d/files/X3D-Edit%20Pre-Release%20Testing/

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br        brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA    +1.831.656.2149
X3D graphics, virtual worlds, Navy robotics https:// faculty.nps.edu/brutzman

From: John Carlson <yottzumm at gmail.com> 
Sent: Thursday, October 27, 2022 12:09 PM
To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; Norbraten, Terry (CIV) <tdnorbra at nps.edu>
Subject: Re: Trying new download--X3D-Edit 4

NPS WARNING: *external sender* verify before acting.

I have confirmed the Pirouette.bvh in archives and pirouette.bvh are the same, essentially, just different whitespace.   I will now try to see if X3D-Edit will load the archive version. 

Attached are the logs that are showing up in Windows 10 X3D-Edit dev/var/log.

I haven't looked into them yet, I will now move to Linux.

If you could send me the X3d-Edit steps how to convert BVH to X_ITE and X3DOM, that would be great.

Forward old email if necessary.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20221107/8a4a781e/attachment.html>