[x3d-public] Mantis 1530: Avoiding exhaustive EXPORT statements within HAnimHumanoid skeleton

Mon Apr 27 10:11:33 PDT 2026

PS I already implemented an HAnimMotionInterpolator node type in freewrl
and have a working example. and doesn't rely on run-time generation of
routes - on each HAnimHumanoid draw, it goes down the (MFNode) list of
interpolators, matches to a corresponding (MFString) list of joint names,
and looks up the joint by name in the HAnimMotion, and applies the value.
A benefit (vs. direct routing to joints by DEF name): if you have different
skins for different level of detail, you can wrap multiple HAnimHumanoid in
an LOD node, and DEF/USE the same Motion or MotionInterpolator node -- no
re-routing or duplicating of routes.
Doesn't break old scenes which can still use joint DEF and routes.
Might help with the IMPORT EXPORT issue for new scenes.
-Doug

On Mon, Apr 27, 2026 at 9:43 AM Don Brutzman <don.brutzman at gmail.com> wrote:

> Thanks for looking at this.  Topic certainly requires careful thought.
>
> DEF identifiers are definitely needed for event ROUTEs, particularly for
> PositionInterpolator and OrientationInterpolator.  This is not something
> that can be removed without breaking legacy content and backwards
> compatibility.
>
> Writing a specialty node that does name lookup is an appealing concept.
> I'd suggest the following approach:
>
>    - X3D Script node that walks HAnimHumanoid tree(s) and creates ROUTE
>    connections at run time,
>    - inputs would be an input PositionInterpolator, an input MFNode array
>    of OrientationInterpolator nodes, and a target HAnimHumanoid,
>    - if single case works, can wrap it in a prototype definition and
>    re-use it as an external prototype,
>    - requires careful author testing, as ever, and
>    - requires javascript support at run time
>
> Interestingly, construction of such ROUTE connections might also be a
> modeling task for authoring environments such as X3D-Edit, X3DJSAIL in
> Java, X3DPSAIL x3d.py in Python, and other tools.
>
> HAnimMotion node is a completely different approach and requires different
> handling.  I'd like to build more examples (at some point) before
> considering alterations to that implementation pattern.  It seems prudent
> to avoid defining a new node until we have fully explored modeling and
> extensibility options with the current architectures.
>
> Have fun building HAnimHumanoid event graphs!  😁
>
> all the best, Don
> --
> X3D Graphics, Maritime Robotics, Distributed Simulation
> Relative Motion Consulting  https://RelativeMotion.info
>
>
> On Mon, Apr 27, 2026 at 5:00 AM GPU Group <gpugroup at gmail.com> wrote:
>
>> Q. does anyone need DEFs for joints?
>> - HAnimMotion nodes can lookup the name field
>> - when animating with interpolators, there can be a new node type
>> HAnimMotionInterpolator and the interpolators route to the
>> HAnimMotionInterpolator which can do the name lookup. like HAnimMotion node
>> does.
>> -Doug
>>
>> On Sun, Apr 26, 2026 at 10:49 PM Don Brutzman <don.brutzman at gmail.com>
>> wrote:
>>
>>> This is a request for X3D browser implementers.
>>>
>>> Joe and I are making good progress on building models that add
>>> additional bones/teeth/cartilage, providing a new LOA-5 for HAnim.  LOA-5
>>> keeps building on progressive Level of Articulation (LOA) 0..4 ranging from
>>> simple to sophisticated HAnim models.
>>>
>>> We will soon be able to test EXPORT and IMPORT of HAnimHumanoid models
>>> in full detail for use with multiple interpolator sets.  Our goal is to
>>> demonstrate simplified sharing and composition of HAnim models in X3D.
>>>
>>> A recent improvement to X3D4 v4.1 draft was to deprecate USE nodes at
>>> the top level of an HAnimHumanoid since they are superfluous, verbose, and
>>> potentially error prone if defined incorrectly.
>>>
>>> Based on current efforts, we'd like to recommend something similar.  If
>>> a HAnimHumanoid model is EXPORTed and then IMPORTed, the corresponding
>>> EXPORT and IMPORT of every contained joint, segment and site is similarly
>>> superfluous since such nodes are detectable automatically without
>>> ambiguity.  HAnim naming conventions for matching prefixed DEF labels with
>>> the corresponding name field in each given node are quite strict.  Thus
>>> manually redefining hundreds of predictable EXPORT and IMPORT statements
>>> for each re-use seems unnecessary.
>>>
>>> Thanks for considering this coding task.  It will have a notable
>>> improvement on authoring simplicity, humanoid portability and model
>>> robustness.
>>>
>>> The Mantis issue describing this proposal follows.
>>>
>>>    - Mantis 1530: Avoiding exhaustive EXPORT statements within
>>>    HAnimHumanoid skeleton
>>>    - https://mantis.web3d.org/view.php?id=1530
>>>
>>> Description Any HAnimHumanoid skeleton can have a lot of HAnimJoint and
>>> HAnimSegment and HAnimSite children. For LOA-5, it is hundreds of such
>>> children.
>>>
>>> These child nodes are always carefully identified, with pairwise DEF and
>>> name fields that match exactly according to HAnim requirements.
>>>
>>> If an X3D model with an HAnimHumanoid includes an EXPORT statement
>>> allowing re-use by other X3D scenes, then browsers need to automatically
>>> EXPORT all of the subordinate HAnim nodes.
>>>
>>> Similarly, if a HAnimHumanoid is IMPORTed for animation re-use in a
>>> different X3D scene, browsers need to automatically IMPORT all of the
>>> subordinate HAnim nodes.
>>> Additional Information Example:
>>> - X3D Example Archives: Humanoid Animation, Bones, All Bones LOA 5
>>> Skeletons
>>> -
>>> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Bones/AllBonesLOA5SkeletonsIndex.html
>>>
>>> see the EXPORT statements beginning at line 3286:
>>>
>>> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Bones/AllBonesLOA5Skeletons.html#3286
>>>
>>> 3286 <!-- right-side HAnimHumanoid -->
>>> 3287 <EXPORT localDEF='hanimMesh_AllBonesSkeleton'
>>> AS='AllBonesSkeletonMesh'/>
>>>
>>> 3288 <!-- left-side HAnimHumanoid -->
>>> 3289 <EXPORT localDEF='hanim_AllBonesSkeleton' AS='AllBonesSkeleton'/>
>>>
>>> 3290 <!-- propose eliminating requirement for EXPORT statements
>>> corresponding to child HAnimJoint HAnimSegment HAnimSite nodes, similar to
>>> removing requirement for definition of USE nodes for HAnimHumanoid children
>>> -->
>>>
>>> 3291 <EXPORT localDEF='hanim_c1' AS='AllBonesSkeletonMesh_hanim_c1'/>
>>> 3292 <EXPORT localDEF='hanim_c1disc'
>>> AS='AllBonesSkeletonMesh_hanim_c1disc'/>
>>> 3293 <EXPORT localDEF='hanim_c2' AS='AllBonesSkeletonMesh_hanim_c2'/>
>>> 3294 <EXPORT localDEF='hanim_c2disc'
>>> AS='AllBonesSkeletonMesh_hanim_c2disc'/>
>>> (etc. etc. approximately 400 EXPORT statements follow which exactly
>>> match the skeleton example)
>>> Tags  HAnim v2.1,  ,X3D v4.1
>>> Attach Tags (Separate by ",")    Existing tags1356apacheCD Ballot
>>> commentDocument styleExamplesfileHTML5JSONMantisMetaverseSAISchema
>>> securityserverspamuploadV3.3 CommentV4.0V4.0 ResolutionValidationWebsite
>>> WebXRX3DUOM
>>>  Activities
>>> <https://mantis.web3d.org/view.php?id=1530#>
>>>
>>>  brutzman <https://mantis.web3d.org/view_user_page.php?id=10>
>>>
>>>  2026-04-23 10:55
>>>
>>> administrator    ~0003889
>>> <https://mantis.web3d.org/view.php?id=1530#c3889>
>>> This issue is similar to the USE nodes in HAnimHumanoid - duplication by
>>> authors is tedious, error prone, and a superfluous task that a browser can s
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Have fun with HAnim and X3D! 😁
>>>
>>> all the best, Don
>>> --
>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>> Relative Motion Consulting  https://RelativeMotion.info
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20260427/f4080a15/attachment-0001.html>