[x3d-public] X3D meeting minutes 9 SEP 2022: X3D glTF feature comparison, continued
Michalis Kamburelis
michalis.kambi at gmail.com
Fri Sep 9 11:18:32 PDT 2022
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/28d1e8ad/attachment-0001.html>
More information about the x3d-public
mailing list