<div dir="ltr"><div dir="auto">Joe, excellent points. See below.<br>
<br>
> Date: Thu, 29 Nov 2018 11:47:34 -0800<br>
> From: Joseph D Williams <<a href="mailto:joedwil@earthlink.net" rel="noreferrer noreferrer" target="_blank">joedwil@earthlink.net</a>><br>
> To: John Carlson <<a href="mailto:yottzumm@gmail.com" rel="noreferrer noreferrer" target="_blank">yottzumm@gmail.com</a>>, GPU Group <<a href="mailto:gpugroup@gmail.com" rel="noreferrer noreferrer" target="_blank">gpugroup@gmail.com</a>><br>
> Cc: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" rel="noreferrer noreferrer" target="_blank">x3d-public@web3d.org</a>><br>
> Subject: Re: [x3d-public] HAnim and glTF skins<br>
><br>
> ? 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.<br>
><br>
> 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<br>
<br>
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.<br>
<br>
><br>
> HAnimDisplacer<br>
>  coordIndex    [  numerical index of each parent geometry vertex<br>
>    to be animated in the same order as they appear<br>
>    in the user code for the target geometry ]<br>
>  displacements  [  x,y,z in skeleton space<br>
>    maximum displacement of each vertex  ]<br>
>  weight        0 to 1 animation control<br>
>    (linear interpolation)<br>
>    0 = same location as parent mesh initial vertex<br>
>    1 = defined maximum displacement location of parent mesh vertex<br>
><br>
> 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.<div dir="auto"><br></div><div dir="auto">That is identical to morph targets in glTF. There, for some reason, the weights are defined in the Node (transform) around the morphed mesh.</div><div dir="auto"><br></div><div dir="auto">In addition, morph targets also define normal and tangent 'displacements', so they do not need to be recomputed if available.</div><div dir="auto"><br>
><br>
> 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.</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br>
><br>
> 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.</div><div dir="auto"><br></div><div dir="auto">Displacer could be a GPU friendly, simple Coordinate/NormalInterpolator.</div><div dir="auto"><br>
><br>
> 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.<br>
><br>
> 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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br>
><br>
> 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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div><br>-Andreas<br><br></div></div>
</div>