[x3d-public] HAnim and glTF skins and skeletons

Andreas Plesch andreasplesch at gmail.com
Mon Dec 3 20:09:03 PST 2018


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 <joedwil at earthlink.net>
> *Sent: *Monday, December 3, 2018 9:07 AM
> *To: *X3D Graphics public mailing list <x3d-public at web3d.org>; Humanoid
> Animation (H-Anim) Working Group <h-anim at web3d.org>
> *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 <joedwil at earthlink.net>
> *Sent: *Sunday, December 2, 2018 10:25 PM
> *To: *Andreas Plesch <andreasplesch at gmail.com>; X3D Graphics public
> mailing list <x3d-public at web3d.org>; Humanoid Animation (H-Anim) Working
> Group <h-anim at web3d.org>
> *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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20181203/6596773e/attachment-0001.html>


More information about the x3d-public mailing list