[x3d-public] both X3DOM and X_ITE.

Mon May 28 18:53:32 PDT 2018

< Or on the web look for other,widely available technologies. 

Well, for character animation by skeleton or morph I don’t think it is the technology but the abstractions of whatever authoring system you use. Names and approaches are different but the structures and the data are the same. Not for me to say there might be some new revolutionary approach to character animation, and there are, just that as far as x3d is concerned we have the basics covered. X3D specifies a set of interfaces to construct the character and then animate it. If someone is doing anything different, then I would like to see it. Maybe convince the IP owners to port it to X3D.

Please see more below.

From: Andreas Plesch
Sent: Monday, May 28, 2018 3:10 PM
To: Joseph D Williams
Cc: John Carlson; x3dom mlist; X3D Graphics public mailing list
Subject: Re: both X3DOM and X_ITE.

On Mon, May 28, 2018 at 4:24 PM, Joseph D Williams
<joedwil at earthlink.net> wrote:
>
> From: Andreas Plesch
>
>
>> There just does not seem a lot of demand or requests by users or
>> customers. Of course, this may be a chicken and egg problem.
>
> And, that if you hae soething that works, like contact and instant, maybe
> you don’t need to complain.
>
>>> Or on the web look for other,widely available technologies.
>
>> Contributions to x3dom or x_ite are always welcome, in any case.
>
> Great a contribution to either is a contribution to X3D.
>
>>> Well said.
>
>> For x3dom, my interest would be probably the glTF angle. glTF has
>> character animation. Here is an example:
>>
>> https://www.donmccurdy.com/2017/11/06/creating-animated-gltf-characters-with-mixamo-and-blender/>
>
> Great, I will look. The basic x3d hanim skeleton, bindings, animations, and
> geometries can be stored in gltf. I hope I can look back in the hanim
> archives to see a comparison I did. No doubt gltf can transport the good
> stuff with the only problem that gltf uses unit quats instead of axis-angle.
>
>>> x3dom uses quats internally anyways, I think rotation field values are
immediately converted at parsing.

Most of them do that, just that unit quats were not so established when hanim or the rest of x3d was first specified

>> The best explanation, apart from studying glTF loaders, is apparently
>> in this figure, sorry about that:
>>
>> https://raw.githubusercontent.com/KhronosGroup/glTF/master/specification/2.0/figures/gltfOverview-2.0.0a.png
>
> OK, I will look for more recent info, but I don’t think anything in this has
> changed. Structure and data – names may be different but the data and its
> application is the same. Now I know there may be some new tech but for the
> basics stuf, not much has changed in the last 20 years since hanim was
> specified.

>>> The glTF spec. itself, I think, refers to the figure to explain meaning.

>> translation of a simple glTF character to an HAnim humanoid would be a
>> good first step.
>
> A better first step would be to transcode an HAnim humanoid into gltf and
> back again. From what I saw it would work. After all, it is all the same
> structure and same data. I was going to work on the Boxman and the JoeKick
> models in the x3d hanim example archives.

>>> Well, these are two steps. The simplest rigged skining glTF example seems to be:

>>> https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/RiggedSimple

Fine, I will look at this soon. When I last looked I could not find an example. 

>
>> A functional, minimal subset of HAnim of nodes and/or a Proto-based
>> implementation of the nodes would also help implementers.
>
> Of course we have the proto-based nodes for HAnim where the geometries are
> children of Segments (bones) and we animate the skeleton. A prototype for
> seamless skin animation is Boxman in x3d hanim archives - it needs a fancy
> script to move skin. Since there are no other features of x3d that
> approximate the way skin is animated, there are no scriptless prototypes.

>>> Ok: Here is the link:
>>> http://www.web3d.org/x3d/content/examples/Basic/HumanoidAnimation/HAnimPrototypesIndex.html

>>> But I do not see scripts ?

Good because there should not be the need – unless you also wish to implement the rotation limit checking. 

>>> Will there be an proto update for the new version of HAnim ?

Yes, at least without the skin animation. No problem, no scripts. 

>> A main challenge will be probably the requirement to have vertex
>> geometry manipulation in a shader on the GPU. This is done only for
>> displacement textures of a CommonSurfaceShader node currently in
>> x3dom.

> Yes, we need to control individual ‘skin’ vertices according to a simple
> weighting algorithm depending upon rotation of one or more joints. That has
> been a problem, yet it is so basic, that and morph shape, that we should
> have both features outside the Humanoid container.

>>> Yes, morphing seems generally useful. I think glTF may use weighted
matrices but not sure.

I think I saw that the morphing defines the max displacement from the original mesh according to some weighting function. HAnim and others should be able to apply that displacement to any displacement caused by the skeleton animation. Again I think the data is the same, just different names and maybe form, like unit quats vs axis-angle.  

> If anyone wants to learn character animation, anything you learn about x3d
> hanim will not be a waste of time. X3d hanim still documents an industry
> standard approach where inputs were taken from all major toolmakers because
> strangely, even back in the late 1990’s there was great input from users to
> the biggies that they had to allow data to be exported and transported
> between applications. Only the names were changed to prevent favoritism and
> preserve innocence – ooh, and to bring the secretive data structures and
> bindings out into the open.

>>> Ok. I will say that the HAnim prototypes which do not need scripts
should be possible, even straightforward to port to x3dom and probably
x_ite native nodes. John's protoexpander probably already could deal
with those. So the main challenge probably really is the GPU based
vertex displacing.

Yes, I think the basic hanim protos for Humanoid, Joint, Segment, and Site are straightforward. Yes, the big challenge comes from the skeleton-driven animation of the skin, and the displacer. How to move them verts according to a plan. ,

>>> Is there any use in having the Grouping/Transform type HAnim nodes only ?

The important stuff is the hierarchy. For example there is a container called skeleton that holds the joints, segments, and sites hierarchy. The joint node contains the skin bindings, if used. I don’t think I get the question. I do think it would be a good thing to get the basic joint-skin operation feature and the displacer functionality out of hanim and available witout the humanoid container. 

>>> Best, -Andreas

Thanks and Best, \
Joe

>
> On Mon, May 28, 2018 at 10:42 AM, Joseph D Williams
>
> <joedwil at earthlink.net> wrote:
>
>>> both X3DOM and X_ITE …
>
>> The discussions about both X3DOM and X_ITE are, to me, missing a very
>> important feature. Neither of these tools can do HAnim skeleton controlled
>> deformable skin. This is a very important feature, lending itself to many
>> important applications in addition to HAnim. There have been several
>> discussions about the hanim joint(s) to deformable skin bindings and as
>> far
>> as I have seen, there is no doubt that the way x3d specifies the basic,
>> most
>> simple, and most transportable technique to achieve the result. So, as the
>> HAnim standard takes the next step, why not move a bit toward implementing
>> this important capability in your browsers. BSContact does it, I think
>> Instant does it mostly but x3dom and x_ite don’t.
>> Thanks and Best,
>
>>
>
>> Joe
>
>>
>
>>
>
>>
>
>>
>
>
>
>
>
>
>
> --
>
> Andreas Plesch
>
> Waltham, MA 02453
>
>

-- 
Andreas Plesch
Waltham, MA 02453

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