[x3d-public] both X3DOM and X_ITE.

[Joseph D Williams]

I will probably be gone for a week or so but so very happy to exchange with you about hanim. When looking deep enough we can see that the entire purpose of VRML and X3D was/is to produce a realistic transportable humanoids for use in a realistic or contrived transportable environments.  

Of course we need both the humanoids and the environments but the humanoid thing is hard because first it is so complex. Second, is that the overall design goal is transportable animations. This also means transportable or ‘standard’ characters. Thus, web3D.org with much outside help put together this detailed assemblage of pieces, provided a basic model of a ‘standard’ humanoid, and then to top it all off, somebody insisted on giving those parts medically-oriented names. Basic VRML and X3D has the parent-child structures needed for realistic animation and sensing, so no big deal there. 

I still think a giant step in x3d hanim was exposing the joints as the main animation interface  Most authoring systems had stuck the boneends  together somehow then, as exposed to the author, animated bone orientation. Instead, the basic tool to move something is to control its parent joint. If you get the hierarchy right and animate the right joints, then it is fun. It’s silly, but since the hanim default joint rotation is 0 0 1 0, you can pretend to sit on it facing +z, and steer the pitch and roll and yaw to move the child hierarchy just like you are fly’n the thing. But still, it takes some time to comprehend and there is some commerciality making claims, but the future use of the hanim model is naturally to hook it up with some physics and haptics so it can figure out how to open the door and go walking on its own, so, not so easy and straightforward. If you use a viewpoint in the eyeball, then you start by orienting the viewpoint to face +z rather than default -z. left is +x. 0 0 0 is the floor, between the feet. +y is up. You can build a character with your exact dimensions.   

Thanks and Best, 
Joe




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

Good, glad you found that second example.. No scripts in the panel-driven. Instead, sets of interpolators for each activity are there. In both cases, if Humanoidis not understood, then nothing. You need a pretty good browser that knows humanoid and skeleton to play the scripted boxman, then more capability to play the unscripted boxman I think I recall that the protos are not in the panel version. 

Incidentally, those panel selections represent a group of ‘standard’ animations in the sense that if we have a ‘standard’ humanoid, then the ‘standard’ animations will play as expected. 

< X_ITE source code.  I see src/x_ite/Components/H-Anim/HAnim…

Great, I have not been following x_ite except when it came n as the default player for the examples and would not run the HAnim examples. I don’t get any boxman in either of those examples so I hope it is coming.

Thanks and Best,
Joe


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

I just peeked at the X_ITE source code.  I see src/x_ite/Components/H-Anim/HAnim… so perhaps something is coming soon.


John

Sent from Mail for Windows 10

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

So BoxMan is here (proto version, single animation):

http://www.web3d.org/x3d/content/examples/Basic/HumanoidAnimation/BoxManIndex.html

and here (native version, multiple animations):

http://www.web3d.org/x3d/content/examples/Basic/HumanoidAnimation/BoxManAnimationPanelIndex.html


These view in X3DOM JSON (with protoexpander) with some points being animated (via X3DJSONLD), however the main body (skin I guess) does not animate.  There’s also the problem of SFRotation being undefined.

Probably our best bet is to try to animate BoxMan.json for X3DOM? Should we go for X3DOM scripts first, then try to do the right thing in my script preprocessor?  I can provide a protoexpanded version (or retrieve from X3DJSONLD), it provides expanded scripts as well (same script with different DEF).

X_ITE doesn’t show the main body because there aren’t HAnim tags I think.  Attempting something in X_ITE will require a full PROTO example (ala the Nancy Protos), or native tags.

Thanks,

John

Sent from Mail for Windows 10

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

➢ Is this JoeKick?


That is how it looks in X_ite and others that do not recognize our x3d hanim Humanoid container. Since there is no geometry of the skeleton, except the xyz reference, maybe nothing of the Humanoid moves, or if simple humanoid, then only the skeleton xyz reference moves. Or, if skin but not skin bindings are recognized, then the skin will remain and the xyz will move. If ‘skin is known and the texture is mapped properly, then everything works. 

The skin is the indexedfaceset in the user code. It is just a collection of vertices as generally defined surface features and sites in our ‘standard’ hanim example Part 1 Annex A and B.
Look at the Joint objects to see how the skin index (order of appearance in the code) is bound to one or more joint objects, with a weight on each joint.

Please note that the latest HAnim standard (DIS) is available from web3d.org

In this latest and the previous standard there is an example program in Part 1 Annex A that shows the prototypes for the various hanim objects. Except those examples don’t do the ‘skin’. Only the Boxman has a proto for the ‘skin’ animation. 

In the Joekick animation we assume full current hanim conformance. Really, try this example on Free BSContact or Flux or Instant. A point for Instant does have the problem in that the JoeKick author depends upon the fact that an indexedfaceset includes a default texture mapping.  At one point, not sure about now, Instant was taking exception to generating and using a default map for hanim skin even if the shape is an ifs because everyone has to gen those custom texcoords anyway. I disagree because an ifs is always supposed to generate a map. Anyway, the effect of not having a texture map is that the skin moves through the texture. 

Anyway, I think I saw a video of the thing kicking somewhere but the main drift in evaluating any feature of x3d is first find a legacy browser that will do the current standard interfaces and then have a look at the user code. HAnim is ‘old’ but really, the folks that deeply know this stuff actually helped out. How else would you document human-readable structure and bindings (the rig) and the animation data. Really, check out the hanim Displacer, which in a way is most basic general tool because skeleton is not needed. If a tool can do hanim Displacer, then pretty sure skeleton-driven skin animation is within reach. 

Thanks and Best, 
Joe



Sent from Mail for Windows 10

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

Is this JoeKick?



Sent from Mail for Windows 10

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

The point is not scripting, most of hanim can work with a simple hierarchy and rotation interpolators. In simple hanim, the geometry is child of a segment which is a child of a joint. The parent joint is rotated then the child joint, segment,  any geometry, and site hierarchy moves as expected. That is why the basic hanim can be easily created from x3d prototypes with no need for scripting. 

Seems like the tough part is making the seamless continuous-mesh skin work. This is done by binding each skin vertex to one or more joints, then moving individual skin vertices a weighted function according to rotation of the controlling joint(s). There is not really any similar feature in basic x3d so much scripting is needed even to create a prototype (see Boxman). Obviously this works much nicer if the script is great fast code deep in the browser. 

The capability for this in a modern authoring system is fundamental and included in the basics of animation. For starters, you either morph shapes or, really the most fun, is to create an armature (skeleton) and use some algorithm to move a geometry according to movements of the armature. Then add some morph stuff for fine detail. Most times the most carefully guarded secrets of the animator is creating the skeleton-skin and morph bindings. 

HAnim covers both these styles of animation. It is this data that allows animations to be exported from authoring systems, reused and shared. At the time, I guess it was decided to implement this form of animation under Humanoid rather than individual objects in basic x3d. That is also the reason why the deformable skin part of hanim is not prototyped from standard x3d features and needs quite fast and intelligent scripting to get it working in realtime. For any reasonable use, all the computation must be built into the most basic structures of the browser. I don’t know, it might be tough because in the x3d hierarchy there is nothing basic about moving one or more things (vertices) according to the movement of one or more things (joints) plus keeping careful track of those things frame-to-frame. 

So you can see that hanim is built upon basics of x3d and that the hanim skeleton-driven deformable skin functionality, and the spacetime-driven morph technique shown in the hanim Displacer node, should perhaps be available in fairly basic x3d. HAnim sort of hijacked the basic functionality of making a snake-like thing or any other skeleton type with a continuous mesh surface. It is preferable to animate features of a geometry in a scene using the combination of a set of ‘joints’ that controls a continuous-mesh geometry ‘skin’ (Seamless) instead of the sometimes clumsy method of using a set of separate geometries (often having seams at intersections) for the animated shape . 

I think it has been suggested that the hanim features should be available in x3d in a less structured way to allow an author to create the animated object out in the scene rather than only from inside the Humanoid container required by x3d hanim, and it should be. 

I would wish for this to happen and will discuss with anyone the current hanim interfaces. Hey, BSContact, Instant, and Flux did it. I’ve been hoping for Octaga to add this because the rest of their browser is fine. 

http://lo-th.github.io/Avatar.lab/

Lots of work but yeah, x3d hanim does all that. Looks like their rest pose, before animation, follows the x3d hanim standard. A BVH input is offered, but we would hope they could export something more usable. Couldn’t see the list of bones used, or how to edit or create animations. Under the hood the avatar and its animation uses the same data as hanim. I mean when you figure out that bone orientations are the same as joint rotations - and lots of other amazing stuff then you just gotta have the x3d hanim capabilities. Much more fun to animate detailed movements using the (hidden in this avatar) joints rather than dragging bones around. If you start in max or any doing skeleton-based animation, there will be a special choice that gives you a ‘standard’ biped that except for a couple of minor joints is an hanim loa2.  

Please see some x3d hanim examples and videos. HAnim does all that (a Bone for them is a Segment for x3d). Like many authoring systems, the joints are not shown or even mentioned.  We do all that with human-readable code and documentation you can walk away with – animations and all. I mean, really, if your browser can’t do this stuff then … 

But the real purpose of x3d in this is to document and show implementations of industry best practices. I think we can show that x3d hanim does that. The only divergence I can find is that x3d uses axis-angle instead of unit quat in our data storage. 

Thanks and Best, 
Joe
. 


From: John Carlson
Sent: Monday, May 28, 2018 8:35 AM
To: Joe D Williams
Cc: Andreas Plesch; x3dom mlist; X3D Graphics public mailing list
Subject: RE: both X3DOM and X_ITE.

I found this:

http://lo-th.github.io/Avatar.lab/

John

Sent from Mail for Windows 10

From: John Carlson
Sent: Monday, May 28, 2018 11:23 AM
To: Joe D Williams
Cc: Andreas Plesch; x3dom mlist; X3D Graphics public mailing list
Subject: Re: both X3DOM and X_ITE.

I'd also be afraid that JavaScript isn't up to the HAnim animation task.  Got any examples of JavaScript HAnim?

On Mon, May 28, 2018, 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
 
 








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