[x3d-public] Depreciated HAnimHumanoid.joints field?

Sun Sep 28 20:58:40 PDT 2025

> Modelling of non-human HAnim figures (https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/concepts.html#ModellingOfNonHumanHAnimFigures)
.jointBindingPositions

jointBindingRotations
jointBindingScales 

No need for "joints" field at all, then, just define that the order of data in
these fields must be the same as the order of appearance in the skeleton field. 
WaaLaa, we are rid of joints, segments, sites.  

Anyway, if really needed, which it is not, then the only need is for
the Name='string' that is the list of names, consisting of an MFstring
field instead oft that cumbersome and misused MFNode field definition. 
Again, the HAnim naming conventions are strict enough to find the
Joint DEF names by Humanoid name and Joint name 

Probably the Best idea is to include spec for metadata that includes
joint, segment, site names, maybe as well as other interface names.
One day when the AIxHumanoid takes over then all it will need is the
metadata anyway.

All Goood,
Joe 

-----Original Message-----
From: Extensible 3D (X3D) Graphics public discussion <x3d-public at web3d.org>
Sent: Sep 27, 2025 5:09 PM
To: Holger Seelig <holger.seelig at yahoo.de>
Cc: Don Brutzman <don.brutzman at gmail.com>, Extensible 3D (X3D) Graphics public discussion <x3d-public at web3d.org>, Humanoid Animation (H-Anim) Working Group <h-anim at web3d.org>
Subject: Re: [x3d-public] Depreciated HAnimHumanoid.joints field?

[added hanim mailing list]

Holger, good catch!  This is a very recent draft change which had not yet been announced for group review (while awaiting release of annual HAnim meeting minutes from Web3D 2025).

Thanks for your insightful observation, no one else caught that relationship.  The primary reference, with relevant excerpts so far, is
  *  Humanoid animation (HAnim) architecture v2.1 draft, part 1, clause 6 Object interfaces, 6.1 Humanoid
  *  https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/ObjectInterfaces.html#Humanoid
  *  The joints, segments, and sites fields are deprecated since they are duplicative and redundant.
[Editors note: typically these fields are populated in models by first defining the skeleton field, containing all of the joints, segments, and sites fields, followed by USE nodes at the end of the HAnimHumanoid node definition. The Castle viewer confirms that the fields are duplicative by automatically creating those USE nodes if missing or incorrect. See Mantis 1512 (https://mantis.web3d.org/view.php?id=1512)]

Unfortunately there is a lockout problem for my mantis account - trouble report submitted.  We keep track of consensus details in there so that there is a trail of logic supporting any specification changes... I will update when my access is restored.

Looks like the specification does include prose for the dependency you are defining:
  *  The following five fields provide information needed for each binding pose of a humanoid or non-human model, as specified in 4.8.3 Modelling of non-human HAnim figures (https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/concepts.html#ModellingOfNonHumanHAnimFigures).  *  jointBindingPositions

  *  jointBindingRotations

  *  jointBindingScales

  *  skinBindingCoords

  *  skinBindingNormals

None of these five fields shall be used in a model that has a skeletalConfiguration value of "BASIC".
The jointBindingPositions, jointBindingRotations, and jointBindingScales fields specify arrays of positions, rotations, and scale values, respectively. These sets of attributes are associated with the array of Joint objects contained in the joints field. If only one value is provided (such as the default value) then it is applied to all listed Joint objects equivalently. Applying each set of these translation, rotation, and scale values, in order, to the corresponding Joint objects maps a skeleton to the binding pose.

Suggested path forward:

  *  remove the deprecation for the joints field, it is not appropriate
  *  Relax the dependency on redundant/superfluous definitions for joint, segment and site MFNode arrays of USE nodes with prose along the lines of:
  *  If any of the jointBindingPositions, jointBindingRotations, and jointBindingScales fields are defined, then the joints field must also be defined with the same indexing order, and each MF array must have the same length.
  *  Add corresponding rule in X3D Schematron to check for this relationship, also update X3D Tooltips.
  *  Ensure that corresponding field definitions in X3D 4.1 draft for HAnimHumanoid continue to match.
  *  Improvements are always welcome.
Wondering, do you think it is OK to deprecate the segments, and sites fields?  Perhaps those fields have a current or future use that we have not anticipated (such as IK inverse kinematics). 

Of note is that deprecation does not forbid the use of a field, rather it indicates that it is likely to be removed in a future follow-on version.
  *  Wiktionary, deprecate
  *  https://en.wiktionary.org/wiki/deprecate

3. (transitive (https://en.wiktionary.org/wiki/Appendix:Glossary#transitive), chiefly computing (https://en.wiktionary.org/wiki/computing#Noun)) To declare something obsolescent (https://en.wiktionary.org/wiki/obsolescent#English); to recommend against a function, technique, command, etc. that still works but has been replaced.   *  The 'bold' tag has been deprecated in favour of the 'strong' tag.

  *  It is still supported but strongly deprecated.

We will review this issue next Monday afternoon during HAnim specification editing session.

Again thanks for your implementation and evaluation efforts and insights.

all the best, Don
-- 
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting  https://RelativeMotion.info

On Sat, Sep 27, 2025 at 12:33 PM Holger Seelig via x3d-public <x3d-public at web3d.org (mailto:x3d-public at web3d.org)> wrote:
As I discovered the HAnimHumanoid.joints field is now deprecated in X3D4.1. This is not good. Because the values in jointBindingPositions, jointBindingRotations, jointBindingRotations depend on an order and mapping to a specific HAnimJoint.

The first value should belong to the first joint in the joints fields and so on. 

If there is now no joints fields such connection is hard to determine, may be by traversing the skeleton, but how, because there are a lot of different traversing strategies. 

https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/hanim.html#HAnimHumanoid

Best regards,Holger

—
Holger Seelig
Leipzig, Germany

holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de)
https://create3000.github.io/x_ite/
https://patreon.com/X_ITE

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org (mailto: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/20250929/6cc3d78e/attachment.html>