[x3d-public] glTF - HAnim conversion

Andreas Plesch andreasplesch at gmail.com
Thu Dec 13 19:38:02 PST 2018


see below.
On Thu, Dec 13, 2018 at 3:40 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> Thanks for the xml conversion. I had tried the instantreality
> converter but it complained and did not convert. Perhaps the copy and
> paste went wrong.
>
> Anyways, here is how x3dom plays the attachment:
>
> http://andreasplesch.github.io/Library/Models/HAnim/x3d/InlineViewer.html
>
> Let me check how it looks in InstantPlayer or BSContact.

I tried the scene in InstantPlayer, BSContact and FreeWRL 4.0. They
all played and rendered the scene the same way as x3dom, so looking
good here.

I also tried the RiggedSimple adaption in these players. BSContact did
not like commas in the translation and rotation fields but after
removing them, all players also played this stranger, more
experimental HAnim as expected and in the same way. The wiki page
https://github.com/andreasplesch/x3dom/wiki/RiggedSimple-glTF-conversion
and https://github.com/andreasplesch/Library/blob/gh-pages/Models/HAnim/glTF/RiggedSimple.x3d
have now the BSContact compatible x3d.

This makes me more confident that the way I have been approaching the
glTF to HAnim conversion is not entirely off. I still want to manually
convert more example before coding something.

Andreas

>
> -Andreas
>
> On Wed, Dec 12, 2018 at 10:05 PM Joseph D Williams
> <joedwil at earthlink.net> wrote:
> >
> >
> >
> > http://doc.instantreality.org/tools/x3d_encoding_converter/
> >
> >
> >
> > Hi Andreas,
> >
> > Yes, please look at the web3d.org resources for other x3d utilities. I tried the instant converter and seemed to work, attached.
> >
> >  I usually always work with x3dv because most examples have been in work since vrml hanim.
> >
> > Utf8 open in notepad with word wrap off.
> >
> > Thanks and Best,
> >
> > Joe
> >
> > http://www.web3d.org/x3d/content/examples/X3dResources.html
> >
> >
> >
> >
> >
> > From: Andreas Plesch
> > Sent: Tuesday, December 11, 2018 1:45 PM
> > To: Joe D Williams
> > Cc: X3D Graphics public mailing list; Michalis Kamburelis; Humanoid Animation (H-Anim) Working Group
> > Subject: Re: [x3d-public] glTF - HAnim conversion
> >
> >
> >
> > Do you have a way to translate the classic format to xml ? -Andreas
> >
> > On Tue, Dec 11, 2018 at 9:05 AM Joseph D Williams <joedwil at earthlink.net> wrote:
> >
> > >
> >
> > > Thanks Andreas, I will delete those continue to see the scene, but still not hanim user code..
> >
> > >
> >
> > > Sorry to be so nit-picky about the syntax and style.
> >
> > >
> >
> > > Did you get a chance to try the attachment I sent?
> >
> > >
> >
> > > Thanks and Best,
> >
> > >
> >
> > > Joe
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > From: Andreas Plesch
> >
> > > Sent: Monday, December 10, 2018 7:21 PM
> >
> > > To: Joe D Williams
> >
> > > Cc: X3D Graphics public mailing list; Michalis Kamburelis; Humanoid Animation (H-Anim) Working Group
> >
> > > Subject: Re: [x3d-public] glTF - HAnim conversion
> >
> > >
> >
> > >
> >
> > >
> >
> > > 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
> >
> > > Sent: Sunday, December 9, 2018 2:24 PM
> >
> > > To: Joe D Williams
> >
> > > Cc: X3D Graphics public mailing list; Michalis Kamburelis; Humanoid Animation (H-Anim) Working Group
> >
> > > 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
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > Andreas Plesch
> >
> > Waltham, MA 02453
> >
> >
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453



-- 
Andreas Plesch
Waltham, MA 02453



More information about the x3d-public mailing list