[x3d-public] X3D meeting minutes 9 SEP 2022: X3D glTF feature comparison, continued
John Carlson
yottzumm at gmail.com
Fri Sep 9 10:54:17 PDT 2022
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220909/084ab883/attachment-0001.html>
More information about the x3d-public
mailing list