[x3d-public] HAnim and glTF skins

Thu Nov 29 12:52:32 PST 2018

> Q1. what do you guys use?
> Q2. should makehuman export something we like, and if so what?
> Thanks, Doug Sanden (freewrl)

Hey Doug, look at whatever and under the covers you will see the same stuff and condense that and you will see x3d as best practice.  
I forget, does freewrl do any hanim
What should makehuman export? 
A skeleton?
Skin? 
Skeleton with skin bindings?
Animations?
Before we can ask to export we must know what that tool chooses to show to the author. 
For instance you set up a nice animation and ask for export and they send a set of completed frames for a video and you can’t even ever see anything that looks like user code or readable data. Most times you really have to fight to actually get the data you authored.
Humanoid animation is complicated and highly structured. Learn x3d hanim and you will learn most of what there is to know. The rest is can you put it together. 

From: Joseph D Williams
Sent: Thursday, November 29, 2018 11:48 AM
To: John Carlson; GPU Group
Cc: X3D Graphics public mailing list
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  

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. 

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. 

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. 

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.  

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. 

➢ John - My guess is the rig + bvh + something is what we need for the skin deformations.   This is the first time I’ve tried to animate a human, but I’ve done some head shots.

HI John. maybe look at the attachment, this one with some animation. You can play with the BVH with Don, but that is not the native form and is not really required since it is easy to create animations by hand, When you start talking skin, then it is a good step up in understanding and processing and rendering so you don’t have to jump right into the skin part of it. Andreas put up a link to some hanim x3dom examples. 

Best Wishes
Joe

From: John Carlson
Sent: Thursday, November 29, 2018 9:39 AM
To: GPU Group
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] HAnim and glTF skins

My guess is the rig + bvh + something is what we need for the skin deformations.   This is the first time I’ve tried to animate a human, but I’ve done some head shots.

On Thu, Nov 29, 2018 at 10:02 AM GPU Group <gpugroup at gmail.com> wrote:
PS I loved this little tool for making humans
http://www.makehumancommunity.org/
and used the humans in blender for static shot raytrace 
https://sites.google.com/site/commutar/
- see human shots near bottom
x but the export options don't include glTF or x3d
* 
https://github.com/makehumancommunity/makehuman
* collada .dae
* filmbox .fbx
* makehuman exchange (mhx2
* wavefront obj
* ogre 3D
* Stereolithography (stl)
Rig format
* Biovision Hierarch BVH

Q1. what do you guys use?
Q2. should makehuman export something we like, and if so what?
Thanks, Doug Sanden (freewrl)

On Thu, Nov 29, 2018 at 7:34 AM Andreas Plesch <andreasplesch at gmail.com> wrote:
My interest was in supporting animation in glTF inlines  in x3dom. With basic animation pretty much solved as TimeSensor/Interpolator/Route combos, the next step is skinned animation. Since HAnim is actually not strictly limited to humanoids (if the H is ignored), it appears more and more feasible to use it to represent glTF skins and skeletons in a fairly complete manner. At least this is what my first manual translations suggest. I am not familiar with other skinned animation systems but most can export glTF.

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.

One difference is that morph targets can be used outside of a joint hierarchy (skeleton) in glTF whereas displacers are confined to joints and segments within a x3d skeleton. Until displacers are released into the wild, it would mean that glTF meshes with morph targets have to be wrapped in a humanoid node. This seems possible. 

Implementing HAnim vertex wise deformation ultimately needs to be in vertex shaders. This may actually mean using a glTF skin representation since it is perhaps more shader friendly.

-Andreas

---on the phone---

Date: Wed, 28 Nov 2018 16:35:17 -0800
From: Leonard Daly <Leonard.Daly at realism.com>
To: x3d-public at web3d.org
Subject: Re: [x3d-public] HAnim and glTF skins
Message-ID: <20125083-023f-b96a-6586-ab8e6d3ea128 at realism.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Andreas,

I have read all of the messages with this subject. I am responding to 
the first one because I think that is best where my question arises.

Are you working on an understanding and implementation of H-Anim skinned 
animation in X3D or the more general animation of skinned surfaces that 
is done in Maya/Blender/+ in most every other application/use?

If you are doing the more general case would it make more sense to get a 
good understanding of the process and work-flow that is used in those 
applications and practices?

If the intent is to use H-Anim with X3D, you will need to resolve the 
differences between X3D V3.3/H-Anim V1.0 and X3D V4 (not yet in 
existence)/H-Anim V2.0 (perhaps); as you have noted in one of the other 
messages in this chain.

Leonard Daly

> I am collecting information on these skinning systems here:
>
> https://github.com/andreasplesch/x3dom/wiki/HAnim-and-glTF-skins
>
> [This is a editable wiki if anybody wants to add to it]
>
> It looks like the less well known
>
> jointBindingPositions/Rotations/Scales and skinBindingCoords/Normals
>
> fields used for non-humanoid skeletons may be useful but I am not
> certain how to interprete those fields. Castle may not implement those
> as a search did not find a match ?
>
> My understanding is that the transformation matrix defined by these
> fields needs to applied before joint trafos are applied. But to which
> vertices ? The ones listed in skinBindingCoords for sure (if they are
> indexed by skinIndex field in the joint) but how does
> skinBindingCoords and skinCoords field interact ? Does the
> skinBindingCoords field take precedence ? But why then have both
> fields in the first place ?
>
> Could the jointBinding fields equivalently be replaced by a sub-Joint
> node under the joint the fields map to ?
>
> Is there an example using these fields ?
>
> Thanks,
>
> -Andreas
>
>
>
>

-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Past Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20181128/f49fe788/attachment-0001.html>

------------------------------

From: Leonard Daly
Sent: Wednesday, November 28, 2018 4:35 PM
To: x3d-public at web3d.org
Subject: Re: [x3d-public] HAnim and glTF skins

Andreas,

I have read all of the messages with this subject. I am responding to the first one because I think that is best where my question arises.

Are you working on an understanding and implementation of H-Anim skinned animation in X3D or the more general animation of skinned surfaces that is done in Maya/Blender/+ in most every other application/use?

If you are doing the more general case would it make more sense to get a good understanding of the process and work-flow that is used in those applications and practices? 

If the intent is to use H-Anim with X3D, you will need to resolve the differences between X3D V3.3/H-Anim V1.0 and X3D V4 (not yet in existence)/H-Anim V2.0 (perhaps); as you have noted in one of the other messages in this chain.

Leonard Daly

I am collecting information on these skinning systems here:

https://github.com/andreasplesch/x3dom/wiki/HAnim-and-glTF-skins

[This is a editable wiki if anybody wants to add to it]

It looks like the less well known

jointBindingPositions/Rotations/Scales and skinBindingCoords/Normals

fields used for non-humanoid skeletons may be useful but I am not
certain how to interprete those fields. Castle may not implement those
as a search did not find a match ?

My understanding is that the transformation matrix defined by these
fields needs to applied before joint trafos are applied. But to which
vertices ? The ones listed in skinBindingCoords for sure (if they are
indexed by skinIndex field in the joint) but how does
skinBindingCoords and skinCoords field interact ? Does the
skinBindingCoords field take precedence ? But why then have both
fields in the first place ?

Could the jointBinding fields equivalently be replaced by a sub-Joint
node under the joint the fields map to ?

Is there an example using these fields ?

Thanks,

-Andreas

-- 
Leonard Daly
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Past Chair
President, Daly Realism - Creating the Future 

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

------------------------------

Subject: Digest Footer

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

------------------------------

End of x3d-public Digest, Vol 116, Issue 52
*******************************************
_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org
_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

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