<div dir="auto">I do hope we are also considering joint additions, subtractions and reordering during animation.</div><div dir="auto"><br></div><div dir="auto">Thanks!</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Sep 29, 2025 at 12:13 PM Don Brutzman via x3d-public <<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>Next, what an interesting discussion! Here are some additional thoughts building on these points.</div><div><br></div><div>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:</div><div><ul><li>X3D Compressed binary encoding (CBE) draft 4.0, clause 4 Concepts, 4.2.3 X3D canonical form</li><li><a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-3v4.0-WD1/Part03/concepts.html#X3DCanonicalForm" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-3v4.0-WD1/Part03/concepts.html#X3DCanonicalForm</a></li></ul></div><div>Regardless of whether Humanoid/HAnimHumanoid includes an MFNode <i>joints </i>field of USE nodes, the ordering must match the <span style="font-style:italic;color:rgb(0,0,0);font-size:11.05px">jointBindingPositions, </span><span style="font-style:italic;color:rgb(0,0,0);font-size:11.05px">jointBindingRotations, </span><font color="#000000"><i style="font-size:11.05px">jointBindin</i><i style="font-size:11.05px">gRotations </i>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 </font>HAnimHumanoid.joints array by itself would likely change index order and break the accompanying binding values.</div><div><font color="#000000"><br></font></div><div><div><font color="#000000">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 i</font><span style="color:rgb(0,0,0)">f we were to define a typical or canonical ordering, it might be</span></div></div><div><ul><li><font color="#000000">breadth-first search (BFS) or depth-first search (DFS) "walking the tree"</font></li><li><font color="#000000">order of appearance in a file (though that might change when an application loads the skeleton)</font></li><li><font color="#000000">or, simply not worry about such ordering since each USE node uniquely points to an HAnimJoint node which includes a unique <i>name </i>field. Having unique <i>name</i> 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.</font></li></ul><div><span style="color:rgb(0,0,0)">Thus it would seem like an explicit definition for HAnim canonical form might be useful someday in the future, but only if </span><span style="color:rgb(0,0,0);font-size:11.05px;font-style:italic">jointBindingPositions</span><span style="color:rgb(0,0,0)"> etc. are </span><span style="color:rgb(0,0,0)">not</span><span style="color:rgb(0,0,0)"> </span><span style="color:rgb(0,0,0)">defined.</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">Meanwhile, still not hearing any current (or future) rationale why </span><span style="color:rgb(0,0,0)">HAnimHumanoid.segments and </span><span style="color:rgb(0,0,0)">HAnimHumanoid.sites need to be retained instead of deprecated. Similarly not seeing any functionality for these duplicative fields... all thoughts welcome.</span></div></div><div><br></div><div>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 <span style="color:rgb(0,0,0)">HAnimHumanoid</span>.joints deprecation and add the following requirement to <span style="background-color:rgb(255,255,0)"><span style="color:rgb(0,0,0)">HAnimHumanoid in</span> HAnim v2.1 draft.</span></div><ul><li><span style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;background-color:rgb(255,255,0)">If any of the <i>jointBindingPositions</i>, <i>jointBindingRotations</i>, and <i>jointBindingScales </i>fields are defined, then the </span><i style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;background-color:rgb(255,255,0)">joints </i><span style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;background-color:rgb(255,255,0)">field must also be defined with the same indexing order, and each MF array must have the same length.</span></li></ul><div><font color="#000000" face="Verdana, Arial, Helvetica, sans-serif">Have fun with HAnim! <font size="6">🧍</font></font></div></div><div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(34,34,34)"><font face="monospace"><br></font></div><div style="color:rgb(34,34,34)"><font face="monospace">all the best, Don</font></div><div style="color:rgb(34,34,34)"><font face="monospace">-- </font></div><div style="color:rgb(34,34,34)"><font face="monospace">X3D Graphics, Maritime Robotics, Distributed Simulation</font></div><div style="color:rgb(34,34,34)"><font face="monospace">Relative Motion Consulting <a href="https://RelativeMotion.info" target="_blank">https://RelativeMotion.info</a></font></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 29, 2025 at 8:59 AM Michalis Kamburelis via x3d-public <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">John: Indeed, we'd need to clarify in spec how the joints order is to<br>
be determined by the implementation, e.g. depth-first. I know that<br>
depth-first may be kind of obvious... but it's important to be precise<br>
here :)<br>
<br>
Aaron:<br>
<br>
- As for file size: For most "pretty / real-life" 3D models that I<br>
have, the file size is determined mostly by the per-vertex data<br>
(indexes, positions), because there's a zillion of vertexes :), so<br>
size of most other things becomes "almost ignorable" when looking at<br>
the file size. Oh, and also embedded images / audio, like using data<br>
URI or PixelTexture, can eat size significantly. So I would not<br>
suspect much size gain from removing things like "joints list"... OK,<br>
but I can be wrong, testcases showing the gain (before and after<br>
removing these fields) would be welcome to back up this.<br>
<br>
- As for incorrect browsers duplicating geometry -- this seems an<br>
independent problem IMHO that should be addressed in these browsers.<br>
In general, in X3D, one is not supposed to "render all children nodes<br>
in all MFNode lists", browsers should have a code to render e.g.<br>
"HAnimHumanoid.skeleton", "HAnimHumanoid.skin" but not<br>
"HAnimHumanoid.joints" . This is the relevant code in CGE, that<br>
accounts for both H-Anim 1.0 and 2.0:<br>
<a href="https://github.com/castle-engine/castle-engine/blob/aa61bfff4593943842ad73f492e9e4d96993d882/src/scene/x3d/x3dnodes_standard_h-anim.inc#L294" rel="noreferrer" target="_blank">https://github.com/castle-engine/castle-engine/blob/aa61bfff4593943842ad73f492e9e4d96993d882/src/scene/x3d/x3dnodes_standard_h-anim.inc#L294</a><br>
. Other X3D nodes also have special rules, like Switch or LOD, of<br>
"where to enter".<br>
<br>
Thank you both for answers. I understand the reasons better... but<br>
admittedly I still think that we don't gain much, and we introduce<br>
potential source of problems (if implementations will deduce different<br>
number of joints, crazy things will happen).<br>
<br>
And looking at others, like glTF, they don't do this, i.e. they just<br>
have explicit list of joints. Collada is like glTF in this regard too,<br>
they have <joints> in <skin>.<br>
<br>
Regards,<br>
Michalis<br>
<br>
<br>
<br>
pon., 29 wrz 2025 o 16:54 Bergstrom, Aaron via x3d-public<br>
<<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>> napisał(a):<br>
><br>
> Everyone,<br>
><br>
><br>
><br>
> The way I remember the discussion from last week, the reasoning behind deprecating these fields was as follows:<br>
><br>
> Reduction in file sizes<br>
> 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<br>
><br>
><br>
><br>
> 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.<br>
><br>
><br>
><br>
> Aaron<br>
><br>
><br>
><br>
> From: x3d-public <<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@web3d.org</a>> On Behalf Of John Carlson via x3d-public<br>
> Sent: Monday, September 29, 2025 3:34 AM<br>
> To: Extensible 3D (X3D) Graphics public discussion <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
> Cc: John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>>; Humanoid Animation (H-Anim) Working Group <<a href="mailto:h-anim@web3d.org" target="_blank">h-anim@web3d.org</a>><br>
> Subject: Re: [x3d-public] Depreciated HAnimHumanoid.joints field?<br>
><br>
><br>
><br>
> 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.<br>
><br>
> On Sun, Sep 28, 2025 at 11:00 PM Joe D Williams via x3d-public <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>> wrote:<br>
><br>
> > Modelling of non-human HAnim figures<br>
><br>
> .jointBindingPositions<br>
><br>
><br>
><br>
> jointBindingRotations<br>
><br>
> jointBindingScales<br>
><br>
><br>
><br>
> No need for "joints" field at all, then, just define that the order of data in<br>
><br>
> these fields must be the same as the order of appearance in the skeleton field.<br>
><br>
> WaaLaa, we are rid of joints, segments, sites.<br>
><br>
><br>
><br>
> Anyway, if really needed, which it is not, then the only need is for<br>
><br>
> the Name='string' that is the list of names, consisting of an MFstring<br>
><br>
> field instead oft that cumbersome and misused MFNode field definition.<br>
><br>
> Again, the HAnim naming conventions are strict enough to find the<br>
><br>
> Joint DEF names by Humanoid name and Joint name<br>
><br>
><br>
><br>
> Probably the Best idea is to include spec for metadata that includes<br>
><br>
> joint, segment, site names, maybe as well as other interface names.<br>
><br>
> One day when the AIxHumanoid takes over then all it will need is the<br>
><br>
> metadata anyway.<br>
><br>
><br>
><br>
> All Goood,<br>
><br>
> Joe<br>
><br>
><br>
><br>
><br>
><br>
> -----Original Message-----<br>
> From: Extensible 3D (X3D) Graphics public discussion <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
> Sent: Sep 27, 2025 5:09 PM<br>
> To: Holger Seelig <<a href="mailto:holger.seelig@yahoo.de" target="_blank">holger.seelig@yahoo.de</a>><br>
> Cc: Don Brutzman <<a href="mailto:don.brutzman@gmail.com" target="_blank">don.brutzman@gmail.com</a>>, Extensible 3D (X3D) Graphics public discussion <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>>, Humanoid Animation (H-Anim) Working Group <<a href="mailto:h-anim@web3d.org" target="_blank">h-anim@web3d.org</a>><br>
> Subject: Re: [x3d-public] Depreciated HAnimHumanoid.joints field?<br>
><br>
><br>
><br>
> [added hanim mailing list]<br>
><br>
><br>
><br>
> 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).<br>
><br>
><br>
><br>
> Thanks for your insightful observation, no one else caught that relationship. The primary reference, with relevant excerpts so far, is<br>
><br>
> Humanoid animation (HAnim) architecture v2.1 draft, part 1, clause 6 Object interfaces, 6.1 Humanoid<br>
> <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/ObjectInterfaces.html#Humanoid" rel="noreferrer" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/ObjectInterfaces.html#Humanoid</a><br>
> The joints, segments, and sites fields are deprecated since they are duplicative and redundant.<br>
> [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]<br>
><br>
> 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.<br>
><br>
><br>
><br>
> Looks like the specification does include prose for the dependency you are defining:<br>
><br>
> 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.<br>
><br>
> jointBindingPositions<br>
> jointBindingRotations<br>
> jointBindingScales<br>
> skinBindingCoords<br>
> skinBindingNormals<br>
><br>
> None of these five fields shall be used in a model that has a skeletalConfiguration value of "BASIC".<br>
> 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.<br>
><br>
> Suggested path forward:<br>
><br>
> remove the deprecation for the joints field, it is not appropriate<br>
> Relax the dependency on redundant/superfluous definitions for joint, segment and site MFNode arrays of USE nodes with prose along the lines of:<br>
> 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.<br>
> Add corresponding rule in X3D Schematron to check for this relationship, also update X3D Tooltips.<br>
> Ensure that corresponding field definitions in X3D 4.1 draft for HAnimHumanoid continue to match.<br>
> Improvements are always welcome.<br>
><br>
> 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).<br>
><br>
><br>
><br>
> 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.<br>
><br>
> Wiktionary, deprecate<br>
> <a href="https://en.wiktionary.org/wiki/deprecate" rel="noreferrer" target="_blank">https://en.wiktionary.org/wiki/deprecate</a><br>
><br>
> 3. (transitive, chiefly computing) To declare something obsolescent; to recommend against a function, technique, command, etc. that still works but has been replaced.<br>
><br>
> The 'bold' tag has been deprecated in favour of the 'strong' tag.<br>
><br>
> It is still supported but strongly deprecated.<br>
><br>
> We will review this issue next Monday afternoon during HAnim specification editing session.<br>
><br>
><br>
><br>
> Again thanks for your implementation and evaluation efforts and insights.<br>
><br>
><br>
><br>
> all the best, Don<br>
><br>
> --<br>
><br>
> X3D Graphics, Maritime Robotics, Distributed Simulation<br>
><br>
> Relative Motion Consulting <a href="https://RelativeMotion.info" rel="noreferrer" target="_blank">https://RelativeMotion.info</a><br>
><br>
><br>
><br>
> On Sat, Sep 27, 2025 at 12:33 PM Holger Seelig via x3d-public <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>> wrote:<br>
><br>
> 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.<br>
><br>
><br>
><br>
> The first value should belong to the first joint in the joints fields and so on.<br>
><br>
><br>
><br>
> 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.<br>
><br>
><br>
><br>
> <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/hanim.html#HAnimHumanoid" rel="noreferrer" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/hanim.html#HAnimHumanoid</a><br>
><br>
><br>
><br>
> Best regards,<br>
><br>
> Holger<br>
><br>
><br>
><br>
> —<br>
> Holger Seelig<br>
> Leipzig, Germany<br>
><br>
> <a href="mailto:holger.seelig@yahoo.de" target="_blank">holger.seelig@yahoo.de</a><br>
> <a href="https://create3000.github.io/x_ite/" rel="noreferrer" target="_blank">https://create3000.github.io/x_ite/</a><br>
> <a href="https://patreon.com/X_ITE" rel="noreferrer" target="_blank">https://patreon.com/X_ITE</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
><br>
> _______________________________________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div>