[x3d-public] glTF - HAnim conversion

Andreas Plesch andreasplesch at gmail.com
Mon Dec 10 19:21:16 PST 2018


Editing the wiki page, I realized that I had left some non-field xml
attributes such as 'rotquat' and 'matrix' for documentation purposes in the
x3d xml. Perhaps this is what tripped up some. browsers. These attributes
can just be removed.

Andreas

---on the phone---

On Mon, Dec 10, 2018, 12:10 PM Joseph D Williams <joedwil at earthlink.net
wrote:

>
> Ø X3D xml
>
> Some nice work and analysis and glad to see some success and
> understanding, however please label your “X3D xml” example as experimental
> or proposed, because the code is not current x3d hanim and will not work in
> any that I have found.
>
> I will try and get this running from the data you have given.
>
> I think, as you add more joints to produce a realistic skeleton and skin,
> you can see the need to add some non-hanim nodes in basic x3d to produce
> simple joint-driven animations like you are showing. It should not be
> necessary to create the humanoid container in order to use freestyle joint
> structures, add some skin, and have a nice smooth animation of something.
> And, of course, Displacer also.
>
>
>
>    - One of the bigger differences is that glTF associates a joint or
>
> multiple joints to each vertex of a mesh while HAnim associates
>
> vertices to joints. If there are many vertices (here 96) it becomes
>
> hard to invert that mapping manually but it is actually pretty
>
> straightforward to do with a few lines of code which are outlined at
>
> the end of the page.
>
>
>
>    - glTF associates a joint or
>
> multiple joints to each vertex of a mesh
>
>
>
> yes, gltf apparently associates ‘all’ or always at least 16(?) joints (and
> weights) with each vertex. That means there is feature called a vertex that
> has a list of joints and weights associated with it. There is one of these
> for each vertex, all listing all joints and weights.
>
>
>
> >while HAnim associates vertices to joints.
>
>
>
> Yes, the each vertex and weight is associated with one or more joints.
> That means there is a feature called a joint that contains a list of
> vertices and weights. There is one of these for each joint, each listing
> only the associated vertices and weights.
>
>
>
> Check the case where you have 96  joints and 2000 vertices.
>
> The three arts are joint(s) vertices, and weights. Compact (as possible),
> complete user code.
>
>
>
>    - If there are many vertices (here 96) it becomes
>
> hard to invert that mapping manually but it is actually pretty
>
> straightforward to do with a few lines of code which are outlined at
>
> the end of the page.
>
>
>
> Check the case where you have 96  joints and 2000 vertices.
>
> One very important part is to know that every vertex is assigned to at
> least one joint
>
> So, at least you want to see it both ways. The three arts are joint(s)
> vertices, and weights.
>
> Objective is compact (as possible), complete user code.
>
>
>
> Please have a look at the attached.
>
>
>
> All Best,
>
> Joe
>
>
>
>
>
>
>
> *From: *Andreas Plesch <andreasplesch at gmail.com>
> *Sent: *Sunday, December 9, 2018 2:24 PM
> *To: *Joe D Williams <joedwil at earthlink.net>
> *Cc: *X3D Graphics public mailing list <x3d-public at web3d.org>; Michalis
> Kamburelis <michalis.kambi at gmail.com>; Humanoid Animation (H-Anim)
> Working Group <h-anim at web3d.org>
> *Subject: *Re: [x3d-public] glTF - HAnim conversion
>
>
>
> In order to learn more about glTF skeletal animation versus HAnim, I
>
> went through a slightly more realistic example conversion, manually.
>
>
>
> https://github.com/andreasplesch/x3dom/wiki/RiggedSimple-glTF-conversion
>
>
>
> documents this process and has both the initial glTF data and the
>
> resulting X3D HAnim scene:
>
> http://andreasplesch.github.io/Library/Models/HAnim/glTF/RiggedSimple.html
>
>
>
> While the example is still very simple, the source model was
>
> originally modelled in Blender, then exported to Collada, then
>
> converted to glTF and then slightly cleaned up in glTF.
>
>
>
> This is a more typical work flow. It turns out that overall it is
>
> quite possible to convert to HAnim.
>
>
>
> The wiki page has all binary data shown as text which is then used in
>
> the X3D xml. VSCode has a glTF plugin which conveniently shows the
>
> binary accessor data.
>
>
>
> One of the bigger differences is that glTF associates a joint or
>
> multiple joints to each vertex of a mesh while HAnim associates
>
> vertices to joints. If there are many vertices (here 96) it becomes
>
> hard to invert that mapping manually but it is actually pretty
>
> straightforward to do with a few lines of code which are outlined at
>
> the end of the page.
>
>
>
> I think x3dom currently does not deal with normals during HAnim
>
> deformation, eg. they are not updated. I may look into this next since
>
> it could be a reachable target.
>
>
>
> -Andreas
>
>
>
> On Mon, Dec 3, 2018 at 11:09 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
> >
>
> > Hi Joe,
>
> >
>
> > thanks for your insights. I will look into using the center field and
> have these immediate reflections.
>
> >
>
> > The exercise on the wiki page is about how to go about translating a
> gltf skeletal animation into HAnim, in the most direct way. The glTF
> example is synthetic and used to test glTF renderers against each other.
>
> >
>
> > glTF does not have a center field for transforms, only TRS. For
> centering rotations, it is necessary to use stacked transforms.
>
> >
>
> > So for import purposes, I think, it may be necessary to use the
> translation field of Joint, rather than center, if the glTF uses the
> translation key as well. This may be rare.
>
> >
>
> >  A more realistic but still simple glTF example would be the next step.
>
> >
>
> > best,
>
> >
>
> > Andreas
>
> >
>
> > ---on the phone---
>
> >
>
> >
>
> > On Mon, Dec 3, 2018, 5:03 PM Joseph D Williams <joedwil at earthlink.net
> wrote:
>
> >>
>
> >> Hi Andreas and All,
>
> >>
>
> >>
>
> >>
>
> >> Please check this out.
>
> >>
>
> >>
>
> >>
>
> >> https://github.com/andreasplesch/x3dom/wiki/HAnim-and-glTF-skins
>
> >>
>
> >>
>
> >>
>
> >> the example program,
>
> >>
>
> >> This is actually a common learning leap, but once you try it you will
> see how it works.
>
> >>
>
> >>
>
> >>
>
> >> You show a skeleton Joint as:
>
> >>
>
> >>
>
> >>
>
> >>       <HAnimJoint DEF='node_2' name='secondglTFjoint' skinCoordIndex=''
> skinCoordWeight=''
>
> >>
>
> >>        translation='0 0 0.2' rotation='-1 0 0 0.5235'>
>
> >>
>
> >>
>
> >>
>
> >> The Joint is not positioned by its translation, but by specifying its
> center, thus its center of rotation. Thus
>
> >>
>
> >>
>
> >>
>
> >>       <HAnimJoint DEF='node_2' name='secondglTFjoint' skinCoordIndex=''
> skinCoordWeight=''
>
> >>
>
> >>        center='0 0 0.2' rotation='0 0 1 0'>
>
> >>
>
> >>
>
> >>
>
> >> There may be tools that seem to use the translation field, but in the
> end, in x3d hhanim and all, you want to deal with a joint center rather
> than its translation. If done right, it all takes care of itself thanks to
> the basic features of vrml/x3d.
>
> >>
>
> >>
>
> >>
>
> >> Also, why do you want to initialize the joint with some rotation? Start
> the thing with 0 0 1 0 default and program it from there. What will happen
> with a ‘standard’ animation sets you model to default pose? What will
> happen when your segment geometry is set to all joints 0 0 1 0?
>
> >>
>
> >>
>
> >>
>
> >> Except to demo skeleton malfunction or special (non-rotary) operation
> if a Joint, the user never needs send translation to Joint except for the
> ROOT. (script may move a joint center) All translation(s) of joint(s) are
> the result of the parent hierarchy. I would say to actually check this out
> both ways and I hope you are more comfortable with Joint center.
>
> >>
>
> >>
>
> >>
>
> >> And, please remember, that if J1 is a parent of J2 and you have
> geometry between joints J1 and J2, then that geometry must be the child of
> J1 or it won’t work right. You might also try that choice.
>
> >>
>
> >>
>
> >>
>
> >> Thanks for Your work on this and hope for demoable results.
>
> >>
>
> >> Joe
>
> >>
>
> >>
>
> >>
>
> >> From: Joseph D Williams
>
> >> Sent: Monday, December 3, 2018 9:07 AM
>
> >> To: X3D Graphics public mailing list; Humanoid Animation (H-Anim)
> Working Group
>
> >> Subject: Re: [x3d-public] HAnim and glTF skins
>
> >>
>
> >>
>
> >>
>
> >> For now, we have seen ogl, vrml/x3d, collada, webgl, and now gltf, and
> all with the goal of providing reliable creation and transport of data.
> While all these provide certain features, none is directly aimed at
> simulation quality realtime interactive scenegraph interactions for the
> WWW, that I have seen. .
>
> >>
>
> >>
>
> >>
>
> >> Please, I want to get this right, did I miss any? And, I meant
>
> >>
>
> >>
>
> >>
>
> >> “… that I have seen, except  vrml/x3d.”
>
> >>
>
> >>
>
> >>
>
> >> Thanks,
>
> >>
>
> >> Joe
>
> >>
>
> >>
>
> >>
>
> >>
>
> >>
>
> >> From: Joseph D Williams
>
> >> Sent: Sunday, December 2, 2018 10:25 PM
>
> >> To: Andreas Plesch; X3D Graphics public mailing list; Humanoid
> Animation (H-Anim) Working Group
>
> >> Subject: Re: [x3d-public] HAnim and glTF skins
>
> >>
>
> >>
>
> >>
>
> >>
>
> >>
>
> >> However, the tradeoff is that this makes implementations harder or
> perhaps completely unfeasible in some cases.
>
> >>
>
> >>
>
> >>
>
> >> No author or specwriter cares about how complicated the implementation
> might be, they just want to stuff to work.
>
> >>
>
> >> I try not to forget, but please to acknowledge while all this stuff may
> look new, the only thing I have ever seen that x3d contributes as new is
> the fact that humans can read the documentation then actually run the
> stuff. For instance, look at that topic of gltf transport of a type of
> vertex animation. This is the sort of stuff you may use to transport a pose
> or a series of poses, most clearly aimed at transport of video frames. It
> is not documentation of the process used to create the data, but just a set
> if frames for part of a scene. That is the typical export of tools aimed at
> video, they just send you so many frames and it is up to you about how this
> data gets used, and that is it.
>
> >>
>
> >>
>
> >>
>
> >> Now, if you want to aim at realtime, then you probably don’t need all
> those frames with all that time resolution everywhere because you can use
> interpolators and other tools to author the intervals and be much more
> efficient. But hey, unless you know the majik words, then they won’t show
> you the timers and interpolators used under the covers, all they want to
> show you is the fixed fps stuff you need to capture a video.
>
> >>
>
> >>
>
> >>
>
> >> If any authoring system is not exporting to x3d, tell ‘em ok, I can do
> it a style sheet if you just show me the simple common data sets I just
> authored. I’ll put in x3d containers and add some x3d boilerplate? Sure,
> export of a feature not included in x3d is obviously impossible, but what
> is feature documented by data not compatible with x3d? (spoiler alert: the
> list is long for some fancy stuff)? Just like the old days before all the
> majors of the time agreed to support export of vrml for the stuff that vrml
> did, which is mainly the basic stuff that x3d does, including the
> humanoidanimation, but now a new group of folks that may have forgotten
> that the same or compatible data is under the covers regardless of the
> interface exposed to the author or the target runtime and may have
> forgotten or are ignoring the value pf easy transport for consumer and
> hobby use.
>
> >>
>
> >>
>
> >>
>
> >> It is the objective of x3d to directly expose the pertinent data in
> suitable form to have a realtime authortime and a realtime runtime. If you
> are authoring in a system that won’t let you export geometries, various
> textures, maps, lights, basic time- and event- driven animations, and
> cameras to vrml or x3d, then you may be dealing with a company evolved over
> the last 5 or so years. These fairly new tools are based on more or less
> the ogl and vrml and the authoring capabilities of the late 90s and 00s
> then big 4 or 5 technical and entertainment digital animation toolmakers of
> the world. See, at the time, in the mid 90’s and early 00s, vrml and then
> web3d was actually able to bring together a dedicated bunch that said to
> the big toolmakers, “not only do us bunch of enthusiastic users want a
> common data transport for vrml scenegraph, but so do you!” or something
> like that and out of that, with the deep technical knowledge and
> inspiration of that group, we got the basic vrml stuff, first built from
> the basic ogl stuff. So it may be likely that if somebody tells you that
> you can’t get the data that you just authored out of their box in x3d
> compatible form, well, it might range all the way from might have even been
> in on the birth of vrml or not yet born then. For now, we have seen ogl,
> vrml/x3d, collada, webgl, and now gltf, and all with the goal of providing
> reliable creation and transport of data. While all these provide certain
> features, none is directly aimed at simulation quality realtime interactive
> interactions for the WWW, that I have seen. .
>
> >>
>
> >>
>
> >>
>
> >> Heck this is just me from the peanut gallery but if “perhaps completely
> unfeasible in some cases” then your engine has wrong features. Be sure you
> start with something that is aimed at readable user code and realtime
> event-driven runtime, that it knows what a schema snd x3d object model is,
> and capable of doing skins and physics and medical graphics for skeletons.
> As far as “unfeasible” x3d (my opinion) is first looking for features and
> structures proven to be widely “feasible” and in fact industry standard and
> actually demonstrated in a couple of open applications. However, I see your
> point, before it was shown to be possible, it was infeasible to expect even
> a 3d spinning tennis shoe but then something happened and computers got a
> lot better at doing some complicated 3d.
>
> >>
>
> >>
>
> >>
>
> >> Thanks,
>
> >>
>
> >> Joe
>
>
>
>
>
>
>
> --
>
> Andreas Plesch
>
> Waltham, MA 02453
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20181210/2feef177/attachment-0001.html>


More information about the x3d-public mailing list