<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">I want to point out that my posting on
      X3Dng Animation [<a class="moz-txt-link-freetext" href="http://realism.com/blog/purpose-x3d-animation">http://realism.com/blog/purpose-x3d-animation</a>]
      (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. <br>
      <br>
      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
<a class="moz-txt-link-freetext" href="http://www.cs.cmu.edu/~yaser/Lecture-9-Skinning%20and%20Body%20Representations.pdf">http://www.cs.cmu.edu/~yaser/Lecture-9-Skinning%20and%20Body%20Representations.pdf</a>,
      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.<br>
      <br>
      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?<br>
      <br>
      <br>
      Leonard Daly<br>
      <br>
      <br>
      <br>
    </div>
    <blockquote cite="mid:485cf04d-0f59-63a5-7a4b-833c5242c821@nps.edu"
      type="cite">[cc: h-anim]
      <br>
      <br>
      Summary: a lot of capability is steadily adding up with H-Anim,
      and beginning to overlap with Medical and CAD.
      <br>
      <br>
      Great observations below, Joe and Michalis!  8)  Thank you.  Here
      are some reactions.
      <br>
      <br>
      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.
      <br>
      <br>
      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.)
      <br>
      <br>
      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.
      <br>
      <br>
    <a class="moz-txt-link-freetext" href="https://svn.code.sf.net/p/x3d/code/www.web3d.org/x3d/tools/X3dEdit3.3/X3D/src/org/web3d/x3d/hanim/bvh/">https://svn.code.sf.net/p/x3d/code/www.web3d.org/x3d/tools/X3dEdit3.3/X3D/src/org/web3d/x3d/hanim/bvh/</a>
      <br>
          BvhSkeletonParameters.java
      <br>
          Hierarchy.java
      <br>
          Joint.java
      <br>
          Motion.java
      <br>
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      Current H-Anim example models:
      <br>
      <br>
    <a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/examples/Basic/HumanoidAnimation">http://www.web3d.org/x3d/content/examples/Basic/HumanoidAnimation</a>
      <br>
      <br>
      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.
      <br>
      <br>
    <a class="moz-txt-link-freetext" href="http://x3dgraphics.com/slidesets/X3dForAdvancedModeling/HumanoidAnimation.pdf">http://x3dgraphics.com/slidesets/X3dForAdvancedModeling/HumanoidAnimation.pdf</a>
      <br>
      <br>
      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:
      <br>
      <br>
          web3D.org > PARTICIPATE > Projects Wish List
      <br>
          <a class="moz-txt-link-freetext" href="http://www.web3d.org/projects/wish-list">http://www.web3d.org/projects/wish-list</a>
      <br>
      <br>
      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:
      <br>
      <br>
          X3D Example Archives: Basic, Humanoid Animation, HAnim
      Prototypes
      <br>
    <a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/examples/Basic/HumanoidAnimation/HAnimPrototypesIndex.html">http://www.web3d.org/x3d/content/examples/Basic/HumanoidAnimation/HAnimPrototypesIndex.html</a>
      <br>
      <br>
          Cobweb Supported Components
      <br>
          <a class="moz-txt-link-freetext" href="http://titania.create3000.de/cobweb/#c426">http://titania.create3000.de/cobweb/#c426</a>
      <br>
      <br>
      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:
      <br>
      <br>
          3D Printed Heart for Printed Preoperative Planning
      <br>
          Two views of a printed heart from MRI data
      <br>
          <a class="moz-txt-link-freetext" href="http://www.web3d.org/example/3d-printed-heart">http://www.web3d.org/example/3d-printed-heart</a>
      <br>
      <br>
      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.
      <br>
      <br>
      All of this technical scrutiny is super valuable.  Having a
      constructive community is so valuable - we avoid blunders and
      steadily build shared understanding.
      <br>
      <br>
      Onward we go, step by step! Looking forward to continuing progress
      together.
      <br>
      <br>
      <br>
      On 10/21/2016 5:06 PM, Joe D Williams wrote:
      <br>
      <blockquote type="cite">
        <blockquote type="cite">It would be fantastic if e.g. Blender
          armature animation was exported
          <br>
          to X3D. It is already possible, as H-Anim supports the
          necessary
          <br>
          features --- what is miss is the actual code on the side of
          Blender
          <br>
          (Python) exporter to X3D.
          <br>
        </blockquote>
        <br>
        Good idea, perhaps if the Blender animation data exists so it
        can be made to work in interpolators.
        <br>
        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.
        <br>
        <br>
        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.
        <br>
        <br>
        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.
        <br>
        <br>
        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.
        <br>
        <br>
        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.
        <br>
        <br>
        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.
        <br>
        <br>
        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.
        <br>
        <br>
        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.
        <br>
        <br>
        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.
        <br>
        <br>
        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.
        <br>
        <br>
        Thanks and Best,
        <br>
        Joe
        <br>
        <br>
        <br>
        ----- Original Message ----- From: "Michalis Kamburelis"
        <a class="moz-txt-link-rfc2396E" href="mailto:michalis.kambi@gmail.com"><michalis.kambi@gmail.com></a>
        <br>
        To: "Leonard Daly" <a class="moz-txt-link-rfc2396E" href="mailto:Leonard.Daly@realism.com"><Leonard.Daly@realism.com></a>
        <br>
        Cc: "Joe D Williams" <a class="moz-txt-link-rfc2396E" href="mailto:joedwil@earthlink.net"><joedwil@earthlink.net></a>; "X3D Public"
        <a class="moz-txt-link-rfc2396E" href="mailto:x3d-public@web3d.org"><x3d-public@web3d.org></a>
        <br>
        Sent: Thursday, October 20, 2016 10:34 PM
        <br>
        Subject: Re: [x3d-public] Purpose of X3Dng -- Animation
        <br>
        <br>
        <br>
        <blockquote type="cite">2016-10-21 6:23 GMT+02:00 Leonard Daly
          <a class="moz-txt-link-rfc2396E" href="mailto:Leonard.Daly@realism.com"><Leonard.Daly@realism.com></a>:
          <br>
          <blockquote type="cite">In all your writings you appear to be
            making the assumption that joint-based
            <br>
            animation with deformable skin is H-Anim. That is not true.
            <br>
          </blockquote>
          <br>
          Hi,
          <br>
          <br>
          From my point of view, I see H-Anim as "the way to do
          animation using
          <br>
          skeletons, bones and (optional) skins in X3D". I can easily do
          <br>
          skeletal animation of anything (humans, pipes, animals) with
          H-Anim. I
          <br>
          actually implemented it in view3dscene, and really there's
          nothing
          <br>
          limiting this system to "humanoids". You just transform the
          bones, and
          <br>
          optionally deform a mesh following the per-vertex weights.
          <br>
          <br>
          Maybe we could solve the issues raised here by simply changing
          the
          <br>
          wording (and some node names), to de-emphasize the "humanoid"
          part in
          <br>
          the H-Anim specifications. (The X3D component
          <br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/hanim.html">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/hanim.html</a>
          <br>
          and the H-Anim spec on
          <br>
          <a class="moz-txt-link-freetext" href="http://h-anim.org/Specifications/H-Anim200x/ISO_IEC_FCD_19774/">http://h-anim.org/Specifications/H-Anim200x/ISO_IEC_FCD_19774/</a>
          ).
          <br>
          <br>
          Such change would more accurately reflect H-Anim's
          capabilities (in my view).
          <br>
          <br>
          How about we would simply rename H-Anim component in X3D to
          "Skeletal
          <br>
          Animation"? Some additional renames would be nice, like
          removing the
          <br>
          "HAnim*" prefix from nodes, and the main "HAnimHumanoid" node
          could be
          <br>
          something simpler like just a "Skeleton" (with the primary
          field being
          <br>
          "skeleton").
          <br>
          <br>
          The fact that the H-Anim standard defines also a standard
          "Structure
          <br>
          of a humanoid" is just "an extra" for me. I mean, it is
          valuable!, but
          <br>
          it can also be simply ignored if you don't model a humanoid
          (or don't
          <br>
          care about standardizing your names, to transfer the
          animations
          <br>
          between other humanoids).
          <br>
          <br>
          Also, adding such "Skeletal Animation" component to the
          "Immersive"
          <br>
          (or even earlier) profile would be a nice touch. It is a major
          <br>
          animation method. Putting it inside a component other than
          "Full" is a
          <br>
          way of encouraging implementations of it. Especially since it
          seems we
          <br>
          do have a lot of implementations of it.
          <br>
          <br>
          It would be fantastic if e.g. Blender armature animation was
          exported
          <br>
          to X3D. It is already possible, as H-Anim supports the
          necessary
          <br>
          features --- what is miss is the actual code on the side of
          Blender
          <br>
          (Python) exporter to X3D.
          <br>
          <br>
          I hope that this opinion helps:)
          <br>
          <br>
          Best regards,
          <br>
          Michalis
          <br>
        </blockquote>
        <br>
        _______________________________________________
        <br>
        x3d-public mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
        <br>
        <a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
        <br>
      </blockquote>
      <br>
      <br>
      all the best, Don
      <br>
    </blockquote>
    <br>
    <p><br>
    </p>
    <div class="moz-signature">-- <br>
      <font class="tahoma,arial,helvetica san serif" color="#333366">
        <font size="+1"><b>Leonard Daly</b></font><br>
        3D Systems & Cloud Consultant<br>
        LA ACM SIGGRAPH Chair<br>
        President, Daly Realism - <i>Creating the Future</i>
      </font></div>
  </body>
</html>