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

[Leonard Daly]

Michalis,

I had included WebGL and THREE to be complete in the stack, not to say 
that they are equivalent to X3D. As you noted the closer match is glTF 
and A-Frame, though these are not exact matches either. That said, it is 
bad to dismiss the popularity of (especially) THREE and the features it 
provides for the JavaScript developer.

SRC support and developed in X3DOM has been dropped by Fraunhofer in 
favor of glTF. Unfortunately, X3DOM's glTF importer does not handle 
multi-mesh files (and several other features). X3D Binary Encoding is 
not equivalent to glTF. It does not store mesh data in a GPU-loadable 
format -- SRC and glTF do.

When doing research on ECS, I found that there is no "true" ECS game 
system. There is still stuff that needs to be handled via some sort of 
hierarchy and the System part would probably have performance issues. 
The perception is still there that Unity and Unreal are ECS. I was not 
advocating X3D switch to ECS, just that there be some explanation as to 
how to use X3D in that type of environment. A lot of adoption has to 
deal with perception. The descriptions I have seen of ECS allow them to 
contain structures that internally may not be ECS, but are wrapped up as 
an entity with selected components. This is the theoretical model I 
understood is used to import from FBX, glTF, OBJ, etc.

The biggest issue with X3D and ECS is the specification run-time. It is 
very detailed and clear (at least to me) about how an X3D scene is 
suppose to evolve over time. It is only an ECS model if you take "S" to 
be everything. This may be a good time to separate out the static X3D 
scene description from the X3D scene run-time.


Leonard Daly



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

-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170820/b345d410/attachment.html>