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

Mon Apr 27 10:12:49 PDT 2026

" looks up the joint by name in the HAnimMotion" should read " looks up the
joint by name in the HAnimHumanoid"
-Doug

On Mon, Apr 27, 2026 at 11:11 AM GPU Group <gpugroup at gmail.com> wrote:

> 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 ResolutionValidation
>>>> WebsiteWebXRX3DUOM
>>>>  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/9db903c3/attachment-0001.html>