[x3d-public] Depreciated HAnimHumanoid.joints field?

Mon Sep 29 08:57:37 PDT 2025

John: Indeed, we'd need to clarify in spec how the joints order is to
be determined by the implementation, e.g. depth-first. I know that
depth-first may be kind of obvious... but it's important to be precise
here :)

Aaron:

- As for file size: For most "pretty / real-life" 3D models that I
have, the file size is determined mostly by the per-vertex data
(indexes, positions), because there's a zillion of vertexes :), so
size of most other things becomes "almost ignorable" when looking at
the file size. Oh, and also embedded images / audio, like using data
URI or PixelTexture, can eat size significantly. So I would not
suspect much size gain from removing things like "joints list"... OK,
but I can be wrong, testcases showing the gain (before and after
removing these fields) would be welcome to back up this.

- As for incorrect browsers duplicating geometry -- this seems an
independent problem IMHO that should be addressed in these browsers.
In general, in X3D, one is not supposed to "render all children nodes
in all MFNode lists", browsers should have a code to render e.g.
"HAnimHumanoid.skeleton", "HAnimHumanoid.skin" but not
"HAnimHumanoid.joints" . This is the relevant code in CGE, that
accounts for both H-Anim 1.0 and 2.0:
https://github.com/castle-engine/castle-engine/blob/aa61bfff4593943842ad73f492e9e4d96993d882/src/scene/x3d/x3dnodes_standard_h-anim.inc#L294
. Other X3D nodes also have special rules, like Switch or LOD, of
"where to enter".

Thank you both for answers. I understand the reasons better... but
admittedly I still think that we don't gain much, and we introduce
potential source of problems (if implementations will deduce different
number of joints, crazy things will happen).

And looking at others, like glTF, they don't do this, i.e. they just
have explicit list of joints. Collada is like glTF in this regard too,
they have <joints> in <skin>.

Regards,
Michalis

pon., 29 wrz 2025 o 16:54 Bergstrom, Aaron via x3d-public
<x3d-public at web3d.org> napisał(a):
>
> Everyone,
>
>
>
> The way I remember the discussion from last week, the reasoning behind deprecating these fields was as follows:
>
> Reduction in file sizes
> Some browser/viewer implementations of HAnim would incorrectly build a duplicate the entire avatar. However I suspect this is more of a problem segment-based avatars than skinned avatars
>
>
>
> If these fields end up not being deprecated, then there should be some kind of statement in regard to browser/view implementation about not duplicating the geometry… or not duplicating nodes that don’t need to be duplicated.
>
>
>
> Aaron
>
>
>
> From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of John Carlson via x3d-public
> Sent: Monday, September 29, 2025 3:34 AM
> To: Extensible 3D (X3D) Graphics public discussion <x3d-public at web3d.org>
> Cc: John Carlson <yottzumm at gmail.com>; Humanoid Animation (H-Anim) Working Group <h-anim at web3d.org>
> Subject: Re: [x3d-public] Depreciated HAnimHumanoid.joints field?
>
>
>
> 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
>
> .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]
>
> 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.
>
> 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, chiefly computing) To declare something obsolescent; 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
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org