[x3d-public] Purpose of X3Dng -- Animation (of humanoid models)
Joe D Williams
joedwil at earthlink.net
Sun Oct 23 21:03:11 PDT 2016
Anyone interested in HAnim has to look at this
http://ws680.nist.gov/publication/get_pdf.cfm?pub_id=150282
> Similarly, it makes no sense to change what we have in H-Anim until
> we have direct evidence of problems or how to accomplish potential
> improvements.
Fine Don, so true, Thanks. Goes right along with having direct
evidence of solutions:)
> Observation: SFRotation axis-angle representation is mathematically
> equivalent to quaternions, so there is no conversion issue there.
True, there is no issue except other tools are more likely to export
of import unit quaterion (uq) form. So, for glTF, for example, X3D
will always be seeing uqs. In practice, all more current X3D tools
will convert internally to uq for the animation computations. An idea
is maybe something like units that allows the author to specify the
standard form as unit quaternion in SF and MFRotation. Yes uq and aa
are mathematically equivalent but not the same. For one thing there is
a computable proof that the uq is valid, and only valid ones can be
used. For axis-angle, this is not so clear because most any set of
numbers will produce a 'valid' result. Maybe not so complicated, but
just different enough so X3D will want to know what is coming in.
> Personally, am hoping to get back to work on the
> BVH-mocap-to-X3D-interpolators converter code
OK but the above issue should prepare you for the fact that uq may be
input instead of x-y-z angles in degrees. In reality, you can expect
any form of data out of mocap depending upon what the user asks to be
exported. Advanced mocap users will choose uq outputs for convenience
and especially if there is any chance of changing the time base
downstream. At least you can easily tell if the rotations are uq, not
so easy to tell what you have with the angles data.
> Current H-Anim example models:
>
> http://www.web3d.org/x3d/content/examples/Basic/HumanoidAnimation
Those need some attention when you get some time.
> That should establish a baseline of 2 mocap-related implementations
> that can help us continue to improve.
Great, the topic is skeletal animation. I believe that you will
produce a conversion process to accept mocap keyframe data referenced
to the coordinate system and initial pose of a near 'standard' capture
skeleton, convert as necessary to reference the data to a 'standard'
X3D HAnim skeleton operating as a realtime character (keyframe
interpolators), then animate the 'standard' character with that data.
Of course the target 'standard' skelton for now should be the LOA3
motion model being refined in the example archive.
> am expecting the differences between different approaches will
> appear simpler, clearer, more adaptable, and easier to support.
are we seeing some differences? different approaches that lead to
different results? Please don't scare me, Don. This stuff is simple
enough with no need to add complications.
> Looking further ahead. ...
Great Don, a big thing is to keep the skeleton, skin, segment
geometry, organs, and accessories all drawn in human space, the Annex
A C-space default initial pose. It is just a fact that all works
better if no extra transforms needed to compose the character. For
example if medical parts are composed using human scale then all
organs and features will fit right into our hanim character. Same for
CAD.
>>> It would be fantastic if e.g. Blender armature animation was
>>> exported
If we can get a sample for examination, maybe we can add it to the
list of forms that can be imported.
Lots of Fun,
Thanks,
Joe
----- Original Message -----
From: "Don Brutzman" <brutzman at nps.edu>
To: "Joe D Williams" <joedwil at earthlink.net>; "Michalis Kamburelis"
<michalis.kambi at gmail.com>
Cc: "Humanoid Animation (H-Anim) Working Group" <h-anim at web3d.org>;
"X3D Public" <x3d-public at web3d.org>
Sent: Sunday, October 23, 2016 3:51 PM
Subject: Re: [x3d-public] Purpose of X3Dng -- Animation (of humanoid
models)
> [cc: h-anim]
>
> Summary: a lot of capability is steadily adding up with H-Anim, and
> beginning to overlap with Medical and CAD.
>
> Great observations below, Joe and Michalis! 8) Thank you. Here
> are some reactions.
>
> We have had a lot of work to achieve progress towards X3D version 4.
> (Don't know what the subject-line "X3Dng" refers to.) Recent
> progress is confirming that the work on X3D Object Model has been
> fundamentally important as a way to ensure that the entire X3D scene
> graph is consistent and coherent across every file encoding and
> every programming language binding. So we are really building for
> scalable, repeatable success.
>
> Observation: SFRotation axis-angle representation is mathematically
> equivalent to quaternions, so there is no conversion issue there.
> Matrix rotations are also almost-fully equivalent with only a few
> edge-case anomalies like the possibility of exceptions when
> computing inverses. So mapping to different forms of rotations is
> not particularly difficult when using X3D SFRotation, it just takes
> close attention to detail. (One virtue of programming, even when
> challenging, is that You Only Have To Get It Right Once.)
>
> Personally, am hoping to get back to work on the
> BVH-mocap-to-X3D-interpolators converter code before the end of the
> year. Goal is to have this open source Java running and producing
> X3D animations, just like Suwon University's C++ code did for their
> H-Anim Music Video competition. That should establish a baseline of
> 2 mocap-related implementations that can help us continue to
> improve.
>
> https://svn.code.sf.net/p/x3d/code/www.web3d.org/x3d/tools/X3dEdit3.3/X3D/src/org/web3d/x3d/hanim/bvh/
> BvhSkeletonParameters.java
> Hierarchy.java
> Joint.java
> Motion.java
>
> All of the recent review activity and interest during the H-Anim
> specifications review is certainly a wonderful development. When
> all of the other H-Anim specification comments are assembled from
> participating ISO national standards bodies, we can plan on an
> Specification Editors Meeting to consider issues and best plans for
> resolutions. Meanwhile, as time permits, the H-Anim and X3D Working
> Groups can continue looking at the baseline mantis issues list to
> prepare potential solutions.
>
> I also agree that the path to success lies through implementation
> and evaluation. As we keep building examples, and implementing
> conversions, and adding tool support, am expecting the differences
> between different approaches will appear simpler, clearer, more
> adaptable, and easier to support. Similarly, it makes no sense to
> change what we have in H-Anim until we have direct evidence of
> problems or how to accomplish potential improvements.
>
> Current H-Anim example models:
>
> http://www.web3d.org/x3d/content/examples/Basic/HumanoidAnimation
>
> Regarding importance of H-Anim tutorials: another point well taken.
> Here is one with 97 slides (second half includes slides + annotation
> notes). Questions, corrections and suggestions for improvement
> welcome.
>
> http://x3dgraphics.com/slidesets/X3dForAdvancedModeling/HumanoidAnimation.pdf
>
> Does it make sense to add adaptation/conversion of Blender character
> animations into H-Anim models as a goal? Blender does have
> excellent general support for X3D export/import (on its top-level
> File menu). If so, we could add it to:
>
> web3D.org > PARTICIPATE > Projects Wish List
> http://www.web3d.org/projects/wish-list
>
> Perhaps someone wants to look at Cobweb source and help out with
> adding support for H-Anim nodes. Not so hard, the pattern is
> somewhat similar to CAD nodes, already implemented in X3DOM; yet
> another open-source example implementation is available as X3D
> prototypes (no Script needed) at:
>
> X3D Example Archives: Basic, Humanoid Animation, HAnim Prototypes
> http://www.web3d.org/x3d/content/examples/Basic/HumanoidAnimation/HAnimPrototypesIndex.html
>
> Cobweb Supported Components
> http://titania.create3000.de/cobweb/#c426
>
> Looking further ahead. There is one more clarion priority for
> H-Anim progress: modeling human joints, bones, skin and motions at a
> resolution suitable for medical applications and electronic health
> records. Alignment of DICOM-standard medical imagery as X3D volume
> presentations is another emerging major asset. Common interest with
> CAD group in metadata annotations, 3D printed parts (splints,
> prostheses, devices) and 3D scanning is also truly compelling. The
> CAD and medical workshops at the Web3D 2016 Conference in Anaheim a
> few months back showed that much is possible. Early-exemplar case
> study:
>
> 3D Printed Heart for Printed Preoperative Planning
> Two views of a printed heart from MRI data
> http://www.web3d.org/example/3d-printed-heart
>
> Assembled and aligned together, with working tools + repeatable
> workflows + validation of correctness, the X3D family of
> technologies holds tremendous promise to broadly improve medical
> understanding and communication.
>
> All of this technical scrutiny is super valuable. Having a
> constructive community is so valuable - we avoid blunders and
> steadily build shared understanding.
>
> Onward we go, step by step! Looking forward to continuing progress
> together.
>
>
> On 10/21/2016 5:06 PM, Joe D Williams wrote:
>>> It would be fantastic if e.g. Blender armature animation was
>>> exported
>>> to X3D. It is already possible, as H-Anim supports the necessary
>>> features --- what is miss is the actual code on the side of
>>> Blender
>>> (Python) exporter to X3D.
>>
>> Good idea, perhaps if the Blender animation data exists so it can
>> be made to work in interpolators.
>> Sometimes the export of animation intended for rendering to film or
>> video is just a list of completely rendered frames rather than an
>> actual realtime animation style.
>>
>> If the data exists to export keyframe keys and keyvalues, then the
>> rotations and translations should be easy to get. In an 'old style'
>> armature they were not interested in joint rotation but depended
>> upon bone orientation. That is OK because the purpose was to pose
>> the artatmure for the next frame, not to worry about interpolation
>> since they knew the target frame intervals. That is OK, bone
>> orientation and joint rotation is the same.
>>
>> Another detail is that the joint animation data may be in unit
>> quaternions, which is actually most likely since it is the
>> preferred form in collada and glTF. Or, the data may use
>> euler-type angles (x-y-z) that need to be converted to x3d
>> axis-angle which can be straightforward.
>>
>> That is what Part 2 of new HAnim is about, how to import mocap and
>> other types of animation data. First you consider the capture
>> skeleton, then you model it to a model of an HAnim 'standard'
>> playback skeleton, convert the keyvalues as required, create the
>> positon and orientation interpolators, then run the thing.
>> Everyone's comments on this Part 2 is also appreciated.
>>
>> I don't think we want to also cover the idea of no interps, just
>> itty through the mocap keyvalues for video or film fixed frame
>> interval rendering and capture. X3D's target is realtime or anytime
>> and everytime. Of course you also make video or film using X3D.
>> Same for 'general' coverage of this anmation technology. Of course
>> you can do anything you want. You don't need study HAnim very long
>> until you learn that yes, you can define your own joint hierarchy,
>> use any names you wish, and attach any kind of geometry and sensors
>> you wish. If you want to do different shaped skin, then fine.
>> Finally, if you understand the skelton setup, you can just fly them
>> joints around to achieve most any animations possible with your
>> model. You can easily adjust animations with a keyboard, a text
>> editor, and an X3D player.
>>
>> Whatever you do, there are the same rules. Similar skeletons with
>> similar initial pose can exchange skeletal animations. That is the
>> most important point of this entire effort. Exchange skins when
>> skeleton joint hierarchy, skin vertex count, order of appearance in
>> the user code, and feature point relationships are the same. Sure
>> we could tell that story in a series of tutorials but this is a
>> spec. Maybe not this example, but the spec does not always need to
>> spell out the history or details that would be obvious to an expert
>> in the field, just the bare implementation requirements.
>>
>> Again, capabilities in this spec can describe any skeleton but I
>> think we want to target something concrete. Something that can have
>> a set of reference inputs and a set of reference outputs. Finally,
>> we want a 'standard' set of example animations that work with each
>> of the 'standard' LOA definitions.
>>
>> For this spec effort, the most important thing is that Implementors
>> get it right. If the implementation can deliver a 'standard'
>> humanoid that uses 'standard' animations, then we have something.
>> If the implemetation gets it right, then the users can get most
>> anything out of it they want. So that is why the HAnim spec targets
>> the 'standard' animatable humanoid.
>>
>> When we discuss general X3D animation facilities, of which there
>> are many, then that is the job of a set of tutorials. Please recall
>> that the spec is addressing Implementors, and technicallly-oriented
>> users, not the general user. Usually the spec will fail when it
>> wanders into general tutorials aimed at general users.
>>
>> Still, the idea of bringing something like the HAnim DIsplacer up
>> into the same bag of tools as other styles and types of
>> interpolators would be a fine idea. I think that might be what
>> Leonard was mentioning when he said there are other more basic
>> tools than joint-actuated mesh deformation. It is easy to recognize
>> the Displacer as a basic mesh animation tool that would be
>> encountered in early animation lessons.
>>
>> Thanks and Best,
>> Joe
>>
>>
>> ----- Original Message ----- From: "Michalis Kamburelis"
>> <michalis.kambi at gmail.com>
>> To: "Leonard Daly" <Leonard.Daly at realism.com>
>> Cc: "Joe D Williams" <joedwil at earthlink.net>; "X3D Public"
>> <x3d-public at web3d.org>
>> Sent: Thursday, October 20, 2016 10:34 PM
>> Subject: Re: [x3d-public] Purpose of X3Dng -- Animation
>>
>>
>>> 2016-10-21 6:23 GMT+02:00 Leonard Daly <Leonard.Daly at realism.com>:
>>>> In all your writings you appear to be making the assumption that
>>>> joint-based
>>>> animation with deformable skin is H-Anim. That is not true.
>>>
>>> Hi,
>>>
>>> From my point of view, I see H-Anim as "the way to do animation
>>> using
>>> skeletons, bones and (optional) skins in X3D". I can easily do
>>> skeletal animation of anything (humans, pipes, animals) with
>>> H-Anim. I
>>> actually implemented it in view3dscene, and really there's nothing
>>> limiting this system to "humanoids". You just transform the bones,
>>> and
>>> optionally deform a mesh following the per-vertex weights.
>>>
>>> Maybe we could solve the issues raised here by simply changing the
>>> wording (and some node names), to de-emphasize the "humanoid" part
>>> in
>>> the H-Anim specifications. (The X3D component
>>> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/hanim.html
>>> and the H-Anim spec on
>>> http://h-anim.org/Specifications/H-Anim200x/ISO_IEC_FCD_19774/ ).
>>>
>>> Such change would more accurately reflect H-Anim's capabilities
>>> (in my view).
>>>
>>> How about we would simply rename H-Anim component in X3D to
>>> "Skeletal
>>> Animation"? Some additional renames would be nice, like removing
>>> the
>>> "HAnim*" prefix from nodes, and the main "HAnimHumanoid" node
>>> could be
>>> something simpler like just a "Skeleton" (with the primary field
>>> being
>>> "skeleton").
>>>
>>> The fact that the H-Anim standard defines also a standard
>>> "Structure
>>> of a humanoid" is just "an extra" for me. I mean, it is valuable!,
>>> but
>>> it can also be simply ignored if you don't model a humanoid (or
>>> don't
>>> care about standardizing your names, to transfer the animations
>>> between other humanoids).
>>>
>>> Also, adding such "Skeletal Animation" component to the
>>> "Immersive"
>>> (or even earlier) profile would be a nice touch. It is a major
>>> animation method. Putting it inside a component other than "Full"
>>> is a
>>> way of encouraging implementations of it. Especially since it
>>> seems we
>>> do have a lot of implementations of it.
>>>
>>> It would be fantastic if e.g. Blender armature animation was
>>> exported
>>> to X3D. It is already possible, as H-Anim supports the necessary
>>> features --- what is miss is the actual code on the side of
>>> Blender
>>> (Python) exporter to X3D.
>>>
>>> I hope that this opinion helps:)
>>>
>>> Best regards,
>>> Michalis
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> 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
> http://faculty.nps.edu/brutzman
More information about the x3d-public
mailing list