[x3d-public] ProtoBody completeness in nested Protos
John Carlson
yottzumm at gmail.com
Tue Apr 26 09:37:15 PDT 2022
I know what building a system with scrape and paste is like. Can we
possibly use X_ITE’s way?
Note that one one has to paste scripts as well. Ouch!
You’re welcome to use my nonstandard JSON script post-processor. I
recommend converting it to XML. It doesn’t cover all cases. Likely X_ITE
is better.
I do have a pipeline approach, which is promising, separating PROTOs from
scripting and then later converting to XML.
If you were my employee, I would highly recommend using X_ITE’s approach,
but I don’t know about licensing.
I believe I finally got extern PROTOs working, but I haven’t tested for a
long time!
John
On Tue, Apr 26, 2022 at 8:57 AM GPU Group <gpugroup at gmail.com> wrote:
> When I started with freewrl around 2009, it had a text-based system for
> protos:
> - when parsing a scene, if it found a proto declare, it would scrape the
> text into a buffer. Then as it continued parsing, when it hit a proto
> instance it pasted, and continued parsing over the pasted text as though it
> had been there all along. Extern protos similar, it would pause parsing, go
> to the file referenced, look for the proto declare by name, and scrape out
> the text of the ProtoDeclare, for pasting in-scene.
> And it worked a bit. But especially extern protos weren't working
> reliably. As a casual volunteer I decided to fix the bugs. How hard could
> it be? A little debugging and presto, I'd be a hero. As I got into it and
> saw more scene failure examples there were several emotional stages like
> grieving denial, shock, sadness, resistance etc. And a slow dawning
> realization the whole system needed a rework.
> And I didn't have support from others -just silence, perhaps they knew it
> was a mess and wanted to stay clear.
> It was a sickening feeling, and I needed to think for a few weeks whether
> I even wanted to be a volunteer programmer if the system was rotten from
> the core.
> So it can not only be a monster task, but precisely because it's a monster
> there's little support for those brave enough to tackle it.
> (After a few weeks I got to the Acceptance stage of grieving, and spent 6
> months of hobby time building the new proto system).
>
>
>
> On Tue, Apr 26, 2022 at 7:16 AM GPU Group <gpugroup at gmail.com> wrote:
>
>>
>> http://dug9.users.sourceforge.net/web3d/tests/protos/Proto_context_inherit_stack_push_and_pop.jpg
>>
>>
>> http://dug9.users.sourceforge.net/web3d/tests/protos/Proto_context_inherit_stack_push_and_pop.x3d
>>
>>
>>
>>
>> On Mon, Apr 25, 2022 at 9:23 PM Andreas Plesch <andreasplesch at gmail.com>
>> wrote:
>>
>>> Thank you for these examples. These are great to study execution
>>> contexts.
>>>
>>> The tricky Proto_context_inherit_and_declare.x3d (see below) first
>>> defines a Thing proto (red sphere) which is then inherited in another
>>> proto (NestedDuo) and instanced inside the NestedDuo proto. Then the
>>> Thing proto gets redefined inside the NestedDuo proto as blue box and
>>> instanced again. Finally, the NestedDuo proto is instanced in the main
>>> scene, and a red sphere and blue box is displayed.
>>>
>>> So freewrl protos inherit parent proto definitions but these inherited
>>> protos can then be redeclared. This is very reasonable but I am not
>>> sure if such inheritance is intended or required in X3D. It may be
>>> silently intended (as Don may have suggested) but the idea of
>>> execution contexts and name scopes would be that there is
>>> encapsulation rather than somehow permeable boundaries.
>>>
>>> Another experiment would be to now add a Thing instance to the main
>>> scene at the end, in another transform to not overlap other shapes.
>>>
>>> Should the final Thing display a red sphere or a blue box ?
>>>
>>> My guess is a red sphere (if the scene name scope is maintained) but I
>>> am not sure since it may be that there is actually just one global
>>> name scope (for protos), or that the redefinition somehow affects the
>>> parent execution context. Don outlined more of a sequential processing
>>> flow which may favor display of a blue box.
>>>
>>> -Andreas
>>>
>>> <ProtoDeclare name='Thing'>
>>> <ProtoBody>
>>> <Shape>
>>> <Appearance>
>>> <Material diffuseColor='1 0 0' />
>>> </Appearance>
>>> <Sphere/>
>>> </Shape>
>>> </ProtoBody>
>>> </ProtoDeclare>
>>>
>>> <ProtoDeclare name='NestedDuo'>
>>> <ProtoBody>
>>> <Group>
>>> <Transform translation='-1 0 0'>
>>> <ProtoInstance name='Thing' />
>>> </Transform>
>>>
>>> <ProtoDeclare name='Thing'>
>>> <ProtoBody>
>>> <Shape>
>>> <Appearance>
>>> <Material diffuseColor='0 0 1' />
>>> </Appearance>
>>> <Box/>
>>> </Shape>
>>> </ProtoBody>
>>> </ProtoDeclare>
>>>
>>> <Transform translation='1 0 0'>
>>> <ProtoInstance name='Thing' />
>>> </Transform>
>>> </Group>
>>> </ProtoBody>
>>> </ProtoDeclare>
>>>
>>> <ProtoInstance name='NestedDuo' />
>>> <!-- experiment below -->
>>> <Transform translation='3 0 0'
>>> <ProtoInstance name='Thing' />
>>> </Transform>
>>>
>>> > Date: Mon, 25 Apr 2022 16:59:38 -0600
>>> > From: GPU Group <gpugroup at gmail.com>
>>> >
>>> >
>>> http://dug9.users.sourceforge.net/web3d/tests/protos/Proto_context_inherit_and_declare.x3d
>>> >
>>> >
>>> http://dug9.users.sourceforge.net/web3d/tests/protos/Proto_context_inherit_and_declare.jpg
>>> >
>>> >
>>> http://dug9.users.sourceforge.net/web3d/tests/protos/Proto_context_inherit.jpg
>>> >
>>> >
>>> http://dug9.users.sourceforge.net/web3d/tests/protos/Proto_context_inherit.x3d
>>> >
>>> >
>>> >
>>> > On Mon, Apr 25, 2022 at 4:11 PM GPU Group <gpugroup at gmail.com> wrote:
>>> >
>>> > >
>>> > >
>>> http://dug9.users.sourceforge.net/web3d/tests/protos/Proto_context_vs_name.x3d
>>> > >
>>> > >
>>> > >
>>> > >
>>> http://dug9.users.sourceforge.net/web3d/tests/protos/Proto_context_vs_name.jpg
>>> > >
>>> > >
>>> > >
>>> > > On Mon, Apr 25, 2022 at 4:01 PM GPU Group <gpugroup at gmail.com>
>>> wrote:
>>> > >
>>> > >> http://dug9.users.sourceforge.net/web3d/tests/protos/CircleFish.jpg
>>> > >>
>>> > >>
>>> > >>
>>> http://dug9.users.sourceforge.net/web3d/tests/protos/Proto_nested.jpg
>>> > >>
>>> > >>
>>> > >>
>>> http://dug9.users.sourceforge.net/web3d/tests/protos/Proto_nested.x3d
>>> > >>
>>> > >>
>>> > >>
>>> > >> On Mon, Apr 25, 2022 at 1:10 PM Andreas Plesch <
>>> andreasplesch at gmail.com>
>>> > >> wrote:
>>> > >>
>>> > >>> Hi Doug,
>>> > >>>
>>> > >>> Thank you for your response.
>>> > >>>
>>> > >>> > Date: Mon, 25 Apr 2022 07:09:14 -0600
>>> > >>> > From: GPU Group <gpugroup at gmail.com>
>>> > >>> >
>>> > >>> > freewrl loads extern proto scenes as whole scene files, but as
>>> 'dead'
>>> > >>> > scenery like a library file: in binary form, ready to binary
>>> deep copy
>>> > >>> > parts to live scenery, but node initialization functions not yet
>>> > >>> > called, and not rendered. Subsequent # references to the same
>>> scene
>>> > >>> file
>>> > >>> > use the same loaded library scene. So any ProtoDeclares outside
>>> the
>>> > >>> > ProtoBody would be resolved.
>>> > >>>
>>> > >>> I think the issue in the CircleFishLod prototype is not directly
>>> > >>> related to extern proto use, but only to how the local ProtoDeclare
>>> > >>> definition needs to reach into the surrounding Scene. It sounds
>>> like
>>> > >>> freewrl allows for that mixing of Execution Contexts, assuming that
>>> > >>> the CircleFishLod proto works in freewrl.
>>> > >>>
>>> > >>> A stress test example would be a Scene which has two Protos, A and
>>> B.
>>> > >>>
>>> > >>> A is a simple Proto with the name "Joe". The scene uses it in an
>>> > >>> instance later.
>>> > >>>
>>> > >>> B is a nested Proto which internally uses another Proto. This
>>> internal
>>> > >>> Proto is also named "Joe" and has both a ProtoDeclare and instances
>>> > >>> within B. The scene then uses B in an instance later.
>>> > >>>
>>> > >>> How should a browser resolve which ProtoDeclaration to use for the
>>> > >>> internal ProtoInstance "Joe" ? Which one would freewrl choose ? The
>>> > >>> first one it finds ?
>>> > >>>
>>> > >>> Perhaps it is time to draft such a test.
>>> > >>>
>>> > >>> Thanks, Andreas
>>> > >>>
>>> > >>> PS: rough draft
>>> > >>>
>>> > >>> <ProtoDeclare name='Joe'>
>>> > >>> <ProtoBody red sphere />
>>> > >>> </ProtoDeclare>
>>> > >>>
>>> > >>> <ProtoDeclare name='nestedBox'>
>>> > >>> <ProtoBody>
>>> > >>> <ProtoDeclare name='Joe'>
>>> > >>> <ProtoBody blue box />
>>> > >>> </ProtoDeclare>
>>> > >>> <ProtoInstance name='Joe' />
>>> > >>> </ProtoBody>
>>> > >>> </ProtoDeclare>
>>> > >>>
>>> > >>> <ProtoInstance name='Joe' />
>>> > >>> <ProtoInstance name='nested' />
>>> > >>>
>>> > >>> Should display a red sphere and blue box.
>>> > >>>
>>> > >>> > -Doug
>>> > >>> > PS this relates to:
>>> > >>> >
>>> > >>> > PROTOTYPE STYLE IMPORTS
>>> > >>> >
>>> > >>> > I had mentioned a prototype style import for gltf use:
>>> > >>> >
>>> > >>> > Shape { url=?library.gltf#shapeName? }
>>> > >>> >
>>> > >>> > Similar to how we load extern protos as a whole ?dead? scene,
>>> and then
>>> > >>> do
>>> > >>> > binary deep copies where used in the live scene to make live.
>>> > >>> >
>>> > >>> > But interestingly, the same goes for x3d scenery ? don?t need
>>> glTF,
>>> > >>> don?t
>>> > >>> > need extern protos in library scene, don?t need Inline or IMPORT.
>>> > >>> >
>>> > >>> > So the concept could be tested first with x3d scenery.
>>> > >>> >
>>> > >>> > Shape { url=?library.x3dv#shapeName }
>>> > >>> >
>>> > >>> > And then extended to gltf.
>>> > >>> >
>>> > >>> > /PROTOTYPE STYLE IMPORTS
>>> > >>> >
>>> > >>> > On Sun, Apr 24, 2022 at 10:43 PM Brutzman, Donald (Don) (CIV) <
>>> > >>> > brutzman at nps.edu> wrote:
>>> > >>> >
>>> > >>> > > Actually please look a little more closely at that (admittedly
>>> > >>> tricky)
>>> > >>> > > example.
>>> > >>> > >
>>> > >>> > > * CircleFish is an ExternProto, separately defined in another
>>> file
>>> > >>> > > * CircleFishLod is a ProtoDeclare defined in that first file,
>>> > >>> > > CircleFishLodPrototype.x3d
>>> > >>> > > * CircleFishLod ProtoBody contains two ProtoInstance copies of
>>> > >>> CircleFish
>>> > >>> > > * CircleFishLod ProtoDeclare is then followed by a
>>> CircleFishLod
>>> > >>> > > ProtoInstance (again in CircleFishLodPrototype.x3d)
>>> > >>> > >
>>> > >>> > > So I would expect an X3D Browser to
>>> > >>> > >
>>> > >>> > > a. load ExternProtoDeclare CircleFish
>>> > >>> > > b. build ProtoDeclare CircleFishLod
>>> > >>> > > c. create inner ProtoInstance CircleFish for use
>>> > >>> > > d. create outer ProtoInstance CircleFishLod
>>> > >>> > >
>>> > >>> > > Order of steps might vary a bit, but those are the
>>> dependencies.
>>> > >>> Good luck
>>> > >>> > > sir.
>>> > >>> > >
>>> > >>> > > all the best, Don
>>> > >>> > > --
>>> > >>> > > Don Brutzman Naval Postgraduate School, Code USW/Br
>>> > >>> > > brutzman at nps.edu
>>> > >>> > > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
>>> > >>> > > +1.831.656.2149
>>> > >>> > > X3D graphics, virtual worlds, Navy robotics https://
>>> > >>> > > faculty.nps.edu/brutzman
>>> > >>> > >
>>> > >>> > > -----Original Message-----
>>> > >>> > > From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of
>>> Andreas
>>> > >>> > > Plesch
>>> > >>> > > Sent: Sunday, April 24, 2022 9:08 PM
>>> > >>> > > To: X3D Graphics public mailing list <x3d-public at web3d.org>
>>> > >>> > > Subject: [x3d-public] ProtoBody completeness in nested Protos
>>> > >>> > >
>>> > >>> > > ProtoDeclarations may use ProtoInstances of other Protos
>>> inside their
>>> > >>> > > ProtoBody definitions.
>>> > >>> > >
>>> > >>> > > For example, the CircleFishLod proto here:
>>> > >>> > >
>>> > >>> > >
>>> > >>> > >
>>> > >>>
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dgraphic
>>> > >>> > > s.com
>>> > >>> > >
>>> > >>>
>>> %2Fexamples%2FX3dForWebAuthors%2FKelpForestExhibit%2FCircleFishLodProto
>>> > >>> > > typeIndex.html&data=05%7C01%7Cbrutzman%40nps.edu
>>> > >>> > > %7C0b4a867ba9874e371f9b0
>>> > >>> > >
>>> > >>> > >
>>> > >>>
>>> 8da267152fa%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637864565880708349%
>>> > >>> > >
>>> > >>> > >
>>> > >>>
>>> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
>>> > >>> > >
>>> > >>> > >
>>> > >>>
>>> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=upr4eckI8axT7MO5fAUvAWfyBzUJfhTwqcp
>>> > >>> > > BuH7tZjc%3D&reserved=0
>>> > >>> > >
>>> > >>> > > uses ProtoInstances of the CircleFish proto.
>>> > >>> > >
>>> > >>> > > A more extreme case of nesting is:
>>> > >>> > >
>>> > >>> > >
>>> > >>> > >
>>> > >>>
>>> https://www.web3d.org/x3d/content/examples/ConformanceNist/Miscellaneous/PRO
>>> > >>> > > TO/fivedeepnestingIndex.html
>>> > >>> > > <
>>> > >>>
>>> https://www.web3d.org/x3d/content/examples/ConformanceNist/Miscellaneous/PROTO/fivedeepnestingIndex.html
>>> > >>> >
>>> > >>> > >
>>> > >>> > > where Proto1 uses ProtoInstance of Proto2 inside its ProtoBody.
>>> > >>> Proto2
>>> > >>> > > itself uses a ProtoInstance of Proto3 inside its ProtoBody.
>>> And so
>>> > >>> on to
>>> > >>> > > five levels deep.
>>> > >>> > >
>>> > >>> > > The second example with the deep nesting currently works with
>>> x3dom
>>> > >>> but the
>>> > >>> > > seemingly simpler CircleFishLod proto does not.
>>> > >>> > >
>>> > >>> > > The reason is that x3dom expects the complete definition of a
>>> proto
>>> > >>> to be
>>> > >>> > > contained in its ProtoBody. However, The CircleFishLod proto
>>> only
>>> > >>> contains
>>> > >>> > > the CircleFish ProtoInstances in the body but not the
>>> associated
>>> > >>> CircleFish
>>> > >>> > > ProtoDeclaration which for some reason occurs outside the
>>> > >>> CircleFishLod
>>> > >>> > > ProtoBody (and outside the CircleFishLod ProtoDeclaration).
>>> > >>> > >
>>> > >>> > > Expecting the ProtoBody to be complete and self-contained seems
>>> > >>> rather
>>> > >>> > > natural. Is x3dom too strict in this regard, or is there an
>>> > >>> oversight in
>>> > >>> > > the
>>> > >>> > > example ? There is not much guidance in the spec., if any.
>>> > >>> > >
>>> > >>> > > Thanks, Andreas
>>> > >>> > >
>>> > >>> > > --
>>> > >>> > > Andreas Plesch
>>> > >>> > > Waltham, MA 02453
>>> > >>> > >
>>> > >>> > > _______________________________________________
>>> > >>> > > 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/20220425/fdcca17c/attachment-0001.html
>>> > >>> >
>>> > >>> >
>>> > >>> > ------------------------------
>>> > >>> >
>>> > >>> > Message: 4
>>> > >>> > Date: Mon, 25 Apr 2022 15:14:25 +0000
>>> > >>> > From: "Brutzman, Donald (Don) (CIV)" <brutzman at nps.edu>
>>> > >>> > To: Andreas Plesch <andreasplesch at gmail.com>
>>> > >>> > Cc: "x3d at web3d.org" <x3d at web3d.org>, Spec Feedback
>>> > >>> > <spec-comment at web3d.org>, "X3D Public Mailing List
>>> > >>> > (x3d-public at web3d.org)" <x3d-public at web3d.org>,
>>> "Brutzman,
>>> > >>> Donald
>>> > >>> > (Don) (CIV)" <brutzman at nps.edu>
>>> > >>> > Subject: Re: [x3d-public] [x3d] Spec Comment by on 19775-1: X3D
>>> > >>> > Architecture - V4.0: component support needed for glTF
>>> inline
>>> > >>> loading
>>> > >>> > conversion
>>> > >>> > Message-ID:
>>> > >>> > <
>>> > >>>
>>> BY3PR13MB48844D178FEBD3BCA8221B51C4F89 at BY3PR13MB4884.namprd13.prod.outlook.com
>>> > >>> >
>>> > >>> >
>>> > >>> > Content-Type: text/plain; charset="us-ascii"
>>> > >>> >
>>> > >>> > [cc: x3d-public]
>>> > >>> >
>>> > >>> > Thanks for insightful comment. Happy to modify this statement
>>> to list
>>> > >>> all
>>> > >>> > appropriate components, possibly Immersive profile.
>>> > >>> >
>>> > >>> > Michalis, do you have any opinions from writing your glTF->X3D
>>> > >>> conversion
>>> > >>> > code?
>>> > >>> >
>>> > >>> > It helps to know full coverage. If there is a glTF test file
>>> that
>>> > >>> includes
>>> > >>> > all constructs, that would also be helpful to convert and add to
>>> our
>>> > >>> > architecture.
>>> > >>> >
>>> > >>> > all the best, Don
>>> > >>> > --
>>> > >>> > Don Brutzman Naval Postgraduate School, Code USW/Br
>>> > >>> brutzman at nps.edu
>>> > >>> > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
>>> > >>> +1.831.656.2149
>>> > >>> > X3D graphics, virtual worlds, Navy robotics https://
>>> > >>> > faculty.nps.edu/brutzman
>>> > >>> >
>>> > >>> > -----Original Message-----
>>> > >>> > From: x3d <x3d-bounces at web3d.org> On Behalf Of Spec Feedback
>>> > >>> > Sent: Thursday, April 21, 2022 12:47 PM
>>> > >>> > To: x3d at web3d.org
>>> > >>> > Subject: [x3d] Spec Comment by on 19775-1: X3D Architecture -
>>> V4.0
>>> > >>> >
>>> > >>> > -- Submitter indicates that this comment may be public: *Yes* --
>>> > >>> >
>>> > >>> > Comment on 19775-1: X3D Architecture - V4.0
>>> > >>> >
>>> > >>> >
>>> > >>>
>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/component
>>> > >>> > s/networking.html#X3DUrlObject
>>> > >>> >
>>> > >>> > -----------------
>>> > >>> > "Support for loading glTF assets (see 2.[GLTF]) also requires
>>> support
>>> > >>> for
>>> > >>> > Shape component level 2 and Lighting component level 4."
>>> > >>> >
>>> > >>> > Many different data fragments may be contained in the current
>>> standard
>>> > >>> gltf
>>> > >>> > asset structure, even animation data, so maybe also more general
>>> > >>> statement?
>>> > >>> >
>>> > >>> >
>>> > >>> >
>>> > >>> > -----------------
>>> > >>> >
>>> > >>> > Submitted on Thursday, 2022, April 21 - 12:47pm by (Joe D
>>> Williams )
>>> > >>> > IP: 12.206.82.58
>>> > >>> >
>>> > >>> > See: https://www.web3d.org/node/1694/submission/5663
>>> > >>> >
>>> > >>> >
>>> > >>> > _______________________________________________
>>> > >>> > x3d mailing list
>>> > >>> > x3d at web3d.org
>>> > >>> > http://web3d.org/mailman/listinfo/x3d_web3d.org
>>> > >>> > -------------- next part --------------
>>> > >>> > A non-text attachment was scrubbed...
>>> > >>> > Name: smime.p7s
>>> > >>> > Type: application/pkcs7-signature
>>> > >>> > Size: 5353 bytes
>>> > >>> > Desc: not available
>>> > >>> > URL: <
>>> > >>>
>>> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220425/1630c2b4/attachment.p7s
>>> > >>> >
>>> > >>> >
>>> > >>> > ------------------------------
>>> > >>> >
>>> > >>> > Subject: Digest Footer
>>> > >>> >
>>> > >>> > _______________________________________________
>>> > >>> > x3d-public mailing list
>>> > >>> > x3d-public at web3d.org
>>> > >>> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>> > >>> >
>>> > >>> >
>>> > >>> > ------------------------------
>>> > >>> >
>>> > >>> > End of x3d-public Digest, Vol 157, Issue 93
>>> > >>> > *******************************************
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>> --
>>> > >>> Andreas Plesch
>>> > >>> Waltham, MA 02453
>>> > >>>
>>> > >>> _______________________________________________
>>> > >>> 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/20220425/bc638b0c/attachment.html
>>> >
>>> >
>>> > ------------------------------
>>> >
>>> > Subject: Digest Footer
>>> >
>>> > _______________________________________________
>>> > x3d-public mailing list
>>> > x3d-public at web3d.org
>>> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>> >
>>> >
>>> > ------------------------------
>>> >
>>> > End of x3d-public Digest, Vol 157, Issue 99
>>> > *******************************************
>>>
>>>
>>>
>>> --
>>> Andreas Plesch
>>> Waltham, MA 02453
>>>
>>> _______________________________________________
>>> 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/20220426/606233e6/attachment-0001.html>
More information about the x3d-public
mailing list