[x3d-public] X3D Working Group Minutes, 2 SEP 2022: X3D glTF feature comparison

Tue Sep 6 06:47:04 PDT 2022

Hello,

I read the https://docs.google.com/spreadsheets/d/1x0DnRtg33AuOA_aSl70L41Gq5m6TFt4t/edit#gid=1010586376
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://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.

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."

- "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://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."

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://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.

- 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://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.

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