[x3d-public] Depreciated HAnimHumanoid.joints field?

[John Carlson]

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
>
>
> 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/20250929/e1266f8a/attachment-0001.html>