[x3d-public] Depreciated HAnimHumanoid.joints field?
John Carlson
yottzumm at gmail.com
Wed Oct 1 16:55:22 PDT 2025
I believe an example can be created by converting .glTF humanoid to .x3d,
possibly using Holger’s x3d-tidy:
For example:
https://github.com/coderextreme/HAnimUtilityKit/blob/main/WalkingAlien.x3d
You’ll have to verify it visually.
Thanks,
John
On Wed, Oct 1, 2025 at 3:35 PM Don Brutzman via x3d-public <
x3d-public at web3d.org> wrote:
> Joe and I just reviewed discussion from last Monday, and came up with a
> further refinement to explicitly handle special cases (such as just a
> fewJoint nodes are needed for a minor jointBinding correction, or no Joint
> nodes are needed when the body is already in an I pose).
>
> - Humanoid *skeleton* trees may contain a large number of Joint nodes,
> but it might not be necessary to adjust every single Joint to achieve an I
> pose. If any of the *jointBindingPositions*, *jointBindingRotations*,
> and *jointBindingScales* fields are defined, then the *joints* field
> shall also be defined with the same indexing order, and each non-empty MF
> array shall have the same length as the *joints* array. Providing only
> one, two, or three of the *jointBindingPositions*,
> *jointBindingRotations*, and *jointBindingScales* fields is allowed.
> If none of those three fields is provided, then the *joints* field is
> not necessary.
>
> Updated online. Further scrutiny is always welcome.
>
> Next step: can we please have an example model for the shared archives?
> That should quickly settle any questions about implementation or
> semantics. Maybe that alien model, if open-source license?
>
> Very respectfully, Joe and Don
>
> all the best, Don
> --
> X3D Graphics, Maritime Robotics, Distributed Simulation
> Relative Motion Consulting https://RelativeMotion.info
>
>
> On Mon, Sep 29, 2025 at 4:40 PM Don Brutzman <don.brutzman at gmail.com>
> wrote:
>
>> Question in today's call: what if the number of joints that need
>> adjustment to match an I pose is actually far less than the entire
>> skeleton? For example, if only the fingers need adjustment, do we have to
>> define "zero" changes for all the other joints?
>>
>> Suggested response: the author has the option to only define the joints
>> of interest in the joints field... so it can be a limited subset of all the
>> joints. Fine tuning:
>>
>> - If any of the *jointBindingPositions*, *jointBindingRotations*, and
>> *jointBindingScales *fields are defined, then the *joints *field
>> shall also be defined with the same indexing order, and each MF array shall
>> have the same length as the *joints *array. Adjusting only one, two,
>> or three of the *jointBindingPositions*, *jointBindingRotations*,
>> and *jointBindingScales *fields is allowed.
>>
>> all the best, Don
>> --
>> X3D Graphics, Maritime Robotics, Distributed Simulation
>> Relative Motion Consulting https://RelativeMotion.info
>>
>>
>> On Mon, Sep 29, 2025 at 10:12 AM Don Brutzman <don.brutzman at gmail.com>
>> 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
>>>
>>>
>>> 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
>>>> >
>>>> >
>>>> >
>>>> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20251001/343cbb60/attachment-0001.html>
More information about the x3d-public
mailing list