[x3d-public] HAnim and glTF skins and skeletons

Joseph D Williams joedwil at earthlink.net
Mon Dec 3 14:03:38 PST 2018


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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20181203/fba1ea01/attachment-0001.html>


More information about the x3d-public mailing list