[x3d-public] X3D meeting minutes 9 SEP 2022: X3D glTF feature comparison, continued
John Carlson
yottzumm at gmail.com
Fri Sep 9 11:51:01 PDT 2022
Im also seeing samplers and interpolation in the examples.
John
On Fri, Sep 9, 2022 at 1:47 PM John Carlson <yottzumm at gmail.com> wrote:
> From what i see, there’s glTF channels for translations, rotations,
> scales, and weights, then there’s extensions and extras.
>
> Very good!
>
> I do need to review glTF some more.
>
> There are also good examples online.
>
> On Fri, Sep 9, 2022 at 1:19 PM Michalis Kamburelis <
> michalis.kambi at gmail.com> wrote:
>
>> John,
>>
>> About "glTF tunnels" -- I'm not sure do I understand the question :) Do
>> you maybe mean "channels" that I mentioned, that connect animations with
>> their target?
>>
>> If yes, take a look at glTF "Animations" section that starts with a good
>> overview+example of the terms used:
>> https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#animations .
>> Quoting important sentence: "Channels connect the output values of the key
>> frame animation to a specific node in the hierarchy.".
>>
>> And also "5.6. Animation Channel",
>> https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#reference-animation-channel
>> , for detailed properties.
>>
>> Regards,
>> Michalis
>>
>> pt., 9 wrz 2022 o 19:55 John Carlson <yottzumm at gmail.com> napisał(a):
>>
>>> Re: Andreas has a glTF/X3D integration app here:
>>>
>>> https://andreasplesch.github.io/Library/Examples/gltf2/Chaser.html
>>>
>>> Mentioned 3 years ago on Nicholas’ blog:
>>> https://www.web3d.org/blog-integrating-x3d-and-gltf
>>>
>>> This has more about integrating events and routes.
>>>
>>> Michalis, do you have a reference for glTF tunnels? So far, I’ve just
>>> identified models.
>>>
>>> Thanks,
>>>
>>> John
>>>
>>> On Fri, Sep 9, 2022 at 12:45 PM Brutzman, Donald (Don) (CIV) <
>>> brutzman at nps.edu> wrote:
>>>
>>>> The Extensible 3D (X3D) Working Group coordinates all Web3D Consortium
>>>> technical development efforts. Working groups are essentially driven by
>>>> the efforts of participants. They focus on issues and technologies that
>>>> produce improvements to our open standards, always achieving results that
>>>> are royalty free for any purpose. All efforts are geared towards improving
>>>> a coordinated set of steadily evolving ISO standards including X3D Version
>>>> 4.
>>>>
>>>> - https://www.web3d.org/working-groups
>>>> - https://www.web3d.org/working-groups/x3d
>>>> -
>>>> https://www.web3d.org/specifications/X3dGraphicsStandardsRelationships.png
>>>> - https://www.web3d.org/x3d4
>>>>
>>>>
>>>>
>>>> Attendees today: John Carlson, Anita Havele, Michalis Kamburelis,
>>>> Nicholas Polys, Dick Puk, Doug Sanden, Don Brutzman. We went long but
>>>> got much done!
>>>>
>>>>
>>>>
>>>> Thanks for all feedback to the steadily improving update comparing X3D
>>>> and glTF. We continued close scrutiny of this document, hopefully *aiding
>>>> both developers and content authors to maximize interoperability,
>>>> adaptation and re-use of 3D model content*.
>>>>
>>>>
>>>>
>>>> Of excellent note: glTF 2 is now an ISO Publicly Available Standard
>>>> (PAS). Renewals are possible every 5 years.
>>>>
>>>> - Khronos glTF 2.0 released as an ISO/IEC International Standard
>>>> -
>>>> https://www.khronos.org/news/press/khronos-gltf-2.0-released-as-an-iso-iec-international-standard
>>>> - https://twitter.com/glTF3D/status/1555192347180544000
>>>>
>>>>
>>>>
>>>> Detailed feedback point-by-point follows below. Also added
>>>>
>>>>
>>>>
>>>> Events and ROUTE connections
>>>>
>>>> Yes
>>>>
>>>> No, animations are attached
>>>>
>>>>
>>>>
>>>> Potential JavaScript file for ROUTEs in JSON:
>>>>
>>>> -
>>>> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/route.js
>>>>
>>>> and
>>>>
>>>> - "..animations are attached using channels"
>>>> -
>>>> https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#reference-animation-channel
>>>>
>>>>
>>>>
>>>> Update spreadsheet attached, also change summaries inserted below.
>>>> Thanks for deep-dive scrutiny!
>>>>
>>>>
>>>>
>>>> -
>>>> https://docs.google.com/spreadsheets/d/1x0DnRtg33AuOA_aSl70L41Gq5m6TFt4t
>>>>
>>>>
>>>>
>>>> As ever, continuing improvements (such as additional glTF extension
>>>> references) are welcome.
>>>>
>>>>
>>>>
>>>> Have (more and more) fun with X3D and glTF! 8)
>>>>
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>> *From:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>>>> *Sent:* Thursday, September 8, 2022 8:39 PM
>>>> *To:* Leonard Daly <Leonard.Daly at realism.com>; x3d-public at web3d.org
>>>> *Cc:* Michalis Kamburelis <michalis.kambi at gmail.com>; puk at igraphics.com;
>>>> Anita Havele <anita.havele at web3d.org>; Nicholas Polys <npolys at vt.edu>;
>>>> Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>>>> *Subject:* RE: [x3d-public] X3D glTF feature comparison [was: X3D
>>>> Working Group Minutes, 2 SEP ...]
>>>>
>>>>
>>>>
>>>> Leonard, thanks very much for sharing these excellent constructive
>>>> comments. Very helpful.
>>>>
>>>>
>>>>
>>>> We will continue working on this comparison document in order to
>>>> hopefully achieve best-possible clarity and correctness.
>>>>
>>>>
>>>>
>>>> One important clarification I can offer now: while X3D4 ISO draft
>>>> international specification references ISO-draft glTF 2 specification.
>>>> Thus cross-referencing glTF extension capabilities and permitting them in
>>>> X3D players is certainly allowed.
>>>>
>>>>
>>>>
>>>> Next session is regular weekly call, Friday 8 SEP, 09-1000 pacific.
>>>> All participation welcome.
>>>>
>>>>
>>>>
>>>> *Consortium and community members are welcome to participate. As
>>>> usual, we meet each Friday.*
>>>>
>>>> • X3D Working Group, Fridays 0900-1000 pacific
>>>>
>>>> •
>>>> https://us02web.zoom.us/j/81634670698?pwd=a1VPeU5tN01rc21Oa3hScUlHK0Rxdz09
>>>>
>>>>
>>>>
>>>> *Web3D Consortium membership has value. Please consider joining to
>>>> maximize your ability to benefit and influence*.
>>>>
>>>> • Join the Web3D Consortium
>>>>
>>>> • https://www.web3d.org/join
>>>>
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>> *From:* x3d-public <x3d-public-bounces at web3d.org> *On Behalf Of *Leonard
>>>> Daly
>>>> *Sent:* Thursday, September 8, 2022 4:21 PM
>>>> *To:* x3d-public at web3d.org
>>>> *Subject:* Re: [x3d-public] X3D glTF feature comparison [was: X3D
>>>> Working Group Minutes, 2 SEP ...]
>>>>
>>>>
>>>>
>>>> These messages were all on the public list and referenced glTF.
>>>>
>>>>
>>>>
>>>> I passed on to 3D Formats WG of Khronos (manages glTF Specification)
>>>> for comments and provided a summary and links to the relevant messages from
>>>> the mailing list and documents. There were links to 3 messages (the initial
>>>> message, the updated PDF, and Michalis' comments.] and the Google Sheet
>>>> document. I gave a chance for people to comment, especially on features of
>>>> glTF.
>>>>
>>>>
>>>>
>>>> The comments from one individual follow.
>>>>
>>>>
>>>>
>>>> Some feedback from my side:(unfortunately I only checked the comments
>>>> in [3] after writing this - there's definitely some overlap)
>>>>
>>>> - It looks like while the X3D side counts their annexes in, glTF
>>>> extension mechanism is ignored for the glTF side (otherwise a good amount
>>>> of the "NO"s would either be "YES" or "possible through extensions"). I
>>>> think an equal comparison would either exclude X3D annexes or include glTF
>>>> extensions.
>>>>
>>>> We want to enter every relevant extension in the table… got a pretty
>>>> good start on that.
>>>>
>>>> - While it's mentioned that X3D is an ISO standard it's omitted
>>>> that glTF is also an ISO standard.
>>>>
>>>> Corrected and announced. Also tweeted the glTF ISO announcement…
>>>>
>>>> - I'm not sure what *Metadata structures: partial, in separate
>>>> files* means for glTF - there's at least one extension for that.
>>>>
>>>> fixed
>>>>
>>>> - *glTF: Transmission format designed for applications rendering
>>>> using WebGL or OpenGLES.* is incorrect in my opinion, I think glTF
>>>> is explicitly not tied to a specific rendering backend, quite the contrary.
>>>>
>>>> fixed
>>>>
>>>> - *glTF: Always changing to support the fast changing GPU, a
>>>> delivery system for highly optimized mesh data for rendering. *kind
>>>> of omits that glTF is also an ISO standard and not "always changing". The
>>>> extension mechanism allows for flexibility but the core is (rightfully)
>>>> rigid.
>>>>
>>>> Deleted that old row, fixed
>>>>
>>>> - One thing that bothers me in a lot of Khronos communication
>>>> around glTF is the focus on "efficient transmission from server to client"
>>>> and similar. Alternate wordings are "The JPEG of 3D" and so on. Lots of
>>>> companies have started to adopt glTF as an interchange format as well
>>>> (including us), not just for last-mile delivery. I don't think it
>>>> strengthens glTF as a whole to "fight against that" in communication and
>>>> continually emphasizing that the format is somehow only suitable for
>>>> last-mile delivery.
>>>> (compare also lots of the USDZ vs. glTF discussions at this year's
>>>> Siggraph)
>>>> I understand this is a bigger discussion but wanted to mention it
>>>> here nonetheless. Almost all of the "Technology Comparison Summaries"
>>>> entries revolve around that, hinting at glTF not being a good format for
>>>> anything else.
>>>>
>>>> We are keen to use glTF phrasing wherever possible to maximize clarity,
>>>> improvements continue to be welcome.
>>>>
>>>> Noted as TODO for table review. Improvements requested when people
>>>> check the specs and announcements.
>>>>
>>>> - Related to the above and some more of the "NO"s: we're happily
>>>> using glTF extensions for composition of files, inline use of glbs inside
>>>> glbs, and so on, there's nothing blocking extensions from doing that. (I
>>>> understand glXF tries to specify that as separate format but still don't
>>>> fully understand why)
>>>>
>>>> We are adding extensions wherever we can, improvements welcome.
>>>>
>>>>
>>>>
>>>> Added: glTF Khronos-approved Extensions Registry is available at *https://github.com/KhronosGroup/glTF/blob/main/extensions/README.md
>>>> <https://github.com/KhronosGroup/glTF/blob/main/extensions/README.md>*
>>>>
>>>>
>>>>
>>>> Leonard Daly
>>>>
>>>>
>>>>
>>>> Michalis thank you for your note. Please be assured we that we have
>>>> zero desire to overstate or incorrectly characterize anything. Our
>>>> previously sent draft did not receive any responses. You saw our best
>>>> effort update to it. Happy to continue improving. Can we meet during this
>>>> Friday’s meeting?
>>>>
>>>>
>>>>
>>>> Thanks, Don
>>>>
>>>>
>>>>
>>>> Search for my handheld device
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> *From:* Michalis Kamburelis <michalis.kambi at gmail.com>
>>>> <michalis.kambi at gmail.com>
>>>> *Sent:* Tuesday, September 6, 2022 6:47:04 AM
>>>> *To:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>>>> <brutzman at nps.edu>
>>>> *Cc:* X3D Public Mailing List (x3d-public at web3d.org)
>>>> <x3d-public at web3d.org> <x3d-public at web3d.org>
>>>> *Subject:* Re: [x3d-public] X3D Working Group Minutes, 2 SEP 2022: X3D
>>>> glTF feature comparison
>>>>
>>>>
>>>>
>>>> NPS WARNING: *external sender* verify before acting.
>>>>
>>>>
>>>> Hello,
>>>>
>>>> I read the
>>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2F1x0DnRtg33AuOA_aSl70L41Gq5m6TFt4t%2Fedit%23gid%3D1010586376&data=05%7C01%7Cbrutzman%40nps.edu%7Cb04d8dc972cb4f8430be08da900e5efe%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637980688655942200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IqmTBR8XcyQT4f3uVk0Gp8rJJb7PvLoB7PcnVg5kiqw%3D&reserved=0
>>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2F1x0DnRtg33AuOA_aSl70L41Gq5m6TFt4t%2Fedit%23gid%3D1010586376&data=05%7C01%7Cbrutzman%40nps.edu%7Cda60c5a36b2b4caf4a4f08da91f0d9ef%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637982762822205320%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=9LP0xGTWczl6oqr%2Bub7r4wI8Tiv8gNp9vMW7Lsb0138%3D&reserved=0>
>>>> and have a number of comments. (sorry -- this is another of Michalis'
>>>> long emails :) ).
>>>>
>>>> My main objections are to the initial sections "Value Proposition" and
>>>> "Technology Comparison Summaries". To be frank, a lot of the content
>>>> there seems to be written with the mindset "X3D is better than glTF,
>>>> so let's list all the ways how it is better". Some statements are
>>>> unclear (and the lack of clarity seems to suggest that X3D is better),
>>>> some are just untrue IMHO. To be clear, in my opinion, indeed X3D
>>>> *has* some strengths over glTF, and same goes for the other way
>>>> around, glTF did some stuff better than X3D.
>>>>
>>>>
>>>>
>>>> addressed
>>>>
>>>>
>>>> A fair comparison of X3D vs glTF would be helpful (I have written it
>>>> myself too, but never published :) ). But the table above is not very
>>>> fair, it tries to push the agenda "X3D is better" a bit too much. Let
>>>> me point out what I think should be improved:
>>>>
>>>>
>>>>
>>>> Addressed, this is not about “who is better” but rather noting
>>>> tremendous overlap and interoperability.
>>>>
>>>>
>>>> 1. "Value Proposition" - in general, the goals listed for X3D are
>>>> broad (wide variety of applications...), while the goals and use-cases
>>>> listed for glTF are narrow (efficient transmission, appropriate if you
>>>> want to view in web browser).
>>>>
>>>> This does not reflect reality in my experience. Neither does it
>>>> reflect glTF mission statements at the beginning of
>>>> https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html "glTF is
>>>> an API-neutral runtime asset delivery format. glTF bridges the gap
>>>> between 3D content creation tools and modern graphics applications by
>>>> providing an efficient, extensible, interoperable format for the
>>>> transmission and loading of 3D content.".
>>>>
>>>> The practical fact, IMHO, is that glTF is here exactly like X3D. It's
>>>> just a format for 3D models, it can be used with a variety of
>>>> applications, on any platforms (certainly not only to view the models
>>>> in web browser; e.g. game engines, including Castle Game Engine, allow
>>>> to use glTF as 3D model format on desktops).
>>>>
>>>> So I would suggest to place there the glTF statement I cited above
>>>> ("glTF is an API-neutral runtime asset delivery format. glTF
>>>> bridges..."), and in general make this section simply honestly state:
>>>> the goals and usecases of X3D and glTF largely overlap. They are both
>>>> open standards for 3D models and can be used in a variety of
>>>> applications, use-cases, platforms.
>>>>
>>>>
>>>>
>>>> All addressed
>>>>
>>>>
>>>> 2. "Technology Comparison Summaries" - in general, statements there
>>>> again suffer from "a bit unclear, in favor of X3D and disfavor of
>>>> glTF".
>>>>
>>>> - X3D advantage: "X3D: Full Inline support for glTF features,
>>>> especially compressed geometry plus advanced lighting model planned
>>>> for X3D version 4." - in X3D we have it, but it is not complete as
>>>> this statement suggests. In particular we don't yet have in X3D spec
>>>> any way to specify binary per-vertex data or "compressed geometry".
>>>> This is a work in progress, with some browser-specific extensions, not
>>>> more yet (https://github.com/michaliskambi/x3d-tests/wiki/Binary-meshes
>>>> ). We have not yet figured out how 100% of glTF features express as
>>>> X3D (as I say explicitly on
>>>> https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D
>>>> ).
>>>>
>>>> I would suggest to change it to "X3D: Inline support for many glTF
>>>> features, especially advanced physically-based materials."
>>>>
>>>> Agreed, revised as two lines:
>>>>
>>>>
>>>>
>>>> X3D: full Inline support for glTF rendering features, especially plus
>>>> advanced lighting model planned for X3D version 4.
>>>>
>>>> X3D native nodes directly corresponding to glTF compressed geometry not
>>>> supported, but Inline loading of glb models is supported.
>>>>
>>>>
>>>>
>>>>
>>>> - "glTF: Transmission format designed for applications rendering using
>>>> WebGL or OpenGLES." This tries to suggest that glTF usefullness is
>>>> narrow. It is in conflict with actual glTF statement I cited above,
>>>> "glTF is an API-neutral runtime asset delivery format.". glTF makes
>>>> sense regardless if you use WebGL or OpenGLES. Yes, it used some
>>>> constants / naming from WebGL / OpenGLES, but it's fully implementable
>>>> and understandable in the context of any graphics API - including e.g.
>>>> Vulkan and Direct3D.
>>>>
>>>> I would suggest to change it to "glTF is an API-neutral runtime
>>>> asset delivery format."
>>>>
>>>> fixed
>>>>
>>>>
>>>> - "glTF: Always changing to support the fast changing GPU, a delivery
>>>> system for highly optimized mesh data for rendering." - not true, or
>>>> at least unclear statement. glTF is not "always changing". They care
>>>> about backward compatibility a *lot* and glTF 2.0 has been stable for
>>>> many years, without any breaking changes.
>>>>
>>>> I would suggest to just remove this statement.
>>>>
>>>> Yes, fixed
>>>>
>>>>
>>>> - "glTF: Backward compatibility, archivability, are not listed as
>>>> specification goals." - not true. In practice, of course they care
>>>> about backward compatibility. And it is mentioned in spec explicitly:
>>>> https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#versioning,
>>>> "Any updates made to the glTF Specification in a minor version MUST be
>>>> backward and forward compatible....."
>>>>
>>>> I would suggest to change this statement: "glTF: Backward
>>>> compatibility is addressed by the spec, any updates made to the glTF
>>>> Specification in a minor version MUST be backward and forward
>>>> compatible."
>>>>
>>>> Added your first sentence, fixing prior entry. Also handled by support
>>>> for extensions.
>>>>
>>>>
>>>> 3. "Picking (touch/over TouchSensor, PickableGroup)" - glTF should
>>>> have "No". (So this part is wrong in favor of glTF). There's work to
>>>> introduce such features on top of glTF, but glTF spec does not have
>>>> it.
>>>>
>>>>
>>>>
>>>> corrected
>>>>
>>>>
>>>> 4. "Clipping planes" - glTF should have "No".
>>>>
>>>>
>>>>
>>>> corrected
>>>>
>>>>
>>>> 5. "Metadata Structures" - glTF does have it, in much the same way as
>>>> X3D.
>>>>
>>>> - Essentially anything can have additional information, with key-value
>>>> or deeper structure:
>>>>
>>>> https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#reference-extras
>>>>
>>>>
>>>> . This is quite similar in practice to how X3D MetadataXxx nodes are
>>>> used.
>>>>
>>>> - There's also "asset" for per-file properties:
>>>> https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#asset . This
>>>> is quite similar to common usage of X3D "META" statements.
>>>>
>>>>
>>>>
>>>> fixed
>>>>
>>>>
>>>> - And the "extras" are mentioned above are really used in practice.
>>>> Blender exports Blender's "Custom properties" to glTF "extras". (Which
>>>> is actually better than Blender->X3D exporter, that doesn't write X3D
>>>> MetadataXxx, although it could.)
>>>>
>>>>
>>>>
>>>> Yes, added/fixed
>>>>
>>>>
>>>>
>>>> 6. "Inline" - this is correct, glTF doesn't have it. But you can
>>>> mention https://github.com/KhronosGroup/glXF -- it's not yet
>>>> officially endorsed, but it's an idea to address exactly this, i.e.
>>>> compose world from multiple glTF files.
>>>>
>>>>
>>>>
>>>> Changed “?” to No, discussions have begun
>>>>
>>>>
>>>>
>>>> 7. Let me add some things I consider missing to have a good picture:
>>>>
>>>> "Efficient representation of mesh in binary format"
>>>> X3D: not (yet!)
>>>> glTF: yes
>>>>
>>>>
>>>>
>>>> added
>>>>
>>>>
>>>> "Cubemap textures, including generated cubemaps"
>>>> X3D: yes
>>>> glTF: no
>>>>
>>>> added
>>>>
>>>>
>>>> "Lights"
>>>> X3D: yes
>>>> glTF: not in core spec (but in extensions)
>>>>
>>>> added
>>>>
>>>>
>>>> "Environmental effects, like fog and background"
>>>> X3D: yes
>>>> glTF: no
>>>>
>>>> added
>>>>
>>>>
>>>> "Full-featured and actively maintained Blender exporter, with support
>>>> for PBR materials, animations, skinned animations"
>>>> X3D: not (yet!)
>>>> glTF: yes
>>>>
>>>> Agreed in principle but not suitable for table
>>>>
>>>>
>>>> Regards,
>>>> Michalis
>>>>
>>>>
>>>> Got it!
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20220909/85f4da42/attachment-0001.html>
More information about the x3d-public
mailing list