[x3d-public] Flattening Scene Graph

[Michalis Kamburelis]

First of all, I'm sorry for the long mail. This *is* the abridged
version, trust me:) This thread has turned into *the* most important
discussion about X3D for me, and the answers will heavily influence
the future focus of my game engine, so it's very important to me.

2017-04-27 23:30 GMT+02:00 Leonard Daly <Leonard.Daly at realism.com>:
> There seems to be a misunderstanding today. In the last two email replies to
> earlier message there is the statement that (quoting from this email) "X3D
> ... delegate it's core job... to glTF". This is not the case. I do not see
> glTF as replacing scene integration, management, and interaction. I do see
> glTF being used to provide models that are integrated into the scene.

We have a different idea about what the "core feature" of X3D is. That
is why I always tried to emphasize that I'm talking about "core idea
for my use-case".

To summarize:

1. For my use-case, the core feature of X3D is it's ability to define
an animated 3D geometry with advanced graphic effects. Materials,
shaders, textures, animations. These are the things that you propose
to delegate to glTF, if I understand you correctly.

2. For you, the core feature of X3D is scene integration, management,
and interaction. For me, my engine can do these tasks on top of X3D,
so I don't see them as a core X3D job. It is very comfortable if I can
do these things in X3D too, but it's only an "extra".

  E.g. my engine has a powerful API that allows complete flexibility
in how you operate on the assets "from the outside". As such, Script
within X3D is for me a "nice feature to have", but not something
essential, most games logic works without it.

  As for transformation hierarchy: my engine has a scene hierarchy.
And glTF would give me another transformation hierarchy (glTF has
"nodes" for this purpose). So if I already have my engine + glTF, then
I don't need X3D anymore to define (another) way to group and
transform stuff.

I'm absolutely aware that neither of our points of view is "better".
We just expect different things from X3D, I have my needs ("my
use-case"), and you have yours. That is understandable.

>From me, this discussion may be the most important discussion I had
about X3D since a long time. Because it may mean that X3D 4.0 is no
longer useful for me engine, which really changes my future priorities
substantially.

> The Consortium did not have an official statement excluding games, but it
> was mentioned all the time in presentations and other discussions about the
> target verticals. The main reason games were excluded was the Consortium did
> not want to get into meeting high-performance rendering and response
> requirements necessary for many games, especially first-person shooter ones.

I wish I knew about this unofficial position, so that I could oppose
it: X3D is already in an area where it needs to meet high-performance
rendering. Whether you include or exclude games does not matter. If
you want to visualize non-trivial 3D models, if you want to use latest
GPU techniques to visualize them and achieve realistic lighting...
then you're already doing what games are doing. And yes, X3D 3.3 is
already mostly doing it. (And where it's missing some features, it's
being extended, like CommonSurfaceShader from Instant Reality or my
shadows extensions.)

There is really no difference between "games" and "3D visualizations
working with non-trivial animated models, and simulating realistic
lighting and reflections, in real-time". If you have one, you have the
other. If you stop supporting one in X3D, you also stop supporting the
other.

On a personal note, I also wish that someone told me years ago, when I
announced a game engine using X3D (on this list, in 2009), that
"""VRML / X3D is not for games. The current standard versions may work
for you, but it may change in the future.""" . This is the first time
I hear that games are not in the scope of X3D.

If the direction of X3D 4.0 is like you propose (relying on glTF for
geometry and animation description), then a lot of things I did during
recent years was a waste of my time. Instead of caring about X3D
correctness, and extending X3D with the features I need, I could have
just ignored X3D format, and focus on integrating my engine perfectly
with glTF (or Collada, in the earlier years). It is stressful for me
to think that all this time I was working with incorrect priorities,
but if I was, I would like to know about it as soon as possible, so
that I can change my priorities for future work.

So, in this context, I am *very* interested to know what are X3D plans
for the future.

I emphasize that I understand your point of view of X3D. And if I had
bad priorities, then it's my own fault for not asking where X3D is
going.  But I very much want to update my priorities, to be optimal :)
For this, I would like to know (in general) future plans of X3D.

> A major revision is a good time to do a review of all features to
> make sure they are really required AND and expressed correctly for optimal
> use in the future.

I absolutely agree that some simplifications can be made to X3D. I
even proposed some in this thread (ComposedTexture3D and
ComposedCubeMapTexture could be removed, MultiTexture could be removed
in favor of CommonSurfaceShader...). I'm sure that we could browse X3D
and find many more removals that would be acceptable.

But your proposal is too drastic in my view. Delegating all the
non-trivial geometry and texture setup to another 3D format is a very
drastic simplification. To say it directly, it simplifies X3D into
something useless for my purposes. I don't have a need for a format
that only wraps lower-level assets (like glTF) into a higher level
view, for this I have my existing scene management in Castle Game
Engine.

Best regards,
Michalis