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

Mon Nov 7 17:01:01 PST 2022

My albiet impractical approach was to bring your own skeleton, and add
whatever motion there is in the bvh file to the Motion object or
HAnimMotion element.   I did not realize that BVH files contained their own
skeleton.   Seems like one should Protoify a standard skeleton and pass the
motion as a parameter.   But I didn’t even get a chance to adequately look
at a bvh file beforehand.   May I suggest we pursue the Motion method, if
we are all in agreement?

I realize that X3DOM/Xj3d may not support the Motion/mocap stuff in XML.
I’m not aware if these are currently supported.  I do know that X_ITE
does.  I do know there is BVH handling in JavaScript.

So it seems like we’re translating bvh to non-standard skeletons, instead
of translating BVH to standard motion.

John

On Mon, Nov 7, 2022 at 5:16 PM Joseph D Williams <joedwil at earthlink.net>
wrote:

> 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) <brutzman at nps.edu>
> *Sent: *Sunday, October 30, 2022 12:21 PM
> *To: *Joseph D Williams <joedwil at earthlink.net>
> *Cc: *X3D Graphics public mailing list <x3d-public at web3d.org>; Brutzman,
> Donald (Don) (CIV) <brutzman at nps.edu>
> *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 <joedwil at earthlink.net>
> *Sent: *Friday, October 28, 2022 5:49 PM
> *To: *John Carlson <yottzumm at gmail.com>; Norbraten, Terry (CIV)
> <tdnorbra at nps.edu>; X3D Graphics public mailing list
> <x3d-public at web3d.org>
> *Cc: *Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> *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 <yottzumm at gmail.com>
> *Sent: *Friday, October 28, 2022 2:53 PM
> *To: *Joe D Williams <joedwil at earthlink.net>; Norbraten, Terry (CIV)
> <tdnorbra at nps.edu>
> *Cc: *Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> *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/
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fprojects%2Fx3d%2Ffiles%2FX3D-Edit%2520Pre-Release%2520Testing%2F&data=05%7C01%7Cbrutzman%40nps.edu%7Ccfce743709d84501fcd208dab9521e76%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638026059745002134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=5nGgyeQabvwSA5rQbsW5k1%2FOxZJgoQlYKbvhjYYhaeI%3D&reserved=0>
>
>
>
> 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.
>
>
>
>
>
>
> _______________________________________________
> x3d-public mailing list
> 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/20221107/3aefd213/attachment-0001.html>