[x3d-public] HAnim and glTF skins

[Andreas Plesch]

Joe, excellent points. See below.

> Date: Thu, 29 Nov 2018 11:47:34 -0800
> From: Joseph D Williams <joedwil at earthlink.net>
> To: John Carlson <yottzumm at gmail.com>, GPU Group <gpugroup at gmail.com>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] HAnim and glTF skins
>
> ? Andreas - Another feature in glTF are morph targets which are
independent of skins. They are similar to HAnim displacers but I have not
looked very closely if it is possible to define a mapping between them.
>
> The thing that maybe special in HAnim is that the displacers applied to
skin are additive to other mesh animation. I think you will find that morph
thingees will be used with other skin animation techniquess

I do think glTF allows that mesh vertices are affected by both, morph
targets and joints, at least nothing is precluding it. It does not seem
explicit about what effect is applied first, perhaps it is implicit that
morphing is first.

>
> HAnimDisplacer
>  coordIndex    [  numerical index of each parent geometry vertex
>    to be animated in the same order as they appear
>    in the user code for the target geometry ]
>  displacements  [  x,y,z in skeleton space
>    maximum displacement of each vertex  ]
>  weight        0 to 1 animation control
>    (linear interpolation)
>    0 = same location as parent mesh initial vertex
>    1 = defined maximum displacement location of parent mesh vertex
>
> Parent geometry is either the Humanoid, if the Displacer is applied to
the mesh in the skin node, or, the geometry of the Displacer node's parent
Segment. The displacements xyz data gives a relative target maximum
displacement, sort of like there is vector that points from the current
vertex position to the location of maximum displacement and the current
vertex is moved along that vector according to the weight input.

That is identical to morph targets in glTF. There, for some reason, the
weights are defined in the Node (transform) around the morphed mesh.

In addition, morph targets also define normal and tangent 'displacements',
so they do not need to be recomputed if available.

>
> Displacer nodes require detailed knowledge of the parent mesh.
Specifically, the vertex order of the parent mesh must not change between
authoring and rendering. Compared to CoordinateInterpolator, for example,
since all vertices of the mesh may not need to be animated for a sequence,
only the vertices to be moved are included. If the mesh is being animated
by another process, then those results and all displacer(s) results must be
applied to the entire mesh in the same frame.

I think, in glTF all vertices need a corresponding target. It is probably
cheaper on the GPU just to displace all than doing the work necessary to
skip some.

>
> In fact, what would be the problem, since the name of the node in X3D is
HAnimDisplacer, the name Displacer is available for x3d, Why not figure out
how to do at least a simple one for V4, or change the name. Canvas the
industry and see the various names they call these things, then pick
something different. The data and execution of the displacer is like other
things called various names that so the same thing, as it has always been.

Displacer could be a GPU friendly, simple Coordinate/NormalInterpolator.

>
> Also, if a good goal is to bring in some more simplified form of
articulation-driven mesh animation, why not define a simple
root-Joints-segments-skin hierarchy setup using some plain names for the
animation nodes and skin bindings. I mean, whatever. we might as well call
a joint a rotary, fixed center of rotation actuator. And, of course we need
joint-like things, only the most perverse (mis)understanding of the fact
that bone orientation the same as joint rotation wants to do away with
joints.
>
> I can see why a gltf vertex contains a list of actuators and weights
while hanim uses the actuator to hold the list of vertices and weights of
the mesh it animates. Some gltf code may show a minimum of 16 actuaor
realtionships per vertex is ?standard? with bunches of zeros, beca the hdwr
wants it that way. That is wasteful and from what I have seen x3d would not
make it the prime directive that the authortime  has to look like the
runtime. That has always been. There is runtime and there is authortime.
HAnim, is concerned with composability and clear documentation. Sure, it
may depend upon how you learned it, but for authortime, if you take care of
it at the jointss, then the mesh will be ok.

I agree that it should be the job of the engine/browser to make
authoring/editing easy while still providing flexibility and power.
However, the tradeoff is that this makes implementations harder or perhaps
completely unfeasible in some cases.

>
> The gltf binary is for under the covers, more for rendering than for
authoring. The runtimes want the data in gltf form and hanim says that is
fine, take the way we do it and create your binary, maybe using a style
sheet, or vice-versa. Every current x3d runtime converts the x3d utf-8 text
to a target binary form at some point. That is why a set of properly
structured binaries might be able to be imported rather easily because the
runtimes probably use that form anyway, just input in different, more
abstractly-connected containers than x3d hanim. The names and readability
are different while the data, the data structures, and the necessary
connections are the same under the covers. I hope all the gltf and x3d data
types match. gltf is fine, as long as I can edit the source.

It is possible to map many of the glTF data structures to X3D and HAnim
data structures but this ability is unrelated to data types or binary
encoding. X3D and HAnim provide enough flexibility to fit glTF. The reverse
is not always the case.

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