[x3d-public] X3D meeting minutes 9 SEP 2022: X3D glTF feature comparison, continued
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Fri Sep 9 10:44:15 PDT 2022
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-i
nternational-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-animatio
n-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
<mailto: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
<mailto: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 <mailto: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
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 <mailto:michalis.kambi at gmail.com>
<michalis.kambi at gmail.com>
Sent: Tuesday, September 6, 2022 6:47:04 AM
To: Brutzman, Donald (Don) (CIV) <mailto:brutzman at nps.edu>
<brutzman at nps.edu>
Cc: X3D Public Mailing List (x3d-public at web3d.org
<mailto:x3d-public at web3d.org> ) <mailto: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.googl
e.com%2Fspreadsheets%2Fd%2F1x0DnRtg33AuOA_aSl70L41Gq5m6TFt4t%2Fedit%23gid%3D
1010586376
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.goog
le.com%2Fspreadsheets%2Fd%2F1x0DnRtg33AuOA_aSl70L41Gq5m6TFt4t%2Fedit%23gid%3
D1010586376&data=05%7C01%7Cbrutzman%40nps.edu%7Cda60c5a36b2b4caf4a4f08da91f0
d9ef%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637982762822205320%7CUnkno
wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
6Mn0%3D%7C1000%7C%7C%7C&sdata=9LP0xGTWczl6oqr%2Bub7r4wI8Tiv8gNp9vMW7Lsb0138%
3D&reserved=0>
&data=05%7C01%7Cbrutzman%40nps.edu%7Cb04d8dc972cb4f8430be08da900e5efe%7C
6d936231a51740ea9199f7578963378e%7C0%7C0%7C637980688655942200%7CUnknown%7CTW
FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
%7C3000%7C%7C%7C&sdata=IqmTBR8XcyQT4f3uVk0Gp8rJJb7PvLoB7PcnVg5kiqw%3D&am
p;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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220909/5baad721/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FeaturesComparisonX3D4glTF2.pdf
Type: application/pdf
Size: 92189 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220909/5baad721/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5353 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220909/5baad721/attachment-0001.p7s>
More information about the x3d-public
mailing list