[x3d-public] No Transform/Group/Shape inside HAnimJoint?

Fri Sep 12 08:34:37 PDT 2025

If you look at my original post, you will see

HAnimJoint : X3DGroupingNode {
  MFNode     [in]     addChildren               [HAnimJoint,HAnimSegment]
  MFNode     [in]     removeChildren            [HAnimJoint,HAnimSegment]
  SFVec3f    [in,out] center           0 0 0    (-∞,∞)`
  MFNode     [in,out] children         []       [HAnimJoint,HAnimSegment]
  SFString   [in,out] description      ""
  MFNode     [in,out] displacers       []       [HAnimDisplacer]

At the bottom, see displacers, so HAnimDisplacer can be under HAnimJoint,
just not in the children field.

Hope this clears things up.

John

On Fri, Sep 12, 2025 at 1:18 AM Don Brutzman <don.brutzman at gmail.com> wrote:

> Joe, let's refer back to the specification.  John helpfully colorized an
> excerpt earlier; let's review how the spec works.  Quote:
>
> HAnimJoint : X3DGroupingNode {
>> MFNode [in] addChildren [HAnimJoint,HAnimSegment]
>> MFNode [in] removeChildren [HAnimJoint,HAnimSegment]
>> SFVec3f [in,out] center 0 0 0 (-∞,∞)`
>> MFNode [in,out] children [] [HAnimJoint,HAnimSegment]
>
>
> This means that a HAnimJoint is itself an X3DGrouping node, but the
> limitation brackets mean that the *children* field can only contain an
> HAnimSegment or another HAnimJoint.  Thus HAnimJoint cannot contain
> HAnimDisplacer.
>
> Paddling upstream to look at the HAnim 2 definitions, that looks to be
> consistent with the Joint definition: no Displacer node seen there.
>
>    -
>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/concepts.html#JointObject
>
> So the two specifications (HAnim primary, X3D secondary, both
> authoritative) look consistent to me.
>
> Important: please check that logic in the specification prose sections
> yourselves.
>
> Therefore HAnimJoint should have no other children besides HAnimSegment
> and/or another HAnimJoint.  Joe, that does not match your list of
> acceptable children... we have to be really careful about these things.
>
> btw thanks John for noting that X3DJSail documentation shows it is
> inconsistent with that restriction.  I'll work on that sometime in the
> future.
>
> p.s. I think our prior SourceForge tickets have gotten scrambled on this
> topic, we probably need to start a separate one.
>
> all the best, Don
>
> On Fri, Sep 12, 2025 at 3:31 AM Joe D Williams <joedwil at earthlink.net>
> wrote:
>
>> > HAnimJoint.
>>
>> The acceptable children for Joint in Basic skeleton are
>> Displacer (for Segment geometry), Joint, Segment.
>> Segment children=any x3d and Site .
>> Site children=any x3d.
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Extensible 3D (X3D) Graphics public discussion <
>> x3d-public at web3d.org></x3d-public at web3d.org>
>> Sent: Sep 9, 2025 3:50 AM
>> To: John Carlson <yottzumm at gmail.com></yottzumm at gmail.com>
>> Cc: Don Brutzman <don.brutzman at gmail.com>, <hanim at web3d.org>, Extensible
>> 3D (X3D) Graphics public discussion <x3d-public at web3d.org></
>> x3d-public at web3d.org></hanim at web3d.org></don.brutzman at gmail.com>
>> Subject: Re: [x3d-public] No Transform/Group/Shape inside HAnimJoint?
>>
>> Hi John. Option 3 please. Recommend fixing the example models, not
>> deleting the example models. The X3D specification implementation of the
>> HAnim specification, both of which are authoritative, clearly shows that
>> Transform/Group/Shape child nodes belong under HAnimSegment, not under
>> HAnimJoint. * 26.3.5 HAnimSegment*
>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment
>>
>> No doubt the errors you have reported here are already detected and
>> reported repeatedly by X3D XML Schema,X3D DOCTYPE, and X3D Schematron.
>> Periodic unit testing logs capture such errors, X3D-Edit can check
>> validation comprehensively as well Proper validation and correction of
>> models prevents Garbage In Garbage Out (GIGO) syndrome.
>>
>> Incidentally, a large number of people have worked long + hard for years
>> to implement both specifications. There is no need to worry about
>> “fixing” the authoritative HAnim and X3D specifications unless
>> you have a valid example demonstrating why such a change is needed. Have
>> fun with valid X3D models! 🥸👌 all the best, Don
>> --
>> Don Brutzman
>> X3D graphics, virtual worlds, Navy robotics
>> https://faculty.nps.edu/brutzman
>> On Mon, Sep 8, 2025 at 8:36 PM John Carlson via x3d-public <
>> x3d-public at web3d.org (mailto:x3d-public at web3d.org)=""> wrote:I suggest
>> we either deep six examples with Transform/Group/Shape children of
>> HAnimJoint, or fix the standard. Here's the standard I am referring to:
>> HAnimJoint : X3DGroupingNode { MFNode [in] addChildren
>> [HAnimJoint,HAnimSegment] MFNode [in] removeChildren
>> [HAnimJoint,HAnimSegment] SFVec3f [in,out] center 0 0 0 (-∞,∞)`
>> MFNode [in,out] children [] [HAnimJoint,HAnimSegment] SFString [in,out]
>> description "" MFNode [in,out] displacers [] [HAnimDisplacer] SFBool
>> [in,out] bboxDisplay FALSE SFRotation [in,out] limitOrientation 0 0 1 0
>> [-1,1] or (-∞,∞) MFFloat [in,out] llimit [0 0 0]
>> (-∞,∞) SFNode [in,out] metadata NULL [X3DMetadataObject]
>> SFString [in,out] name "" SFRotation [in,out] rotation 0 0 1 0 [-1,1] or
>> (-∞,∞) SFVec3f [in,out] scale 1 1 1 (0,∞) SFRotation
>> [in,out] scaleOrientation 0 0 1 0 [-1,1] or (-∞,∞) MFInt32
>> [in,out] skinCoordIndex [] [0,∞) MFFloat [in,out] skinCoordWeight []
>> [0,1] MFFloat [in,out] stiffness [0 0 0] [0,1] SFVec3f [in,out] translation
>> 0 0 0 (-∞,∞) MFFloat [in,out] ulimit [0 0 0] (-∞,∞)
>> SFBool [in,out] visible TRUE SFVec3f [] bboxCenter 0 0 0 (-∞,∞)
>> SFVec3f [] bboxSize -1 -1 -1 [0,∞) or −1 −1 −1}See
>> examples in the archive, e.g.:Humanoid Animation X3D Examples Archive,
>> Winter And Spring, Lily Animated ()Humanoid Animation X3D Examples Archive,
>> Winter And Spring, Leif Animated (
>> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/WinterAndSpring/LeifAnimatedIndex.html
>> (
>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimJoint))Humanoid
>> Animation X3D Examples Archive, Winter And Spring, Tufani Animated ()If
>> HAnimJoint IS a X3DGroupingNode, then X3DChildNodes should be acceptable.
>> Is that how to read the standard?
>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/grouping.html#X3DGroupingNode10.3.2
>> (
>> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/WinterAndSpring/TufaniAnimatedIndex.html)
>> X3DGroupingNodeX3DGroupingNode : X3DChildNode, X3DBoundedObject { MFNode
>> [in] addChildren [X3DChildNode] MFNode [in] removeChildren [X3DChildNode]
>> MFNode [in,out] children [] [X3DChildNode] SFBool [in,out] bboxDisplay
>> FALSE SFNode [in,out] metadata NULL [X3DMetadataObject] SFBool [in,out]
>> visible TRUE SFVec3f [] bboxCenter 0 0 0 (-∞,∞) SFVec3f []
>> bboxSize -1 -1 -1 [0,∞) or −1 −1 −1}Anyway, that
>> seems *REALLY* confusing! Any clarification on "overloading" of fields
>> welcome! Thanks, John_______________________________________________</
>> x3d-public at web3d.org>
>> x3d-public mailing list
>> x3d-public at web3d.org (mailto: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/20250912/15f5e7d4/attachment.html>