[x3d-public] Depreciated HAnimHumanoid.joints field?
Don Brutzman
don.brutzman at gmail.com
Wed Oct 1 17:32:53 PDT 2025
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/7026c042/attachment-0001.html>
More information about the x3d-public
mailing list