[x3d-public] Depreciated HAnimHumanoid.joints field?

Don Brutzman don.brutzman at gmail.com
Sat Sep 27 17:08:28 PDT 2025


[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:

   1. remove the deprecation for the *joints *field, it is not appropriate
   2. Relax the dependency on redundant/superfluous definitions for joint,
   segment and site MFNode arrays of USE nodes with prose along the lines of:
   3. 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.
   4. Add corresponding rule in X3D Schematron to check for this
   relationship, also update X3D Tooltips.
   5. Ensure that corresponding field definitions in X3D 4.1 draft for
   HAnimHumanoid continue to match.
   6. 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> 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
> https://create3000.github.io/x_ite/
> https://patreon.com/X_ITE
>
>
>
> _______________________________________________
> 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/20250927/8a0cd76a/attachment-0001.html>


More information about the x3d-public mailing list