[x3d-public] [x3d] Spec Comment by on 19774-1: H-AnimArchitecture - V1.0

[Joseph D Williams]

Please see inline remarks.
Thanks, 
Joe



From: Don Brutzman
Sent: Saturday, May 19, 2018 6:54 AM
To: Leonard Daly; Humanoid Animation (H-Anim) Working Group
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] [x3d] Spec Comment by on 19774-1: H-AnimArchitecture - V1.0

Forwarded to HAnim Working Group for consideration.  Thanks for your review and these comments.

On 5/17/2018 10:00 PM, Spec Feedback wrote:
> -- Submitter indicates that this comment may be public: *Yes* --
> 
> Comment on 19774-1: H-Anim Architecture - V1.0
> All sections
> 
> 
> -----------------
> These comments were collected from the entire specification document. They
> are divided into 2 sections - General and Specific.  Each numbered item is a
> separate comment.
> 
> 
> General Comments
> 
> 1: The fonts for the fixed-width text elements appear to be significantly
> smaller than that surroiuding text. For eample see 4.2.3
> 2: The text appears to be responsive (viewable in a variety of browser
> widths); however, this was not confirmed using multiple devices. The images
> are not responsive, either by rearranging multiple images across the page or
> reducing the size of the image. This may not be a desired feature of the
> document, but should be mentioned.
> 3: This document does not define industry-standard practice, 

It comepletly docoments industry-standard practices. 
The ‘standard’ type data structures for this skeleton-based animation are the same as used in every one of the multiple character animation systems in use. The data structures are transportagble to all the oldest and the latest. In some case, data like rotations are ‘industry-standard’ notations are 0010 instead of 1000 but that is an HAnim opportunity, not a departure from ’industry-standard’ ways to animate. This is shown in the built-in and demonstrated capability for data from an ‘industry-standard’ mocap animation data to be directly used in HAnim ‘standard’ character. 

Basically, anyone who says HAnim is not the same as current systems for the basic hierarchy and animation capabilities has not looked under the covers. 

For hecks-sake, When you into any modelling system and ask for the basic biped, you get what is preactivcally almost an LOA2 like HAnim Annex A and can find skins and yes even export to HAnim. Really, the backup for this idea that X3D HAnim is not a comprehensive and human-readable and executable form of ‘industry-standard’ skeleton-based character animation styles has not tried to discover the hidden forms and structures in the oldest and the newest character animation authoring systems. 

> but either
> defines a separate means or a more general means of h-anim design. 

Yes, it is the most general means of documenting the structures and the data required for hanim design. 

> This extends from concepts (individual components vs. single mesh skin) 

HAnim does either or both, with the same data used by any character authoring system. Namely space-time and coordinates of important features like like joints, sites, and geometry.   

When anyone looks into this they will be very pleased to find that segment, or bone, orientation is the same as joint rotation. They would be happy to find that when the data in some authoring or execution system is the same as documented in 	x3D HAnim. 

> terminology. 


(For example, rigging is defined in section 3, but never used in
> section 4.) As a result the document is not easy to read or comprehed for
> someone use to industry-style humanoid anmiation.

The spec does not teach whatever category of ‘rigging’ you are concerned with. The ‘rigging’ is obvious: make skeleton hierarchy then bind ‘skin’ vertices and weight joint interactions with individual vertices. If anyone looks at most any authoring system this is the same data they use. 

It gets easier when you understand ‘industry standard’ for humanoid animation. It is easy to be involved in industry standard skeletal animation while seeing it from behind a dashboard that hides some of the interfaces with the data. 

Look deep enough to see that HAnim truly captures the basics of it all. Most any authoring system may have variations. For example the system may allow definition of a non-linear interpolation of the deformable skin instead of HAnim any specifies linear. And have features extending the HAnim basic capablilities. But look close and you will find the same skeleton, geometries, and means to animate. 
 
All general use models are based on a hierarchy of joints and segments (bones). Motion is achieved by hierarchal rotation of individual joints, or by translation/rotation of the humanoid root joint.  Either individual geometries are children of the segments in which case the geometry is animated by rotation of the parent joint , or a skin is constructed to be a child of the humanoid and individual vertices of the skin are animated by a weighted displacement that depends on the rotation of specified joints.

That is all there is. If you study various authoring systems, some names are different but these are the basics. 
 

>     a: For reference, industry-style process requires a single-mesh skin that
> is then rigged (skeleton creation with skin weighted-attachment to bones).
> “Bones” are used more frequently than “joints”, but both terms are
> understood.

Joints are not bones. Joints are joints and segments are bones. Please notice that the industry-style process using a single mesh skin with weighted attachments between associated joints for each vertex. The way that HAnim does it is exactly the same. Look in different authoring systems and you will find the name data underneath the covers. 


>     b: For rendering purposes, skin vertices are generally restricted to being
> weighted to no more than 4 joints. This is not a hard requirement, but based
> on practicality and performance, especially real-time performance.

Yes, ok. It just happens to be a bit more ‘efficient’ for typical processors to always use 4 joints/vertex bindings even if some are zero due to processor/GPU specs. Some may try to bind 8 if it ends up rendering faster. 

> 4: For a document that is labeld “Humanoid Animation”, there is very
> little (and perhaps no) discussion of animatation techniques of how the skin
> is animated based on joint motion. 

Wow, please read the part about how the ‘skin’ vertices are bound to the joints by index and weight. You may find another system that appears to bind the skin to the segments, but again, look under the covers. But again, the objective is not to teach this prat of the ‘rigging’ but instead to document the data structures and parameters that document the skin binding and animation. 


> 19774-2 (minimally reviewed) appears to
> relate how to relate motion capture to joint animation of H-Anim characters.

The spec is not a tutorial for prospective animators, it is spec for the HAnim interfaces with some examples. 

> 
> Specific Comments
> 1: It is not clear from the text in 4.2.3 exactly what is required. The
> paragraph states both of the items below. It is not clear if a skeletal
> structure that meets (b), but uses something else besides a joint object to
> the end effector of each appendage qualifies as a H-Anim compliant figure.

The end-effector is called a Site. It is a child of a Segment. For the appendages, fingers and toes, the last (distal) segment is parent of a Site that indicates the end of the segment. All other segments in the skeleton have at one joint at each end.


>     a: “The skeletal description of the H-Anim figure consists of a tree of
> Joint objects that define the transformations from the humanoid_root Joint to
> the end effector of each appendage of the humanoid.”

Right, we see a very detailed example in Annex A. We define the skeleton using a root joint and joint centers. 
Annex A shows the transformations from 0 0 0 (between the feet) in a human scale. 

>     b: “The only requirement of this International Standard for the
> definition of the skeletal hierarchy is that it shall have a humanoid_root
> Joint object defined. All of the other Joint objects are optional and are not
> required for a humanoid figure to be H-Anim compliant.

Right, LOA0 only has the root joint along with the segment to parent other features such as site objects. 
 
> 2: It is not clear if the LOAs and other skeletal definitions are normative
> or not. There is material in the early part of Section 4 that state or imply
> that they are optional or not even relevant (for non-human like figures);
> then later in the section (especially when skeletalConfiguration is
> “Basic”) that the definitions are required. The text needs to be
> rewritten to make these distinctions clearer.

I think in this spec there should be no doubt that this is for a ‘standard’ humanoid. 
The ‘standard’ humanoid must have one of the given hierarchies. 

This is so that animations for a given hierarchy, or higher or even lower, can be used directly with any ‘standard’ skeleton. Transporting animations is the important part

> 3: Section 4.8.1, 3rd paragraph defines what it means for two skeletons to be
> of the same configuration without defining what “identical” means. 

Identical means similar and compatible in order to transport animations.

Identical, maybe not the best word, refers to the hierarchy and the loa. The actual dimensions of the skeleton matter, but if the hierarchy is ‘standard’ then the animation is mostly transportable. 

Suggesting that someone building a character might start designing it using human-scale stuffs is ok by me even though a statement like this would certainly not be absolutely needed in a ‘standard’ describing the exact documentation and runtime needed for humanoid character modeling. 

> Does
> identical mean that all of the transforms are the same? 

No.

> Is a reclining figure
> in the standard pose the same as one arranged on its head? 

For easy import of animations it is best if the initial pose (all joints 0 0 1 0) is the recommended ‘semi-attention’ pose described in the standard. If the base pose for animation is different, then the animation data will probably not produce the desired result. It may be possible to adjust the animation data for different initial pose but it may be hard to do. That is why, for transporting animations, HAnim defines an initial pose. Any skeleton model in any animation system can be set the initial pose then ‘zero’ the thing (all joints 0010). 

> Does scaling matter? 

Yes it can if it doesn’t match other humanoids. In detail, the skin can be scaled to the ‘standard’ humanoid configuration, or even vise-versa. But why not follow a standard that offers transportable animations? 

> If the idea is that two skeletons are identical if all transforms
> from the root node are the same, then that should be stated more clearly.

Please understand that each humanoid model can have realistic or comic dimensions, meaning joint center locations. This allows anyone to build an dimensionally accurate model of, well, even themselves. If they use a ‘standard’ loa then animations is other similar characters can be reused. 


> 4: Section 4.8.4 appears to meet the requirements of 4.8.2 and not 4.8.3. It
> should be a sub-clause of 4.8.2 as it pertains specifically to human-like
> figures. If not moved to a sub-clause, it needs to be made clear in 4.8.2 and
> 4.8.4 that these sections only apply to human-like.

Actually any skeleton-based character can be created. 

> 5: Section 4.9 also appears to apply specifically to human-like figures.
> There is no obvious statement about the connection and cross-requirements
> with this section.
> 6: Section 4.9.5 (and probably others) refers to facial anomation by
> animation of joints to move facial features. There is no discussion of the
> (not exclusive) industry standard of using morph targets to handle facial
> expression changes and combinations.

Please understand that skin bound to the joints is primary, like for when you move the jaw, then you move the associated skin. There is a ‘joint’ for the eyebrows but an author may wish to use morph targets, or a combination of joint-driven and morph targets to get the effect. There is not much doubt that an author would rather base eyelid movement on a joint motion than a morph target (unless the authoring system makes it easy) but most would use both – the joint to get the basic motion, then a morph target for detail. 

Next, please understand how the HAnim Displacer is comparable to Morph targets. Look under the covers and you will see the same data used for the same thing. 

> 7: Section 4.9.8 appears to conflict with statements made in section 4.2.3.
> This conflict needs to be removed or clarified that certain restrictions only
> apply to certain kinds of models.

Thanks, the group can look more closely at that. 

>     a: 4.2.3: “This hierarchy may include any number of optional model
> specific Joint objects, which may be dispersed among the standard H-Anim
> Joint objects. As long as the ancestral ordering of the standard Joint
> objects is preserved, model specific Joint objects may be inserted between
> the standard Joint objects in the hierarchy.”
>     b: 4.9.8: “No new Joint objects are allowed within the chain of the
> standard Joint hierarchy. These non-standard Joint objects may be children of
> either standard Joint objects or other non-standard Joint objects.”

Good, that is a common understanding. The idea is that you can add stuff as long as the additions do not interfere with a standard animation. The idea here is that an author might use a special joint that moves to show a detail, like muscle covering skin displacements, but this addition should not interfere with the ‘standard’ hierarchy of the arm, for instance. This wording should be improved but and implementer will basically understand and this is mainly guidance for the author in constructing a ‘standard’ very transportable humanoid.

> 8: Section 7.3 specifies the minimum support requirements for VRML/X3D. It is
> not clear why X3D nodes not related to creating (e.g., IFS), positioning
> (e.g., Transform), or texturing (e.g., TextureTransform) models are included;
> especially in light of Section 7.4 that only requires the above three
> capabilities plus a viewing requirement. For example, there is no requirement
> in section 7.4 for lighting, navigation, or general information.
> Suggest fix: Define the general requirements first, then indicate the minimum
> VRML/X3D requirements, and lastly the recommended capabilities.

OK, that seems reasonable. 

> 9: Annex F is listed as informative; however, the first sentence of F.2
> indicates that certain things shall be done. Earlier in the document it was
> indicated that the various LOA definitions only applied to human-like
> cahracters. The intent of this section needs to be determine and the text and
> perhaps other places in the document needs to be made consistent.

Yes. 

> 10: The industry-style for creating animated characters is to model the skin
> first, then rig it (create the skeleton and assign skin vertex weights). This
> is not the process described in Annex F. It should be made clear that this is
> different from industry and educatuional practice for US-style animation.

Not so true, I think. Maybe the first thing the commercials wan to sell you is a skin, then texture it, then you find out you need a skeleton to animate it unless you want to morph everything. You will find it best to work by defining your skeleton first. I say pick the LOA4 because it is ok to have joint you don’t animate, learn how to operate it, then figure out what skin, at what density of vertices, you really need to do realtime interactions. 

There are several items that make it hard to understand character animation. X3D HAnim interfaces give you the keys to the vault. And, it’s just like the big guys do it but don’t show you it, and don’t be too shocked, it is the ‘same’ data used by the latest and greatest forms to transport data and it is designed for readability (relative to most commercial authortime/runtime).    

Thanks and Best, 
Joe 


> 
> -----------------
> 
> Submitted on Thursday, 2018,  May 17 - 10:00pm
> by  (Leonard Daly )
> IP: 174.237.6.109
> 
> See: http://www.web3d.org/node/1694/submission/2675
> 
> 
> _______________________________________________
> x3d mailing list
> x3d at web3d.org
> http://web3d.org/mailman/listinfo/x3d_web3d.org


all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman


_______________________________________________
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/20180520/e582cd1d/attachment-0001.html>