[x3d-public] X3D Working Group Minutes, 2 SEP 2022: X3D glTF feature comparison
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Fri Sep 9 08:53:16 PDT 2022
Yes, 9 pacific is new recurring meeting time. 7 minutes from now.
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
-----Original Message-----
From: Michalis Kamburelis <michalis.kambi at gmail.com>
Sent: Friday, September 9, 2022 8:08 AM
To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
Cc: X3D Public Mailing List (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.
Don,
I'm at the Zoom meeting for Friday. But I guess I'm in the wrong meeting or
at a wrong hour :)
I visited the Zoom URL from
https://www.web3d.org/member/teleconference-information , and if I check
right -- now is 8 AM in Pacific time in USA.
Did I mix the timezones? Are we meeting in +1 hour?
Regards,
Michalis
śr., 7 wrz 2022 o 08:56 Michalis Kamburelis <michalis.kambi at gmail.com>
napisał(a):
>
> Sure, I can join the meeting this Friday, though I will have to run
> quickly (after 30-45 minutes) to another meeting :)
>
> See you then,
> Michalis
>
> śr., 7 wrz 2022 o 04:59 Brutzman, Donald (Don) (CIV)
> <brutzman at nps.edu> napisał(a):
> >
> > 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>
> > Sent: Tuesday, September 6, 2022 6:47:04 AM
> > To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> > Cc: X3D Public Mailing List (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%2Fdo
> > cs.google.com%2Fspreadsheets%2Fd%2F1x0DnRtg33AuOA_aSl70L41Gq5m6TFt4t
> > %2Fedit%23gid%3D1010586376&data=05%7C01%7Cbrutzman%40nps.edu%7C5
> > 7109b6eb306402b1f0908da92752b39%7C6d936231a51740ea9199f7578963378e%7
> > C0%7C0%7C637983329179244077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&a
> > mp;sdata=7liJnfxo3zUTpklDg5E6mtds0pkzeudvfNgxeCU6L%2FY%3D&reserv
> > ed=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.
> >
> > 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:
> >
> > 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fre
> > gistry.khronos.org%2FglTF%2Fspecs%2F2.0%2FglTF-2.0.html&data=05%
> > 7C01%7Cbrutzman%40nps.edu%7C57109b6eb306402b1f0908da92752b39%7C6d936
> > 231a51740ea9199f7578963378e%7C0%7C0%7C637983329179244077%7CUnknown%7
> >
CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
%3D%7C3000%7C%7C%7C&sdata=FzJln5dgyL4Yvl7ZIgXlkCwuUvfs2OFEIH1JpTx1ZT0%3D
&reserved=0 , "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.
> >
> > 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > thub.com%2Fmichaliskambi%2Fx3d-tests%2Fwiki%2FBinary-meshes&data
> > =05%7C01%7Cbrutzman%40nps.edu%7C57109b6eb306402b1f0908da92752b39%7C6
> > d936231a51740ea9199f7578963378e%7C0%7C0%7C637983329179244077%7CUnkno
> > wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> > iLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FNU2t%2B9HEqK%2BnsfyPnoC%2
> > BjomfjOJ8%2BWoWGRTlDq2SOE%3D&reserved=0
> > ). We have not yet figured out how 100% of glTF features express as
> > X3D (as I say explicitly on
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > thub.com%2Fmichaliskambi%2Fx3d-tests%2Fwiki%2FConverting-glTF-to-X3D
> > &data=05%7C01%7Cbrutzman%40nps.edu%7C57109b6eb306402b1f0908da927
> > 52b39%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C63798332917924407
> > 7%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> > I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eWZE8yAk%2Bt%2FOA
> > MEEEbbnHZ7YnYMq42qfUoRSgEJNsf8%3D&reserved=0
> > ).
> >
> > I would suggest to change it to "X3D: Inline support for many
> > glTF features, especially advanced physically-based materials."
> >
> > - "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."
> >
> > - "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.
> >
> > - "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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fre
> > gistry.khronos.org%2FglTF%2Fspecs%2F2.0%2FglTF-2.0.html%23versioning
> >
&data=05%7C01%7Cbrutzman%40nps.edu%7C57109b6eb306402b1f0908da92752b39%7C
6d936231a51740ea9199f7578963378e%7C0%7C0%7C637983329179244077%7CUnknown%7CTW
FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
%7C3000%7C%7C%7C&sdata=D%2FK7EhED9Xo7pIkZczBXar5PY7ZjHiOJGCMH6cP4FB8%3D&
amp;reserved=0 , "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."
> >
> > 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.
> >
> > 4. "Clipping planes" - glTF should have "No".
> >
> > 5. "Metadata Structures" - glTF does have it, in much the same way as
X3D.
> >
> > - Essentially anything can have additional informatiom, with
> > key-value or deeper structure:
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fre
> > gistry.khronos.org%2FglTF%2Fspecs%2F2.0%2FglTF-2.0.html%23reference-
> > extras&data=05%7C01%7Cbrutzman%40nps.edu%7C57109b6eb306402b1f090
> > 8da92752b39%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C63798332917
> > 9244077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2B%2BZWOSI
> > eFsz%2Fgl5h4tXgdQLfry6oi8DpchEGP7q1Vjc%3D&reserved=0
> > . This is quite similar in practice to how X3D MetadataXxx nodes are
> > used.
> >
> > - There's also "asset" for per-file properties:
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fre
> >
gistry.khronos.org%2FglTF%2Fspecs%2F2.0%2FglTF-2.0.html%23asset&data=05%
7C01%7Cbrutzman%40nps.edu%7C57109b6eb306402b1f0908da92752b39%7C6d936231a5174
0ea9199f7578963378e%7C0%7C0%7C637983329179244077%7CUnknown%7CTWFpbGZsb3d8eyJ
WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
%7C&sdata=mAAFgZ7Bu9JzGiHkRcYPukkECw%2BFaddM%2ByjghfdhdoY%3D&reserve
d=0 . This is quite similar to common usage of X3D "META" statements.
> >
> > - 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.)
> >
> > 6. "Inline" - this is correct, glTF doesn't have it. But you can
> > mention
> >
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com
%2FKhronosGroup%2FglXF&data=05%7C01%7Cbrutzman%40nps.edu%7C57109b6eb3064
02b1f0908da92752b39%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C63798332917
9244077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0eJDsIJbCypxQPpGie%2BylkVe%
2BABuKE0SSrBo5nJD08M%3D&reserved=0 -- it's not yet officially endorsed,
but it's an idea to address exactly this, i.e.
> > compose world from multiple glTF files.
> >
> > 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
> >
> > "Cubemap textures, including generated cubemaps"
> > X3D: yes
> > glTF: no
> >
> > "Lights"
> > X3D: yes
> > glTF: not in core spec (but in extensions)
> >
> > "Environmental effects, like fog and background"
> > X3D: yes
> > glTF: no
> >
> > "Full-featured and actively maintained Blender exporter, with
> > support for PBR materials, animations, skinned animations"
> > X3D: not (yet!)
> > glTF: yes
> >
> > Regards,
> > Michalis
> >
> > sob., 3 wrz 2022 o 01:10 Brutzman, Donald (Don) (CIV)
> > <brutzman at nps.edu> napisał(a):
> > >
> > > Spreadsheet PDF with corrected date (for today) attached.
> > >
> > >
> > >
> > > 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
> > >
> > >
> > >
> > > _______________________________________________
> > > x3d-public mailing list
> > > x3d-public at web3d.org
> > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
-------------- 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/41c6e93b/attachment-0001.p7s>
More information about the x3d-public
mailing list