[x3d-public] allowing full capabilities for X3D node reuse with Inline EXPORT/IMPORT AS/USE
John Carlson
yottzumm at gmail.com
Sun Oct 19 06:49:12 PDT 2025
Doug,
I considered a MFPath field type some time ago:
https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/route.js
See test() function for greatest detail.
Enjoy!
John
On Sat, Oct 18, 2025 at 4:56 PM GPU Group via x3d-public <
x3d-public at web3d.org> wrote:
> Q: can/should/could/would it help to have an XPath-like SAI function that
> returns a (filtered) list of nodes (MFNode), for example list of joint type
> nodes from an HAnim?
> -Doug
> https://www.w3schools.com/XML/xml_xpath.asp
>
>
> On Sat, Oct 18, 2025, 2:00 p.m. Don Brutzman <don.brutzman at gmail.com>
> wrote:
>
>> Gee Doug, design sounds pretty thorough!
>>
>> Holger, the following HAnimPose prototype example + ProtoInstance nodes
>> seem to be fully working now.
>> -
>>
>> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Pose/HAnimPosePrototypeIndex.html
>>
>> However I have not been able to get the IMPORT/Inline HAnimHumanoid
>> replacement to work, as an alternative to copying the HAnimHumanoid
>> completely…
>>
>> Wondering if my conversion stylesheets are not iinvoking your latest
>> X_ITE correctly?
>>
>> all the best, Don
>> --
>> Don Brutzman
>> X3D graphics, virtual worlds, Navy robotics
>> https://faculty.nps.edu/brutzman
>>
>>
>> On Fri, Oct 17, 2025 at 09:10 GPU Group <gpugroup at gmail.com> wrote:
>>
>>> Thanks again Holger, the proxy idea might work in freewrl.
>>> -Doug
>>> more..
>>> Recursive Addressing and Node Status Table:
>>> Use-Case: Inlines can inline and pass-through nodes via import + export.
>>> - but each Inline can un-export or un-import a node
>>> - script nodes can delete nodes in executionContext
>>> Recursive Addressing:
>>> When recursing from the main scene, a getNode(inode) funcion would check
>>> current import, Inline.loaded, export, node deleted? and so on through
>>> layers of inlines in what I'll call recursive addressing
>>> - the recursive addressing would be applied when traversing the
>>> scenegraph to draw a node, and when routing, would be applied at each end
>>> of the route
>>> - recursion bottoms out when a node is 'unresolved' or it gets to a
>>> specific node (vs intermediary proxies)
>>> NST node status table::
>>> - MFNode and SFNode fields would hold integer indexes into a table of
>>> (node or proxy address) aka NST node status table, which would be globally
>>> available, and not garbage collected until the browser shuts down, and
>>> putting a null for the entry when a node is deleted, but not re-using the
>>> table entry for the life of the browser run. This would avoid the need for
>>> hunting down references to a node that is being deleted. Any proxies
>>> pointing to a node would go through the NST to get the address, and if null
>>> would not draw/route.
>>> - so when an Inline is unloaded, and all its nodes deleted, any
>>> main-scene proxies pointing at imported nodes would go through the NST
>>> IMPORT and EXPORT tables in each executionContext
>>> - proxies would have an index into the table for themselves, and when
>>> un-imported or un-exported (through SAI) a flag in the table would be set
>>> Option: all nodes could be wrapped with a proxy, or just use proxies as
>>> needed
>>> During parsing, routes would not resolve to field ;memory address
>>> end-points, but rather DEFname + fieldname.
>>> - during routing, on the first pass, a long lookup getNodeB(string
>>> DEFname) and getField(string fieldname) would be used, and subsequently if
>>> nothing changed a shortcut would be used, while still recursing as needed
>>> to check for deletion, import/export status, loaded status.
>>>
>>>
>>>
>>> On Thu, Oct 9, 2025 at 3:04 PM GPU Group <gpugroup at gmail.com> wrote:
>>>
>>>> Thanks Holger - I see something about proxy wrappers, and while smoke
>>>> pours out of my ears, I'll incubate the implications.
>>>> -Doug
>>>> For example would routes carry the string field name, route to/from
>>>> proxies, and proxy node would do string lookup on each routing loop? Would
>>>> there be one type of route, and one type of proxy wrapper around all nodes,
>>>> and the proxy would hold specific node pointer and a few other things like
>>>> specific node type, or NULL if unloaded? Would the specific nodes have a
>>>> pointer back to one specific proxy, or a list of proxies, so when being
>>>> unloaded, it can refer back to it/ them all and empty all the proxies?
>>>>
>>>> On Thu, Oct 9, 2025 at 2:31 PM Holger Seelig <holger.seelig at yahoo.de>
>>>> wrote:
>>>>
>>>>> Hello Doug,
>>>>>
>>>>> There is a special node internally X3DImportedNodeProxy which pretends
>>>>> to be the exported node and then behaves accordingly. This class overloads
>>>>> some basic functions. If this node is then inside an SFNode, you
>>>>> won't notice any difference. If the Inline unloads, you should see a NULL
>>>>> node maybe in the future.
>>>>>
>>>>>
>>>>> https://github.com/create3000/x_ite/blob/feature/use-exported-node/src/x_ite/Components/Core/X3DImportedNodeProxy.js
>>>>>
>>>>> Best regards,
>>>>> Holger
>>>>>
>>>>> —
>>>>> Holger Seelig
>>>>> holger.seelig at yahoo.de
>>>>>
>>>>>
>>>>> Am 09.10.2025 um 22:09 schrieb GPU Group <gpugroup at gmail.com>:
>>>>>
>>>>> Holger, very interesting. I'd love to know how you did it, if it's not
>>>>> too hard to explain.
>>>>> -Doug
>>>>>
>>>>> On Thu, Oct 9, 2025 at 2: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
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
> 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/20251019/de63ffb4/attachment-0001.html>
More information about the x3d-public
mailing list