<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Michalis,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.
<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
</div>
<blockquote type="cite"
cite="mid:CAKzBGZPDziyBJk=mwh7aH2L1vZDj7Y-yjd4t0cohsJLBf=OY2w@mail.gmail.com">
<pre wrap="">Leonard Daly <a class="moz-txt-link-rfc2396E" href="mailto:Leonard.Daly@realism.com"><Leonard.Daly@realism.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.]
</pre>
</blockquote>
<pre wrap="">
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
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>