<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>
To compare X3D's runtime with glTF is not an appropriate
comparison. It has nothing to do with the heaviness or lightness
of X3D's runtime, but the fact that glTF does not have one. <br>
<br>
If the work flow is to ingest models and make modifications, then
the runtime capabilities are irrelevant to the extent that those
capabilities do not impose requirements on the importing tool. <br>
<br>
Since the addition of components of a profile is strictly a
browser choice, it does not have any place in a comparison of
specifications. This comparison was not to establish test cases
for bench marking various browser that support glTF or X3D (or
both). This was strictly a comparison of features that are in the
specification.<br>
<br>
If you want to see a comparison of browsers please feel free to go
ahead and design and do the testing. It is beyond my available
time right now.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
<br>
</div>
<blockquote type="cite"
cite="mid:CAKzBGZMJipw1X1CXu0ny_NW1Fa5NRfyh8sPzQX0Y2==-mwidHA@mail.gmail.com">
<pre wrap="">2017-09-21 23:40 GMT+02:00 Leonard Daly <a class="moz-txt-link-rfc2396E" href="mailto:Leonard.Daly@realism.com"><Leonard.Daly@realism.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Since higher level X3D
Profiles include a lot of run time and glTF does not include any, it would
not be a fair comparison -- it wouldn't even be relevant. Someone might need
to work in a specific environment which would preclude X3D's runtime.
</pre>
</blockquote>
<pre wrap="">
But an X3D browser can implement the parts of X3D responsible for the
missing features (vs glTF, in your table) without "a lot of run time".
I know that it's more-or-less what I'm doing myself (details below).
If you consider some X3D browsers as "heavier" on resources than some
glTF browsers, then you should point and
compare these specific browsers, and mention that browser X (which
happens to use X3D) is heavier on resources than browser Y (which
happens to use glTF). As far as standards go, saying that X3D requires
"heavier runtime" for the same features is not true, in my experience.
I actually do implement in my X3D browser various features that you
list as missing in your table (since they are indeed missing from the
Interchange profile). I'm quite sure that implementing these features
does not make the runtime "heavy", at least not more than implementing
them using glTF would be.
Some details:
- Implementing [Indexed]QuadSet nodes (which is part of CAD component,
and provides "Quad surface model" feature in your table) is very easy,
and it does not require anything special from the runtime. It's just
another geometry node. (Some APIs, like OpenGLES, may not support
quads, but you don't pass polygons from IndexedFaceSet straight as
polygons to OpenGLES either.)
- Using shaders is something that all renderers do already, regardless
if it reads X3D or glTF. Exposing shaders to the X3D author is
relatively easy, and it does not require any "heavy runtime", you just
copy some data from X3D shader nodes to your renderer shaders.
- Implementing animations (using morph and joints) is indeed not
trivial (to do it efficient). But it's the same level of difficulty as
doing it with glTF.
- Implementing bump mapping etc. using X3D CommonSurfaceShader is the
same level of difficulty as implementing these features using glTF.
The input format doesn't really matter here much.
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>