[x3d-public] Flattening Scene Graph

[Michalis Kamburelis]

2017-04-26 16:37 GMT+02:00 Leonard Daly <Leonard.Daly at realism.com>:
> 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.)

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.

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

Aha, sharing like CSS. I can see that it's elegant, if the emphasis is
on having similar concepts as HTML.

Best regards,
Michalis