[x3d-public] allowing full capabilities for X3D node reuse with Inline EXPORT/IMPORT AS/USE
Don Brutzman
don.brutzman at gmail.com
Sat Oct 11 17:41:57 PDT 2025
Thanks once again. I did take another approach this morning, and
everything sorted out well today.
Found this documentation useful too:
- Direct scene manipulations with Javascript
- Author(s): Michael Zoellner, Date: 2009-01-01
- Summary: This tutorial shows you how to create, manipulate, add and
remove nodes via Javascript
-
https://doc.instantreality.org/tutorial/direct-scene-manipulations-with-javascript
Have successfully tested first two poses and the resetJoints function
also. I think HAnimPose will be a useful and interesting node. Adding the
ability to IMPORT/USE large HAnimHumanoid skeletons will be further
powerful.
- Humanoid Animation X3D Examples Archive, Pose, HAnim Pose Prototype
<https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Pose/HAnimPosePrototypeIndex.html>
-
https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Pose/HAnimPosePrototypeIndex.html
- (Playground
<https://create3000.github.io/x_ite/playground/?url=https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Pose/HAnimPosePrototype.x3d>
)
-
https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Pose/HAnimPosePrototype.console.txt
Again thanks for Sunrize on Windows, really powerful. Having fun with X3D
and HAnim! 😀👌
all the best, Don
--
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting https://RelativeMotion.info
On Sat, Oct 11, 2025 at 1:08 PM Holger Seelig <holger.seelig at yahoo.de>
wrote:
> What I can say to add/removeRootNode, both of these function are only
> available in a X3DScene. Within a X3DPrototypeInstance there are no such
> function, because editing of the root nodes is not allowed (by the spec),
> there is only a X3DExecutionContext accessible via Browser.currentScene.
>
> But it is possible to have a root node to be a Group or whatever,
> reference this node in a Script and fill the children of this node with
> content, possible other nodes.
>
> Best regards,
> Holger
>
> —
> Holger Seelig
> holger.seelig at yahoo.de
>
>
> Am 11.10.2025 um 09:51 schrieb Don Brutzman <don.brutzman at gmail.com>:
>
> Thanks for catching that Holger. That was a big help.
>
> Have made much progress, now walking the entire HAnimHumanoid tree and
> finding matches with poses, setting up clock and OrientationInterpolator
> connections, etc.
>
> A productive setup that is working well for me:
>
> - X3D-Edit for separately eding .x3d file and .js script, providing
> independent error checking and hints/warnings/errors for each,
> - Sunrize to test via Reload, checking console, taking small steps for
> changes
>
> Got through a bunch of Javascript difficulties due to unfamiliarity on my
> part. Still blocked by
> one, Browser.currentScene.addRootNode(someCreatedNode) is failing at run
> time.
>
> - X3D Example Archives: Humanoid Animation, Pose, HAnim Pose Prototype
> -
> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Pose/HAnimPosePrototypeIndex.html
> -
> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Pose/HAnimPosePrototype.x3d
> -
> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Pose/HAnimPosePrototypeScript.js
> -
> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Pose/HAnimPosePrototype.console.txt
>
> all the best, Don
> --
> X3D Graphics, Maritime Robotics, Distributed Simulation
> Relative Motion Consulting https://RelativeMotion.info
> <https://relativemotion.info/>
>
>
> On Fri, Oct 10, 2025 at 4:58 AM Holger Seelig <holger.seelig at yahoo.de>
> wrote:
>
>> If found at least one mistake. You access parentHAnimHumanoid.skeleton
>> and use it as if it is a SFNode but HAnimHumanoid.skeleton is of type
>> MFNode.
>>
>> Best regards,
>> Holger
>>
>> —
>> Holger Seelig
>> holger.seelig at yahoo.de
>>
>>
>> Am 09.10.2025 um 23:14 schrieb Don Brutzman <don.brutzman at gmail.com>:
>>
>> Wow this is great Holger, thanks for sharing that excellent example. I
>> think this will really provide a big step up for our HAnim development work.
>>
>> When you are ready, I am keen to test it out with Windows installer for
>> sunrize, that has really accelerated and improved my ability to write &
>> debug javascript inside a ProtoDeclare.
>>
>> Meanwhile, the prototype implementation for HAnimPosePrototype.x3d that
>> I've been working on is coming along, but I am running into problems
>> "walking the tree" of an HAnimHumanoid because I am not able to access
>> fields properly. Many times when I try to dereference a node to get its
>> name, am getting 'undefined' as a result. Much online search and a few
>> variations didn't help, so there are likely some basic mistakes occurring.
>>
>> This is probably due to an incorrect understanding on my part. Please
>> don't feel like I am asking you to debug it, but you (or someone else on
>> the list) might see poor JavaScript invocations that are preventing the
>> source from working. Link follow to latest version and trace statements on
>> console log. As might be expected, results are consistent between my local
>> Sunrize and online Playground and online X_ITE.
>>
>> - X3D Example Archives: Humanoid Animation, Pose, HAnim Pose Prototype
>> - Define an experimental new node to simply capture a single pose for
>> an HAnimHumanoid model. Expected usage is to allow HAnimHumanoid to contain
>> multiple Pose nodes which can be activated and composed.
>> - (scroll down bottom pane to see ecmascript: source contained in
>> Script inside the model)
>> -
>> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Pose/HAnimPosePrototypeIndex.html
>>
>> -
>> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Pose/HAnimPosePrototype.x3d
>>
>> (This version is loading an Inline copy of JinLOA2 Humanoid so everything
>> is right there, and there are no possible EXPORT/IMPORT complications for
>> that Humanoid.)
>>
>> ---------------------
>> found Pose FaceLeft, enabled=true, traceEnabled=true
>> [HAnimPoseScript : initializing Pose FaceLeft]
>> [HAnimPoseScript : loa=0 description=Only modify humanoid_root Joint node
>> to face left]
>> [HAnimPoseScript : numberPoseJoints= 2]
>>
>> // the following is an expected diagnostic that is working correctly
>>
>> [HAnimPoseScript : *** [error] node type mismatch,
>> poseJoints[1]=HAnimSegment { } name=specialTestCase (should be HAnimJoint,
>> ignored)]
>> [HAnimPoseScript : outputVrmlString=
>> DEF OI_humanoid_root OrientationInterpolator { key [0, 1] keyValue [0 1 0
>> 0, 0 1 0 0] }
>> # ROUTE HAnimPoseClock.fraction_changed TO OI_humanoid_root.set_fraction
>> ]
>> [HAnimPoseScript : jointOrientationInterpolators.length=1 # size is
>> correct]
>> [HAnimPoseScript : jointOrientationInterpolators.toString()=
>> OrientationInterpolator { } ### TODO missing fields]
>> [HAnimPoseScript : jointOrientationInterpolators JSON.stringify=
>> {"0":{"metadata":null,"key":{"0":0,"1":1},"keyValue":{"0":{},"1":{}},"value_changed":{}}}
>> ### TODO partial fields]
>> [HAnimPoseScript : countPoseJoints() complete]
>> [HAnimPoseScript : starting countHumanoidSkeletonJoints()]
>> [HAnimPoseScript : parentHAnimHumanoid.name=JinLOA2=JinLOA2]
>> skeletonNode=HAnimJoint { }, name=undefined (console.log)
>> [HAnimPoseScript : skeletonNode=HAnimJoint { }, name=undefined]
>> [HAnimPoseScript : *** TODO why is skeletonNode.name not
>> retrievable/referencable?]
>> [HAnimPoseScript : parentHAnimHumanoid.skeleton=HAnimJoint { }
>> name=undefined]
>> [HAnimPoseScript : parentHAnimHumanoid.skeleton.length=1]
>> [HAnimPoseScript : invoking countChildJointsRecurse() to walk the tree...]
>> [HAnimPoseScript : *** recursion trace: nextNode=HAnimJoint { },
>> nextNode.name=undefined, nextNodeObject=HAnimJoint { },
>> nextNodeObject.name=undefined]
>> [HAnimPoseScript : *** TODO error, parameter nextNode appears to lose
>> fields and perhaps context when passed into next method]
>> [HAnimPoseScript : recursion found HAnimJoint { } name=undefined with
>> counter=1]
>> [HAnimPoseScript : HAnimJoint name=undefined has no children,
>> backtracking...]
>> [HAnimPoseScript : found numberSkeletonJoints=1 total]
>> [HAnimPoseScript : Pose FaceLeft initialization() complete]
>> ---------------------
>> found Pose A, enabled=true, traceEnabled=true
>> [HAnimPoseScript : initializing Pose A]
>> [HAnimPoseScript : loa=1 description=experimental pose]
>> [HAnimPoseScript : numberPoseJoints= 2]
>> [HAnimPoseScript : outputVrmlString=
>> DEF OI_l_shoulder OrientationInterpolator { key [0, 1] keyValue [0 1 0 0,
>> 0 1 0 0] }
>> # ROUTE HAnimPoseClock.fraction_changed TO OI_l_shoulder.set_fraction
>> DEF OI_r_shoulder OrientationInterpolator { key [0, 1] keyValue [0 1 0 0,
>> 0 1 0 0] }
>> # ROUTE HAnimPoseClock.fraction_changed TO OI_r_shoulder.set_fraction
>> ]
>> [HAnimPoseScript : jointOrientationInterpolators.length=2 # size is
>> correct]
>> [HAnimPoseScript : jointOrientationInterpolators.toString()=
>> [
>> OrientationInterpolator { }
>> OrientationInterpolator { }
>> ] ### TODO missing fields]
>> [HAnimPoseScript : jointOrientationInterpolators JSON.stringify=
>> {"0":{"metadata":null,"key":{"0":0,"1":1},"keyValue":{"0":{},"1":{}},"value_changed":{}},"1":{"metadata":null,"key":{"0":0,"1":1},"keyValue":{"0":{},"1":{}},"value_changed":{}}}
>> ### TODO partial fields]
>> [HAnimPoseScript : countPoseJoints() complete]
>> [HAnimPoseScript : starting countHumanoidSkeletonJoints()]
>> [HAnimPoseScript : parentHAnimHumanoid.name=JinLOA2=JinLOA2]
>> skeletonNode=HAnimJoint { }, name=undefined (console.log)
>> [HAnimPoseScript : skeletonNode=HAnimJoint { }, name=undefined]
>> [HAnimPoseScript : *** TODO why is skeletonNode.name not
>> retrievable/referencable?]
>> [HAnimPoseScript : parentHAnimHumanoid.skeleton=HAnimJoint { }
>> name=undefined]
>> [HAnimPoseScript : parentHAnimHumanoid.skeleton.length=1]
>> [HAnimPoseScript : invoking countChildJointsRecurse() to walk the tree...]
>> [HAnimPoseScript : *** recursion trace: nextNode=HAnimJoint { },
>> nextNode.name=undefined, nextNodeObject=HAnimJoint { },
>> nextNodeObject.name=undefined]
>> [HAnimPoseScript : *** TODO error, parameter nextNode appears to lose
>> fields and perhaps context when passed into next method]
>> [HAnimPoseScript : recursion found HAnimJoint { } name=undefined with
>> counter=1]
>> [HAnimPoseScript : HAnimJoint name=undefined has no children,
>> backtracking...]
>> [HAnimPoseScript : found numberSkeletonJoints=1 total]
>> [HAnimPoseScript : Pose A initialization() complete]
>> ---------------------
>> found Pose T, enabled=false, traceEnabled=false
>> ---------------------
>> found Pose H, enabled=false, traceEnabled=false
>> ---------------------
>> found Pose I, enabled=false, traceEnabled=false
>>
>>
>> Perhaps there is an example somewhere that can help, but I didn't find
>> it. Goal for now is to fully traverse an HAnimHumanoid tree, noting all
>> HAnimJoint nodes and their names.
>>
>> Am running out of things to try... other eyes may do better than mine.
>> TIA for all scrutiny.
>>
>> all the best, Don
>> --
>> X3D Graphics, Maritime Robotics, Distributed Simulation
>> Relative Motion Consulting https://RelativeMotion.info
>> <https://relativemotion.info/>
>>
>>
>> On Thu, Oct 9, 2025 at 1:01 PM Holger Seelig <holger.seelig at yahoo.de>
>> wrote:
>>
>>> I have made an experimental implementation of this new feature. You can
>>> already use and play with it in the special preview playground:
>>>
>>>
>>> https://create3000.github.io/preview/playground/?url=https://create3000.github.io/Library/Tests/Components/Core/use-exported-node.x3dv
>>>
>>> This scene loads an inline file which exports a single green cube. This
>>> cube is imported into the scene and used a second time.
>>>
>>> There is also a experimental feature ‚USE before DEF‘ enabled in this
>>> preview playground. This feature seems important for me to get this all
>>> work in all cases.
>>>
>>> Best regards,
>>> Holger
>>>
>>> —
>>> Holger Seelig
>>> Leipzig, Germany
>>>
>>> holger.seelig at yahoo.de
>>> https://create3000.github.io/x_ite/
>>> https://patreon.com/X_ITE
>>>
>>>
>>>
>>> Am 09.10.2025 um 18:51 schrieb Don Brutzman via x3d-public <
>>> x3d-public at web3d.org>:
>>>
>>> Hi Doug. Thanks for looking this over.
>>>
>>> I meant to also note earlier that this proposed change in semantics has
>>> no effect on any existing EXPORT/IMPORT statements in any existing X3D
>>> models, versions 3.0 through 4.0.
>>>
>>> Am glad to see you describing how FreeWrl supports EXPORT/IMPORT to date.
>>>
>>> Certainly refactoring half a gazillion lines of code is likely not
>>> worthwhile for such an extensibility feature... don't want to risk
>>> provoking side-effect problems. Unless you want to, of course... :)
>>>
>>> I'm following your points. Seems sensible, but maybe any changes to the
>>> existing functionality you describe is pretty similar to other handling
>>> that is already in place. Please consider the following short reactions,
>>> and correct me if wrong:
>>>
>>> - Inline nodes exist and receive few ROUTE connections, there are
>>> not many fields there (url load etc.)
>>> - IMPORT creates a node reference that points somewhere in the scene
>>> subgraph loaded by Inline
>>> - That IMPORT reference can already send/receive events via ROUTE,
>>> as long defined in the spec.
>>> - In essence, the proposal says such a node reference might be
>>> treated in the same manner as other USE nodes, which are also node
>>> references.
>>>
>>> Again appreciate all consideration. Even if this is impractical for
>>> FreeWrl, your opinion on feasibility in general remains welcome. Am not
>>> trying to check boxes on a feature list, and am not trying to push a
>>> nontrivial architectural change. Rather am trying to enable significantly
>>> more scalable extensibility by removing a small existing constraint on
>>> usage.
>>>
>>> p.s. curiously, since the specification intentionally never mandates
>>> error responses, it seems like a browser implementation might
>>> satisfactorily permit IMPORT node references to behave similarly as USE
>>> node references, if it wants. hmmm...
>>>
>>> Have fun with X3D! 😀
>>>
>>> all the best, Don
>>> --
>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>> Relative Motion Consulting https://RelativeMotion.info
>>> <https://relativemotion.info/>
>>>
>>>
>>> On Thu, Oct 9, 2025 at 9:14 AM GPU Group <gpugroup at gmail.com> wrote:
>>>
>>>> Don,
>>>> "synchronization" I suspect the change would break (25 year old,
>>>> currently unmaintained) freewrl. I like the use-case you mention for the
>>>> change, seems well worth a big change. Final nail in freewrl coffin? Not
>>>> necessarily but would require insight and ambition to refactor 500,000
>>>> lines of code to allow a layer of abstraction / uncertainty around every
>>>> node and route in the scenegraph.
>>>> -Doug
>>>> more..
>>>> tests for new conformance would be
>>>> - if routes can dangle before an Inline is loaded, and after an Inline
>>>> is unloaded
>>>> - by dangle I mean point harmlessly TO nothing / unloaded node, without
>>>> being garbage collected
>>>> - no error or warning is issued when a route dangles
>>>> - if Inlined nodes are to be treated like regular scenegraph nodes,
>>>> would that mean all routes to regular scenegraph nodes should be able to
>>>> dangle?
>>>> - current specs: a test for deleting a regular scenegraph node: have an
>>>> active route to it, and see if something breaks when the node is deleted
>>>> -- would that need to change so instead of garbage collecting routes to
>>>> deleted nodes, they dangle, and (somehow) are allowed to hook back up to
>>>> new added nodes?
>>>> freewrl current Inline mechanism:
>>>> - Inlines are loaded, parsed in a separate thread, and can be loaded
>>>> and unloaded with true/false field on Inline
>>>> - on each rendering frame, when Inline node is rendered/drawn/visited,
>>>> it does a little work to check the load progress/status, and makes any
>>>> changes to IMPORT routes and AS nodes as needed
>>>> - freewrl uses special routes to Inlined IMPORTed nodes, which can
>>>> 'dangle' (called weak routes in freewrl) while waiting for the inline to
>>>> load (rest of scene can be rendering).
>>>> - the special routes get an extra complex lookup to see if the TO node
>>>> is loaded
>>>> - versus deleting a regular scenegraph node would trigger a search for
>>>> routes to the deleted node, and the routes would be deleted/garbage
>>>> collected too
>>>> - and normal routes, freewrl uses memory addresses for start and end
>>>> node fields, and does a memory copy of field value during routing loop,
>>>> (versus weak/dangling route complex lookup in separate loop)
>>>> - when an Inline EXPORTed node is loaded it is allocated to a memory
>>>> address via malloc. when unloaded and free(), and reloaded and
>>>> reallocated, it would be loaded in a different memory address, so can't do
>>>> a simple memcpy with old address during routing, needs to check if node
>>>> loaded and what's the new memory address
>>>> SUMMARY: freewrl seems to be missing a layer of abstraction around or
>>>> flag for each node and route that would allow a USE of an Inlined AS node
>>>> and IMPORT route to enjoy equal status in the scenegraph. Not immediately
>>>> obvious how to fix / refactor.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Oct 8, 2025 at 1:27 PM Don Brutzman via x3d-public <
>>>> x3d-public at web3d.org> wrote:
>>>>
>>>>> [BLUF summary: proposed specification change to allow regular re-USE
>>>>> of imported node references.]
>>>>>
>>>>> Am trying to write a prototype for HAnim, and hoped that I might
>>>>> EXPORT a large model so that a smaller scene might IMPORT the HAnimHumanoid
>>>>> for further reuse (as a USE node in a prototype). Example EXPORT:
>>>>>
>>>>> - 3D Example Archives: Humanoid Animation, Characters, Jin LOA 2
>>>>> - Articulated 3D game character designed with a general graphics
>>>>> tool, then converted into an X3D HAnim model and available for IMPORT as
>>>>> JinLOA2.
>>>>> -
>>>>> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JinLOA2Index.html
>>>>> - <!-- This node has an EXPORT
>>>>> <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JinLOA2.html#JinLOA2> connection
>>>>> that can exchange events with a parent X3D model. -->
>>>>> <HAnimHumanoid DEF='hanim_JinLOA2
>>>>> <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JinLOA2.html#hanim_JinLOA2>
>>>>> ' loa='2' name='JinLOA2' scale='0.0225 0.0225 0.0225'> on line 30
>>>>> <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JinLOA2.html#30>
>>>>>
>>>>> - <EXPORT localDEF='hanim_JinLOA2
>>>>> <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JinLOA2.html#hanim_JinLOA2>
>>>>> ' AS='JinLOA2'/> on line 1319
>>>>> <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JinLOA2.html#1319>
>>>>>
>>>>>
>>>>> Hmmm, please notice that medium-size HAnim model is (1319 - 30 =
>>>>> 1289) lines long... gee, wouldn't it be nice to Inline and IMPORT
>>>>> that model in ~3 lines instead, with added benefit of being able to reuse
>>>>> pose and motion animations with it also.
>>>>>
>>>>> However the current X3D Architecture appears to restrict the usage of
>>>>> imported nodes solely to receiving/sending events. That restriction
>>>>> permits writing ROUTE connections, but a blocker if trying to write a
>>>>> prototype or trying other node re-USE.
>>>>>
>>>>> EXPORT and IMPORT statements are rarely used, but have been around a
>>>>> long time... since X3D 3.0, about 25 years maybe. They have potential for
>>>>> great expressive power and extensibility (the X in X3D). However, am
>>>>> guessing that the reuse limitation of IMPORT nodes has likely inhibited our
>>>>> adoption. If I recall correctly, the primary objection (way back then) to
>>>>> allowing full access to an imported node reference was uncertainty about
>>>>> how it might all work, perhaps complicated by run-time synchronization
>>>>> concerns.
>>>>>
>>>>> We have come a long way since then. It seems pretty clear that an
>>>>> Inline node loads an external scene graph into the current scene graph.
>>>>> Further, the EXPORT statement identifies a specific node (sub graph) within
>>>>> that inlined scene graph.
>>>>>
>>>>> The straightforward way to think about this: Inline EXPORT/IMPORT
>>>>> provides a reference to a node in the currently loaded scene graph. Given
>>>>> that the author has a reference to an active node, they ought to be able to
>>>>> utilize that node reference just like any other DEF/USE node reference.
>>>>>
>>>>> I propose we relax the legacy (25-year) restriction and allow IMPORT
>>>>> node references to be treated the same as USE node references.
>>>>>
>>>>> Towards that end, have written out suggested changes in the draft v4.1
>>>>> architecture, adding to a number of editorial improvements already
>>>>> accomplished as part of
>>>>>
>>>>> - Mantis 1470: add EXPORT/IMPORT field DESCRIPTION for X3D
>>>>> Architecture 4.1; also allow reuse
>>>>> - https://mantis.web3d.org/view.php?id=14701470: add EXPORT/IMPORT
>>>>> field DESCRIPTION for X3D Architecture 4.1
>>>>>
>>>>> Request review, considerations and reactions. The markup changes at
>>>>> first look complex but are essentially all geared towards the single
>>>>> objective of allowing re-use of IMPORT nodes. Lots of markup shows that
>>>>> there are few actual changes to existing prose, most of it is simply
>>>>> editorial re-organization for clarity.
>>>>>
>>>>> This is a good topic for this week's specification editors call on
>>>>> Friday (9 pacific).
>>>>> ______________________________
>>>>>
>>>>> For easy review, current markup follows. *First is Concepts.*
>>>>>
>>>>> - X3D Architecture v4.1, clause 4 Concepts, 4.4.6 EXPORT/IMPORT
>>>>> semantics
>>>>> -
>>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#ExportImportSemantics
>>>>>
>>>>> 4.4.6 EXPORT/IMPORT semantics Import/Export semantics
>>>>>
>>>>> Editors note: there are few actual changes here, most are simply
>>>>> switching the order of EXPORT and IMPORT. Added functionality: imported
>>>>> node reuse.
>>>>>
>>>>> The EXPORT feature allows authors to identify specific parts of an X3D
>>>>> model which might be safely shared and reused by other X3D models. The
>>>>> IMPORT feature allows authors to incorporate content defined within Inline
>>>>> nodes or created programmatically into the namespace of the containing file
>>>>> for the purposes of event routing and reusing scene subgraphs on a
>>>>> per-node basis. In contrast with external prototyping (see 4.4.5
>>>>> External prototype semantics
>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#Externalprototypesemantics>),
>>>>> which allows access to individual fields of nodes defined as prototypes in
>>>>> external files, IMPORT provides access to all the fields of an externally
>>>>> defined node with a single statement (see 9.2.6 IMPORT statement
>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#IMPORTStatement>
>>>>> ).
>>>>>
>>>>> Importing nodes from an Inlined file is accomplished with two
>>>>> statements: EXPORT and IMPORT. IMPORT and EXPORT. The IMPORT
>>>>> statement is used in the containing file to define which nodes of an Inline
>>>>> are to be incorporated into the containing file's namespace. The
>>>>> EXPORT statement is used in the file being Inlined, to control access over
>>>>> which nodes within a file are visible to other files (see 9.2.5
>>>>> EXPORT statement
>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#EXPORTStatement>).
>>>>> EXPORT statements are not allowed in prototype declarations. The
>>>>> IMPORT statement is used in the containing file to define which nodes of an
>>>>> Inline are to be incorporated into the containing file's namespace.
>>>>>
>>>>> In contrast with external prototyping (see 4.4.5 External prototype
>>>>> semantics
>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#Externalprototypesemantics>),
>>>>> which allows access to individual fields of nodes defined as prototypes in
>>>>> external files, IMPORT provides access to all the fields of an externally
>>>>> defined node with a single statement (see 9.2.6 IMPORT statement
>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#IMPORTStatement>
>>>>> ).
>>>>>
>>>>> ______________________________
>>>>>
>>>>> *Next is the EXPORT statement.*
>>>>>
>>>>> - X3D Architecture v4.1, clause 9 Networking component, 9.2.5
>>>>> EXPORT statement
>>>>> -
>>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#EXPORTStatement
>>>>>
>>>>> 9.2.5 EXPORT statement
>>>>>
>>>>> The EXPORT statement is used within an X3D file to specify nodes that
>>>>> may be imported into other scenes when Inlining that file. Only named nodes
>>>>> exported with an EXPORT statement are eligible to be imported into another
>>>>> scene. file. DEF names are used to identify exported nodes. See 4.4.6
>>>>> EXPORT/IMPORT semantics
>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#ExportImportSemantics> for
>>>>> further details.
>>>>>
>>>>> EXPORT statements may appear anywhere in the file and have the
>>>>> following form:
>>>>>
>>>>> EXPORT <NodeDEFName> [ AS <ExportedNodeDEFName> ]
>>>>> [DESCRIPTION "a simple description of intended EXPORT purpose"]
>>>>>
>>>>> EXPORT <NodeName> [ AS <ExportedNodeName> ]
>>>>>
>>>>> The EXPORT statement has the following components:
>>>>>
>>>>> 1. The local DEF name of the node to be exported if the current
>>>>> scene is retrieved externally via Inline,
>>>>> 2. An optional alternative DEF name that is used AS a default as an alias
>>>>> for the exported node when importing it into other scenes, files,
>>>>> 3. An optional simple DESCRIPTION of intended purpose for the node
>>>>> provided via EXPORT.
>>>>>
>>>>> The EXPORT statement has the following semantics:
>>>>>
>>>>> 4. Once imported into a containing scene, events may be routed to
>>>>> or from the fields of an exported node in exactly the same manner
>>>>> as any node defined with DEF.
>>>>> 5. Exported nodes imported into a containing scene may be
>>>>> referenced via a USE statement in the importing scene. may not be
>>>>> instanced via the USE statement.
>>>>> 6. Exportation may not be propagated across multiple files; that
>>>>> is, a node imported into one scene using the IMPORT statement may not then
>>>>> be further exported into another scene using the EXPORT statement.
>>>>> 7. Nodes shall not be exported from within the body of a PROTO
>>>>> declaration.
>>>>> 8. Any scene with an EXPORT statement shall apply UNIT statement
>>>>> adjustments as needed to the fields of any exported nodes and child nodes.
>>>>> 9. The EXPORT statement can appear wherever a ROUTE statement is
>>>>> allowed, and shall be contained within the Inline node to which it refers.
>>>>>
>>>>> The following example illustrates the use of the EXPORT statement
>>>>> (Classic VRML encoding):
>>>>>
>>>>> EXAMPLE
>>>>>
>>>>> DEF T1 Transform {
>>>>> # additional nodes and fields...
>>>>> }# additional nodes and fields...
>>>>>
>>>>> EXPORT T1 AS rootTransform
>>>>>
>>>>> In the above example, node T1 is exported for use by other X3D
>>>>> scenes. The optional AS keyword defines the exported name of *T1* as
>>>>> *rootTransform* (*i.e.*, other scenes may import the node only using
>>>>> the name rootTransform). All defined alias AS names shall also meet
>>>>> appropriate uniqueness requirements in the local DEF namespace of the
>>>>> parent scene.
>>>>>
>>>>> ______________________________
>>>>> *Next is the IMPORT statement.*
>>>>>
>>>>> - X3D Architecture v4.1, clause 9 Networking component, 9.2.6
>>>>> IMPORT statement
>>>>> -
>>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#IMPORTStatement
>>>>>
>>>>> 9.2.6 IMPORT statement
>>>>>
>>>>> The IMPORT statement is used within an X3D file to specify nodes,
>>>>> which are defined within Inline files or programmatically created content,
>>>>> that are to be brought into the namespace of the containing file for the
>>>>> purposes of event routing. Once a node is imported, events may be sent to
>>>>> its fields via ROUTEs, or routed from any fields of the node which have
>>>>> output events. DEF names are used to identify nodes. See 4.4.6
>>>>> EXPORT/IMPORT semantics
>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#ExportImportSemantics> for
>>>>> further details.
>>>>>
>>>>> IMPORT statements may appear anywhere in the file and have the
>>>>> following form:
>>>>>
>>>>> IMPORT <InlineNodeDEFName>*.*<ExportedNameFromInlinedFile> [ AS
>>>>> <NewLocalNodeDEFName> ]
>>>>> [DESCRIPTION "a simple description of intended IMPORT purpose"]
>>>>>
>>>>> IMPORT <InlineNodeName>*.*<ExportedNameFromInlinedFile> [ AS
>>>>> <NewLocalNodeName> ]
>>>>>
>>>>> The IMPORT statement has the following components:
>>>>>
>>>>> 1. The DEF name of the Inline node that contains the node to be
>>>>> imported,
>>>>> 2. The DEF name of the node to import,
>>>>> 3. An optional alternative DEF name that is used AS as an alias
>>>>> for the imported node within the run-time name scope, to help
>>>>> prevent avoid potential DEF name clashes within the parent scene
>>>>> containing the IMPORT statement,
>>>>> 4. An optional simple DESCRIPTION of intended purpose for the node
>>>>> provided via IMPORT.
>>>>>
>>>>> The IMPORT statement has the following semantics:
>>>>>
>>>>> 5. Once imported, events may be routed to or from the fields of an imported
>>>>> node in the Inline scene, in exactly the same manner as any node
>>>>> defined locally with DEF.
>>>>> 6. Editors note: the following is an important change, otherwise
>>>>> an imported node cannot be utilized other than by receiving ROUTEd events
>>>>> (as shown by the InlineImport.x3d
>>>>> <https://www.web3d.org/x3d/content/examples/Basic/X3dSpecifications/InlineImportIndex.html>
>>>>> example).
>>>>> Nodes imported into an X3D scene using the IMPORT statement may be
>>>>> referenced not be instanced via the USE statement.
>>>>> 7. Only nodes that are exported from within the Inline scene via
>>>>> an EXPORT statement may be imported using a corresponding IMPORT statement.
>>>>> 8. The IMPORT statement can appear wherever a ROUTE statement is
>>>>> allowed, and shall follow the Inline node to which it refers.
>>>>>
>>>>> Any node reference that is obtained via IMPORT from an exporting scene
>>>>> is also available as a USE node in the importing scene. This requirement is
>>>>> necessary for the node reference retrieved by IMPORT to have full
>>>>> capabilities in the importing scene. Nevertheless, important
>>>>> synchronization considerations arise when one or more Inline models are
>>>>> loaded as part of the current scene graph.
>>>>>
>>>>> 9. A single Inline node is allowed to have multiple IMPORT
>>>>> statements. The state of nodes within that currently loaded Inline model
>>>>> are consistently maintained as part of the current scene.
>>>>> 10. Multiple Inline nodes with separate IMPORT statements are
>>>>> completely independent, even if each independent Inline is retrieving a
>>>>> copy of the same original model.
>>>>>
>>>>> The following example illustrates the use of the IMPORT statement
>>>>> (Classic VRML encoding syntax):
>>>>>
>>>>> EXAMPLE
>>>>>
>>>>> DEF MyInline I1 Inline {
>>>>> url "someurl.x3d"
>>>>> }
>>>>> IMPORT MyInline.rootTransform AS ImportedTransform I1.rootTransform AS I1Root ...
>>>>> # ROUTE events into the imported node, which is now a part of an Inline scene subgraph
>>>>> DEF PI PositionInterpolator { } { ... }
>>>>> ROUTE PI.value_changed TO ImportedTransform.set_translation I1Root.set_translation
>>>>>
>>>>> # also USE the imported node (and associated scene subgraph) elsewhere in the parent scene
>>>>> Group {
>>>>> USE ImportedTransform
>>>>> }
>>>>>
>>>>> # also USE the imported node when defining an instance of a MyNewTransform prototype
>>>>> MyNewTransform {
>>>>> children USE ImportedTransform
>>>>> }
>>>>>
>>>>> In the above example,
>>>>>
>>>>> - rootTransform is externally defined as a Transform node in the
>>>>> file someurl.x3d and exported via an EXPORT statement. (see 4.4.6
>>>>> Import/Export semantics
>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#ExportImportSemantics>
>>>>> ).
>>>>> - The optional AS keyword in the IMPORT statement defines an alias
>>>>> for the MyInline.rootTransform rootTransform DEF. , so that
>>>>> - Within the containing scene, the node is referenced using the AS
>>>>> alias name ImportedTransform. DEF name I1Root.
>>>>>
>>>>> All defined alias AS names shall also meet appropriate uniqueness
>>>>> requirements in the local DEF namespace of the parent scene.
>>>>>
>>>>> ______________________________
>>>>> Additional thanks to Joe Williams, Holger Seelig, and Nicholas Polys
>>>>> for contributing to this analysis and potential improvement.
>>>>>
>>>>> All feedback welcome! This simple functional refinement has potential
>>>>> for much X3D scalability and extensibility.
>>>>>
>>>>> Thanks in advance for considering the possibilities.
>>>>>
>>>>> all the best, Don
>>>>> --
>>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>>> Relative Motion Consulting https://RelativeMotion.info
>>>>> <https://relativemotion.info/>
>>>>> _______________________________________________
>>>>> 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/20251011/a95eed0c/attachment-0001.html>
More information about the x3d-public
mailing list