[x3d-public] motivations and potential renaming of OM4X3D as X3D Unified Object Model (X3DUOM)

[Michalis Kamburelis]

Leonard Daly <Leonard.Daly at realism.com> wrote:

> We know that incremental enhancement is insufficient because
> there is minimal adoption of X3D compared to other standards that have
> been around a shorter amount of time - glTF, WebGL, THREE.js, etc.

Comparison of X3D and glTF is indeed justified. From my point of view,
glTF strengths are:

1. It is developed by Khronos. This gives it a huge boost to "trust",
as Khronos is also responsible for other technologies I use
(OpenGL[ES], OpenCL, KTX,  EGL, Vulkan...). So I know that these are
people who have the skills (and time!) to create (and update!) a good
specification.

2. It has some modern features that X3D lacks. You mentioned bump
mapping and displacement mapping later yourself.

    We have ideas to fix it in X3D, some of them even seem easy:
"just" add CommonSurfaceShader to the X3D specification, and you have
just upgraded your materials to be "modern". But these are just ideas,
not yet part of any X3D specification, while the glTF is something
that exists today and already has it as part of the standard.

3. It is more efficient, using binary data. The X3D does have answers
to this (X3D binary encoding, and more recently the shape containers
and ExternalGeometry ideas). But "X3D binary encoding" is not popular
enough (I regret it!), and the shape containers etc. are not yet part
of existing X3D 3.3.

Comparison of X3D standard with WebGL and three.js is not justified,
in my eyes:

- WebGL is a technology to render 3D stuff using JavaScript. It is
used to implement renderers, which may include an X3D or glTF
renderer. X3DOM and CobWeb are doing exactly that with X3D.

- Three.js is a JavaScript library that wraps WebGL. Again, you can
just use it to render X3D or glTF or anything else you like.

The fact that WebGL and Three.js have wide adoption doesn't say
anything about X3D quality, I think. It just says that web
technologies are "hot" now and evolve fast. WebGL and Three.js are
APIs, they do not "fill" the same space that a 3D format like X3D
does.

> 5) Game engines for at least the last 10 years have used an Entity
> Component System (ECS). ECS was developed in the early 2000's because of
> performance issues with handing extensive object hierarchy. ECS is how
> Unity, Unreal, and A-Frame work. It drives their internal data structure
> and run-time. Without some sort of explanation of how X3D can be used in
> an ECS, it will be dismissed by the entire game community. [Note that
> THREE more closely aligns with WebGL and is more object-oriented.]

I don't think X3D will be dismissed just because it doesn't come with
a ready explanation "how to use it from an Entity Component System".
You could accuse glTF, Collada, FBX, or any other 3D format of the same
flaw.

Programmers that want to use Entity Component System can probably
figure out how to do it, and they will most likely treat "X3D scene"
as a higher-level thing, and not be concerned about wrapping every X3D
node inside an ECS component. The specifics how to do it depend on the
exact application.

And BTW,

- Unity3d is not a "true" Entity Component System. Indeed, you can
wrap it in ECS, or you can create your own "systems" to operate on
Unity3d components. But most people just put the code in
MonoBehaviours, which is not ECS at all.

- Unreal Engine is further from ECS, as it uses class inheritance for
some key concepts. Just because you have something called "component"
in your API doesn't mean that you're an ECS :) Again, you can wrap
Unreal Engine in an ECS, if you want.

Bottom line: OOP is not dead yet :), and it's certainly not clear
whether it's optimal to convert *all* our APIs to use ECS approach.
You can use ECS to "wrap" any other API (like Unity3d, Unreal, or any
API exposing X3D scenes).

Regards,
Michalis