[x3d-public] HAnim draft 2.1 review, Mantis issues: Site node feature points, possible Pose node, Joint constraints for Range of Motion (ROM), etc.

[Don Brutzman]

We continued working through Carol McDonald's excellent list of potential
changes to HAnim Architecture.

As part of weekly editor meetings with Dick, Carol, Joe and (occasionally)
Myeong, I have prepared Mantis issues for tracking progress and applying
proposed changes.  The full Mantis issues are accessible to Web3D
Consortium members.

=========================================================================

We first worked on wording for Level of Articulation (LOA) to improve
clarity.

   - HAnim draft v2.1 specification, clause 4 Concepts, 4.8.5 Levels of
   articulation (LOA)
   -
   https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/concepts.html#LevelsOfArticulation

4.8.5 Levels of articulation (LOA)

Level of articulation (LOA) represents the complexity and detail of joints
for a humanoid skeletal hierarchy, and can be used for generating various
motions based on the joints.

Defining the LOA for a given humanoid is useful for sharing interoperable
animations. The humanoid_root Joint is always required for every LOA, so
that the location and orientation of the Humanoid can be moved within a
scene.

There are five levels of articulation. Each lower LOA remains a strict
subset of higher LOAs, and so animations for lower LOAs also work as
satisfactory animations for higher LOAs.

   - LOA‑0 represents only the humanoid_root Joint object without an
   accompanying hierarchy, as shown in (Figure 4.3 <#f-LOA0Joint>).
   - LOA‑1 represents the simplest organization and hierarchy of joints for
   a humanoid. There are up to 18 joints and 18 segments. Each segment has
   a joint in the hierarchy. Figure 4.4 <#f-LOA1Joints> shows all of the
   specific represents LOA‑1 joints.
   - LOA‑2 consists of up to 71 joints and 71 segments (Figure 4.5
   <#f-LOA2Joints>).
   - LOA‑3 consists of up to 94 joints and 94 segments (Figure 4.6
   <#f-LOA3Joints>).
   - LOA‑4 builds on LOA‑3 by adding anatomical details of hands and
feet (Figure
   4.7 <#f-LOA4Joints>). LOA‑4 consists of up to 148 joints and 148
   segments. Hands and feet joints for LOA‑4 are illustrated in 4.9.3
   <#TheHands> and 4.9.4 <#TheFeet> respectively.

Animation interoperability is a key design goal of LOA representations.
Some of the predefined joints for a given LOA might be omitted, and other
joints may be included in the given model, but animation for missing (or
added) joints might not occur. Animations for higher LOAs can work for
humanoids at lower LOAs, but unused animation events are ignored without
error.

TODO. Specification editors and the HAnim Working Group are considering
inclusion of additional joints in various LOAs, in order to better support
modeling of clothing and possibly to encourage interoperable animation with
other specifications.

TODO. Specification editors are considering proper names for each LOA in
order to better communicate the functionality of LOA use cases. For example:

   - LOA-0. Humanoid location and direction
   - LOA-1. Simple animation and poses.
   - LOA-2. Everyday motion and sports.
   - LOA-3. Clothing and apparel.
   - LOA-4. Anatomically correct human skeleton.

=========================================================================

   - Mantis 1502: coordination issue for HAnim 2.1 features supporting
   clothing and coveroid
   - https://mantis.web3d.org/view.php?id=1502
   - This is a coordination issue for HAnim 2.1 features supporting
   clothing and coveroid.

   Carol McDonald has submitted a large number of suggested enhancements
   and capability improvements. We are steadily reviewing them. Direct
   enhancements are made by editor consensus, while potential major changes
   require full review and consensus building by HAnim and X3D working groups.

   * HAnim Architecture r2 (recommendations by Carol McDonald)
   *
   https://docs.google.com/document/d/1IMCr83o0hEq-ga5YYpxqTUM09D2A3Tdq/edit

   Also proposed with direct potential impact to clothing/coveroids and
   animation: Pose node (aka HAnimPose in X3D).

=========================================================================

   - Mantis 1503: add new feature points for Site node
   - https://mantis.web3d.org/view.php?id=1503

Description Add additional new feature points for Site node.

* ensure well-defined with corresponding references when appropriate (in
documentation, at least)
* careful consistency with naming conventions
* synonyms and alias terms identified, often correlating different
authoritative references

Suggested changes:
* HAnim Architecture r2 (recommendations by Carol McDonald)
* https://docs.google.com/document/d/1IMCr83o0hEq-ga5YYpxqTUM09D2A3Tdq/edit
Additional Information * Humanoid animation (HAnim) architecture draft 2.1,
clause 4 Concepts, Table 4.7 — Site and Segment relationships
*
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/concepts.html#t-SiteSegments

* Humanoid animation (HAnim) architecture draft 2.1, Annex B (informative),
Feature points for the human body
*
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/FeaturePoints.html

* various sections and figures, especially Table B.2 — Feature points
*
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/FeaturePoints.html#t-FeaturePoints

* X3D Tooltips, HAnimSite
* https://www.web3d.org/x3d/tooltips/X3dTooltips.html#HAnimSite

* HAnim2 Name - HAnim1 Alias Tables
*
https://www.web3d.org/x3d/content/examples/HumanoidAnimation/HAnim2NameHAnim1AliasTables.txt

Much planning and discussion detail follows within the Mantis issue.  Some
additions have been applied and can be observed at

   - Table 4.7 — Site and Segment relationships
   -
   https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/concepts.html#t-SiteSegments

   - look to bottom of table, more entries will follow from Carol's
   clothing-motivated list


Index Site name Segment names
 for LOA‑4 Segment names
for LOA‑3 Segment names
for LOA‑2 Segment names for
LOA‑1 Segment names
for LOA‑0
121 l_axilla l_clavicle l_clavicle l_clavicle l5 sacrum
122 r_axilla r_clavicle r_clavicle r_clavicle l5 sacrum
123 l_underbust t8 t8 t6 l5 sacrum
124 r_underbust t8 t8 t6 l5 sacrum
125 virtual_crotch pelvis pelvis x_ischium
sacroiliac or hip? x_ischium sacrum
=========================================================================

   - Mantis 1504: Consider Pose node (aka HAnimPose in X3D) to support
   inclusion of I, A, T, other poses within Humanoid
   - https://mantis.web3d.org/view.php?id=1504

Description Consider Pose node (aka HAnimPose in X3D) to support inclusion
of I, A, T, other poses within Humanoid

Current specification omission: prose defines I, A, T, other poses
conceptually but provides no means of defining them. Only adjustments for I
pose are permitted.

Having multiple poses present will also offer opportunity for additional
animation between poses, either interpolating smoothly or switching
immediately.

Related, once poses are better defined:
* coherent discussion on possible new definitions for "posture" concepts.
* Getting clear on Pose definitions first seems necessary because posture
changes are likely relative to the original (or current) pose of the
humanoid.
* Preliminary conjecture: might posture be defined from perspective of
actual physical human individual, while pose remains (increasing well
defined) for the virtual HAnim model.

Related, but not constraining: this capability may relate to definitions
for skeletalConfiguration parameter, which is only defined currently for
BASIC. This is a design opportunity and prose omission that can best be
addressed once Pose and posture are both satisfactorily defined.

This is a start at defining initial goals clearly for an important topic
that (historically at least) can lead to much ambiguity.

=========================================================================

   - Mantis 1505: Joint minAngle, maxAngle constraints to define limits for
   joint range of motion (ROM)
   - https://mantis.web3d.org/view.php?id=1505

Dick and I made further useful progress during discussions today.

Description Concept: if we already have constraints on rotation axis, and
now add constraints on rotation angle, then we can hopefully express Range
of Motion (ROM) limits for a given Joint.

Goal: try to define SFFloat min/max angle limits, applied to each joint
rotation, at least for planar rotations.

Angle only limits the angular portion of the axis-angle SFRotation for each
Joint, which is in the 'rotation' field.

These might possibly provide a fairly natural representation for range of
motion (ROM) constraints.

Further demonstration needed to determine whether these are also useful for
out-of-plane rotations, which remains an important prerequisite. In other
words, if a Joint axis varies somewhat (which often occurs for human
joints) then it needs to be shown that minAngle/maxAngle constraints (tuned
to a given set of axis rotations) are still helpful and not confounding.

Context: minAngle/maxAngle values constrain the angle of the rotation,
while llimit/ulimit/rotationAngle constraints restrict the axis of the
rotation. Thus these fields together define the allowed range of spherical
Joint rotation.

Note that actual received animation values (provided via diverse sources)
might readily exceed such constraints. The animation values are
independent, the presentation of the joint is what gets effectively clamped.

*
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/ObjectInterfaces.html#Joint

Current specification limits on Joint define allowed axis variation using
llimit, ulimit, limitOrientation

"The ulimit and llimit fields of the Joint object specify the upper and
lower joint rotation limits. Both fields are three-element float sequences
containing separate values for the X, Y and Z rotation limits. The ulimit
field stores the upper (i.e. maximum) values for rotation around the X, Y
and Z axes. The llimit field stores the lower (i.e., minimum) values for
rotation around those axes. A sequence containing zero elements indicates
that the joint is unconstrained. A non-empty sequence can only consist of a
single three-value element. If ulimit and llimit values are provided, both
must be defined together. If llimit and ulimit are equal, no constraints
are applied to Joint object rotations."

(Incidentally we are not actually sure where this concept originated, but
suspect such values might be produced by IK or mocap tools.)
---
HAnim standard:
* HAnim v2.1 draft Architecture, clause 6 Object interfaces, 6.3 Joint
*
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/ObjectInterfaces.html#Joint

Once added to HAnim v2.1 draft, also add to X3D v4.1 draft:
* X3D v4.1 draft Architecture, clause 26 HAnim component, 26.3.3 HAnimJoint
*
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/hanim.html#HAnimJoint
---
Initial specification interface additions and prose:

   - HAnim 6.3 Joint
   -
   https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/ObjectInterfaces.html#Joint

   SFFloat [in,out] maxAngle 0 (-inf,inf) # or [-2pi,2pi]
   SFFloat [in,out] minAngle 0 (-inf,inf) # or [-2pi,2pi]

The maxAngle and minAngle fields specify the maximum and minimum angles in
radians defining the allowed range of motion (ROM) for a joint. These
values constrain the angle component of the corresponding axis-angle
rotation field. If both maxAngle and minAngle values are equal, or if
maxAngle is less than minAngle, then no angular constraints are applied.
These constraints are applied in concert with
llimit/ulimit/limitOrientation constraints. Together these fields define
the allowed range of Joint rotation.

NOTE. These combined constraints only affect Joint presentation and do not
affect the source of animated inputs for the set_rotation field.

Editors notes:
* TODO create a diagram illustrating range of motion (ROM) use cases, each
showing an example Joint rotation axis with corresponding maxAngle and
minAngle values.
* (This approach is somewhat similar to X3D CylinderSensor definitions
using a given axisRotation with corresponding maxAngle and minAngle values.)

Working on example models and diagrams will be essential for understandable
progress on this topic.

=========================================================================

   - Mantis 1506: enable assignment of index numbers for Site, Joint,
   Segment as synonyms for name enumerations
   - https://mantis.web3d.org/view.php?id=1506

Description A potential animation improvement is to assign index numbers
for Site, Joint, Segment formally within HAnim standard. Table entries
indicate these index numbers, but there is no formal designation that they
might be used equivalently (either separately in authoring tools or
directly in the skeleton definitions themselves).

Each of the individual index values are already recorded in X3D XML Schema
and X3DUOM (and thus available within other tools). Such indexing may lead
to future possibilities using carefully named enumerations as simpler
values for animation engines.

=========================================================================

Wow, that is a lot for the past two weeks!  Onward we go.  Thanks for all
efforts, careful thinking, and feedback.  Questions and insight are always
welcome.

Have fun with HAnim and X3D!  🤓👍

all the best, Don
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250806/dd218d1c/attachment-0001.html>