[x3d-public] X3D meeting minutes 9 SEP 2022: X3D glTF feature comparison, continued
John Carlson
yottzumm at gmail.com
Fri Sep 9 11:59:12 PDT 2022
Fairly recent info on KHR_audio extension:
https://github.com/KhronosGroup/glTF/pull/2137
Enjoy!
John
On Fri, Sep 9, 2022 at 1:51 PM John Carlson <yottzumm at gmail.com> wrote:
> 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/18dc26ef/attachment-0001.html>
More information about the x3d-public
mailing list