[x3d-public] Purpose of X3Dng -- Animation (of humanoid models)
Joe D Williams
joedwil at earthlink.net
Mon Oct 24 23:32:40 PDT 2016
> If that capability were part of the X3D specification, would it need
> to be repeated in H-Anim?
Stop! That capability is part of the X3D specifcation.
Please check the HAnim component of the current X3D standard.
What do you want to do, Leonard?
What parts of X3D HAnim component do you wish to move from X3D HAnim
to another part of the standard?
Do you want to drop some of the special fields of Joint and just call
it a Transform?
If you look at actual HAnim definitions and prototype user code you
will see that, except for skin bindings, the skeleton structures could
be built using standard nodes. The Humanoid is just a Group node,
Joint is just a Transform, Segment is just specially named child
geometry, and Site is just specially named child geometry. The HAnim
spec just puts these together in a set of special configurations that
describe a 'standard' humanoid.
The mesh deformable skin and displacer controls are a big level of
dificulty above just using segment geometry. Thus, any X3D player can
create a skeleton and segment geometry using standard nodes in
whatever hierarchy desired. Making the deformable skin work, and
making a DIsplacer work, is more dificult. Deformable skin and
Displacer can be prototyped using script and interpolator techniques
but without built-in processing power, it will be slow.
If you are interested in defining a general purpose mesh deformation
tool, look at the DIsplacer. If you get an X3D browser running and
experiment, you will see that this is the heart of the HAnim animation
system. The DIsplacer moves mesh vertices around according to a
weighted input. This is also how skin animation works - the joint
rotation provides basis for the weighting input. The DIsplacer is a
common tool that any mesh animation authoring system includes (but
maybe they call it a deformer or miscall it a morpher or maybe
something else), but the principle is the same. Some targeted vertices
are moved according to author-defined directions. Displacer is very
general and probably cjould belong in with interpolators, yet it is
confined to HAnim now.
If you don't understand what the HAnim Displacer does and how it works
and how actually it is a very general purpose tool, then you really
can't formulate questions about mesh animation, much less humanoid or
general character animation using deformable skin. .
Next, please comprehend the deformable skin by skeleton movements. You
need to associate each vertex of the skin with one or more Joint
objects. Then you assign a weight that controls how much, from 0 to 1,
that defines how much each vertex actually moves when the controlling
joints are rotated. Typical old style authoring systems may give the
idea to the casual user that the skin is controlled by bones and thus
appear to associate each vertex of the skin with a bone. That is OK,
the numbers work out to be the same.
So what part of this do you want to move out of HAnim? For skin, you
start with a mesh and create some interface between the mesh and
controller. This interface is the skeleton and the system will detect
rotation events of the controllers and use some data base to figure
out which verts are affected and how to move them. In the HAnim it was
decided that the interface was the skeleton and its Joint structures.
It was decided to contain the data base concerning vertex assignments
and weights in the Joint nodes. Would you choose to do something
different?
All Best,
Joe
---- Original Message -----
From: "Leonard Daly" <Leonard.Daly at realism.com>
To: <yottzumm at gmail.com>; <x3d-public at web3d.org>; "Human Animation
working group" <h-anim at web3d.org>
Sent: Sunday, October 23, 2016 8:43 PM
Subject: Re: [x3d-public] Purpose of X3Dng -- Animation (of humanoid
models)
> On 10/23/2016 8:30 PM, yottzumm at gmail.com wrote:
>>
>> Leonard,
>>
>> I think you wanted to say for your last sentence: “If X3Dng joint
>> animation and skin deformation was taken, perhaps wholesale, from
>> H-Anim, what would be left in H-Anim?”
>>
>> But you can probably word-craft better than I can. Have another go
>> at
>> it if you like.
>>
>
> John,
>
> Thanks for pointing this out. I am not too particular to get the
> discussion going. What you said is correct, but I did want to give
> the
> opportunity to include other material that might better fit the
> mission
> of H-Anim. I do not know what that might be, nor do I wish to
> presume
> anything about that mission. I did intend it to be an open-ended
> question, though I could have improved the wording.
>
>
> Leonard Daly
>
>
>
>
>
>> John
>>
>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>> Windows 10
>>
>> *From: *Leonard Daly <mailto:Leonard.Daly at realism.com>
>> *Sent: *Sunday, October 23, 2016 11:22 PM
>> *To: *x3d-public at web3d.org <mailto:x3d-public at web3d.org>; Human
>> Animation working group <mailto:h-anim at web3d.org>
>> *Subject: *Re: [x3d-public] Purpose of X3Dng -- Animation (of
>> humanoid
>> models)
>>
>> I want to point out that my posting on X3Dng Animation
>> [http://realism.com/blog/purpose-x3d-animation] (BTW, ng == next
>> generation) is not necessarily for characters - human, humanoid, or
>> animal. It is a means of animation that is in standard use in the
>> animation industry. It is frequently applied to characters, but
>> that
>> is not the only possible target of the animation.
>>
>> This method of animation is not "fool-proof" - there are some edge
>> cases that cause problems -- for example a rotation of pi radians
>> on a
>> joint that can twist causes the skin to "candy-wrap". See
>> http://www.cs.cmu.edu/~yaser/Lecture-9-Skinning%20and%20Body%20Representations.pdf
>> <http://www.cs.cmu.edu/%7Eyaser/Lecture-9-Skinning%20and%20Body%20Representations.pdf>,
>> pages 27-34 for a visual and technical description of the issue.
>> The
>> charts also provide a lot of the mathematical framework that Don
>> discusses below including motion capture.
>>
>> So I'll ask my question again, if X3Dng includes joint animation
>> with
>> skin deformation at a profile that is generally used (e.g.,
>> Immersive
>> or less); what should the H-Anim specification cover? I am not
>> trying
>> to imply that H-Anim should not exist, but a big chunk of the
>> document
>> does discuss joint animation with skin deformation. If that
>> capability
>> were part of the X3D specification, would it need to be repeated in
>> H-Anim? (If so, why?). If it was removed, what would be the
>> appropriate material to include in the document?
>>
>>
>> Leonard Daly
>>
>>
>> [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>
>> <mailto:michalis.kambi at gmail.com>
>> To: "Leonard Daly" <Leonard.Daly at realism.com>
>> <mailto:Leonard.Daly at realism.com>
>> Cc: "Joe D Williams" <joedwil at earthlink.net>
>> <mailto:joedwil at earthlink.net>; "X3D Public"
>> <x3d-public at web3d.org> <mailto: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>
>> <mailto: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 <mailto:x3d-public at web3d.org>
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>>
>>
>> all the best, Don
>>
>> --
>> *Leonard Daly*
>> 3D Systems & Cloud Consultant
>> LA ACM SIGGRAPH Chair
>> President, Daly Realism - /Creating the Future/
>>
>>
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> --
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - /Creating the Future/
>
--------------------------------------------------------------------------------
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
More information about the x3d-public
mailing list