<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>
Thanks for the confirmation. I am not a complete advocate of scene
graph flattening, but I did want to have a discussion on it so
it's strengths and limitations are understood.<br>
<br>
Something that has been missing from X3D development in a while is
an actual determination of which environment and
industries/applications is X3D targeting. For a long time the
answer was all environments and all applications except games. <br>
Your work has shown that games should not be excluded. To my
knowledge the Consortium has not clarified or revised the
statement on the target platforms/environments or
industries/applications of X3D. This has led to some people trying
to figure out how to define the next generation of X3D (common
called X3DV4) for every possible platform and environment and for
all applications. This is the smooth peanut butter approach --
spread it smooth (and thin) to make sure everything is covered.
That doesn't work when you are trying to build market share.<br>
<br>
My efforts have been getting X3D to work in the browser
environment. I am looking at what is necessary to make adoption
easier for people already working in similar existing (e.g., Unity
and Unreal) and developing (A-Frame) environments. In all of those
environments people regularly import models from a large variety
of sources, including glTF, FBX, and OBJ. The environment provides
the glue that holds everything together and handles the
interaction between the various elements of the scene and
surrounding environment (in my case, the web page).<br>
<br>
Formats like glTF (and its predecessors SRC and PopGeometry from
Fraunhofer) were designed to ease the importation of large models
into the GPU by doing the preprocessing once. glTF is planned to
be included in V4 much like JPEG is used as an image format.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
</div>
<blockquote type="cite"
cite="mid:CAKzBGZONDWg3Stg_jksj4K5==gEibP04MwzW3URaW+cFMfZd_g@mail.gmail.com">
<pre wrap="">2017-04-26 16:37 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="">Michalis,
You did hit on the difficultly of expressing geometry or complex texture in
a single node. This is certainly the case when you are using a model in X3D
(as opposed to glTF or other model format). What if there was a requirement
that Mesh only supported simple models and textures and anything complex
needed to be referenced by URL (to a non-X3D file). The external file could
also include internal animation of the model (e.g., pistons, wheel, walk,
run, jump, etc.)
</pre>
</blockquote>
<pre wrap="">
It would mean that for my (Castle Game Engine) purposes the X3D
standard would no longer stand on it's own. If I would need to combine
X3D with some other 3D format, like glTF, to get the features I need,
then... in practice I would just focus on glTF.
To give a little background: I'm making a game engine, integrated with
any 3D authoring tool (like Blender) by supporting many asset formats
(like X3D), running on any platform (desktop, mobile, web), and also
using X3D as a complete scene graph.
Right now, I *can* combine X3D with other formats (e.g. using Inline),
but it's my choice if (and how) I do it. For example, my Collada, MD3,
Spine, OBJ, STL... importers right now just convert everything to X3D
nodes. Right now, I can do it, because X3D is a powerful scene graph
describing everything I need. This would change. The format you
propose would no longer be a useful (complete) scene graph for me, it
would only be a start.
Also the exporters would need to adapt. Blender's exporter to the
format you propose would likely need to use glTF exporter internally
too.
Since glTF can express animations, shaders, texture coordinates... in
many cases, I would actually not need X3D. The primary focus of the
engine would be the glTF format. X3D would still add interactivity to
glTF models, and allow to group and reuse them... but I don't really
need X3D for this. E.g. for scripting, we have a nice object-oriented
API in our modern Object Pascal to do all kinds of interactive things
with assets. This can be invoked from X3D Script, but it can also work
from the outside of the X3D Script, loading and unloading and
organizing whatever assets it needs.
In other words, it would (from my usecase) make the (new) X3D much
less useful. The glTF becomes the powerful format then, and X3D is
then only an optional wrapper around glTF.
Let me be very clear: Your design is elegant, and I can see where
you're going. Your design is coherent. I asked "How do you deal with
complicated geometry?", and your answer "You delegate it to an
external file" is an absolutely reasonable answer. But for me, it is
also something different than X3D, it does not fill my need (unlike
the current X3D). The new format would be something to manipulate the
3D assets expressed in other files. I need a format to actually define
these assets.
</pre>
<blockquote type="cite">
<pre wrap="">You also brought up accessing various subparts of mesh that are current
existing nodes (e.g., reusing Appearance, Geometry, Coordinate, etc.). The
current standard when modeling (*) is to create a complete model for each
non-repeated instance. The parts that may be reused (texture, animation)
could be represented as the equivalent of CSS classes and reused between
instances of Mesh. For example
.texture-color {diffuse:orange; specular:blue; }
.texture-ball {appearance: hard-surface.shader; }
.texture-plush {appearance: fuzzy-surface.shader; }
</pre>
</blockquote>
<pre wrap="">
Aha, sharing like CSS. I can see that it's elegant, if the emphasis is
on having similar concepts as HTML.
Best 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>