[x3d-public] Depreciated HAnimHumanoid.joints field?

Mon Sep 29 12:41:26 PDT 2025

Holger,

I don’t have a specific use case, but Halloween will be arriving soon, so I
can imagine some Transformers (tm) skeletons.

Understood that if one wants to build a skeleton in an editor or authoring
system, such things should be possible.

John
On Mon, Sep 29, 2025 at 2:36 PM Holger Seelig <holger.seelig at yahoo.de>
wrote:

> John: It is not intended that the skeleton be modified indiscriminately
> and that this now poses a problem, but there are X3D editors and these must
> also be able to cope with changes to the skeleton.
>
> Best regards,
> Holger
>
> —
> Holger Seelig
> Leipzig, Germany
>
> holger.seelig at yahoo.de
> https://create3000.github.io/x_ite/
> https://patreon.com/X_ITE
>
>
>
> Am 29.09.2025 um 20:40 schrieb John Carlson via x3d-public <
> x3d-public at web3d.org>:
>
> I do hope we are also considering joint additions, subtractions and
> reordering during animation.
>
> Thanks!
>
> John
>
> On Mon, Sep 29, 2025 at 12:13 PM Don Brutzman via x3d-public <
> x3d-public at web3d.org> wrote:
>
>> First, a preliminary point: Michalis, thanks for concern about Castle
>> practice.  I wasn't trying to overemphasize your tool as some kind of proof
>> point - in fact, the X3D-Tidy stylesheet performs the same corrections when
>> those jointBinding fields are missing.  X3D-Tidy populates the
>> HAnimHumanoid,joints HAnimHumanoid, segments HAnimHumanoid.sites MFNode USE
>> arrays in order of the default XPath traversal of the tree.  Possibly some
>> other HAnim authoring tools perform similar author assists.
>>
>> Next, what an interesting discussion!  Here are some additional thoughts
>> building on these points.
>>
>> It is intriguing to consider whether a HAnim Canonical Form is needed,
>> defining the normalized order of an HAnim model.  This might have potential
>> use in several ways: comparison of skeletons, version control, digital
>> signature, perhaps some interoperability considerations too.  For example,
>> for X3D in general:
>>
>>    - X3D Compressed binary encoding (CBE) draft 4.0, clause 4
>>    Concepts, 4.2.3 X3D canonical form
>>    -
>>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-3v4.0-WD1/Part03/concepts.html#X3DCanonicalForm
>>
>> Regardless of whether Humanoid/HAnimHumanoid includes an MFNode *joints *field
>> of USE nodes, the ordering must match the jointBindingPositions,
>> jointBindingRotations, *jointBindin**gRotations *fields.  Defining
>> values for those fields is used to return the Humanoid geometry to a
>> binding pose, the "I" pose.  Since this is a one-time activity, and also
>> may depend on ordering of skin vertices, any reordering the HAnimHumanoid.joints
>> array by itself would likely change index order and break the accompanying
>> binding values.
>>
>> If we were to define an expected ordering for HAnimHumanoid.joints array,
>> it would probably have to match the order of appearance of Joint nodes in
>> the model.  This makes simplistic sense, but is also subject to possible
>> error if the skeleton is modified.  Thus if we were to define a typical
>> or canonical ordering, it might be
>>
>>    - breadth-first search (BFS) or depth-first search (DFS) "walking the
>>    tree"
>>    - order of appearance in a file (though that might change when an
>>    application loads the skeleton)
>>    - or, simply not worry about such ordering since each USE node
>>    uniquely points to an HAnimJoint node which includes a unique *name *field.
>>    Having unique *name* fields means that any order in the file is OK,
>>    as long as jointBinding corrections can be applied in order when first
>>    loading the model.
>>
>> Thus it would seem like an explicit definition for HAnim canonical form
>> might be useful someday in the future, but only if jointBindingPositions etc.
>> are not defined.
>>
>> Meanwhile, still not hearing any current (or future) rationale why HAnimHumanoid.segments
>> and HAnimHumanoid.sites need to be retained instead of deprecated.
>> Similarly not seeing any functionality for these duplicative fields... all
>> thoughts welcome.
>>
>> So, again thanks Holger for noting this important dependency.  Making
>> minimal changes to existing specifications is always the best starting
>> point.  Looking forward to weekly discussion this afternoon.  As before,
>> unless discussion goes in another direction, am thinking that we should
>> remove HAnimHumanoid.joints deprecation and add the following
>> requirement to HAnimHumanoid in HAnim v2.1 draft.
>>
>>    - 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.
>>
>> Have fun with HAnim! 🧍
>>
>> all the best, Don
>> --
>> X3D Graphics, Maritime Robotics, Distributed Simulation
>> Relative Motion Consulting  https://RelativeMotion.info
>> <https://relativemotion.info/>
>>
>>
>> On Mon, Sep 29, 2025 at 8:59 AM Michalis Kamburelis via x3d-public <
>> x3d-public at web3d.org> wrote:
>>
>>> 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
>>> <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
>>>
>>> _______________________________________________
>>> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250929/e2b967d8/attachment-0001.html>