[x3d-public] Depreciated HAnimHumanoid.joints field?
John Carlson
yottzumm at gmail.com
Wed Oct 1 18:15:29 PDT 2025
Understood. I can send you the original .glTF that i have, I think Holger
posted it originally.
Here’s my copy:
https://github.com/coderextreme/HAnimUtilityKit/blob/main/WalkingAlien.gltf
If you go through the email archives, you might find the original.
Joe originally had me work with it, I was kind of reluctant. If I need to
delete my copy, please let me know.
Apologies if I cause any distress. The recommendation is to start with
open source .glTF and convert with x3d-tidy as previously mentioned.
If anyone is opposed to me working with their models, please let me know. A
quick note is great!
John
On Wed, Oct 1, 2025 at 7:33 PM Don Brutzman <don.brutzman at gmail.com> wrote:
> Thanks John. Any example is helpful, but we need to know that this model
> is open source (Web3D license or other license) before we can add it to the
> X3D Examples Archive.
>
> all the best, Don
> --
> X3D Graphics, Maritime Robotics, Distributed Simulation
> Relative Motion Consulting https://RelativeMotion.info
>
>
> On Wed, Oct 1, 2025 at 4:55 PM John Carlson <yottzumm at gmail.com> wrote:
>
>> 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/db2506e5/attachment-0001.html>
More information about the x3d-public
mailing list