[x3d-public] X3D meeting minutes 9 SEP 2022: X3D glTF feature comparison, continued
John Carlson
yottzumm at gmail.com
Fri Sep 9 11:36:46 PDT 2022
I see the link now in Don’s email. Thanks! Yes, channels
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/bbbee72b/attachment-0001.html>
More information about the x3d-public
mailing list