[x3d-public] Depreciated HAnimHumanoid.joints field?
John Carlson
yottzumm at gmail.com
Mon Sep 29 01:34:11 PDT 2025
As holger mentioned, we would probably have to include how skeleton is
traversed (probably in order, as opposed to post order or pre order) depth
first vs breadth first, etc.
On Sun, Sep 28, 2025 at 11:00 PM Joe D Williams via x3d-public <
x3d-public at web3d.org> wrote:
> > 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:
>
> 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
>
>
> _______________________________________________
> 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/20250929/d6431b5c/attachment-0001.html>
More information about the x3d-public
mailing list