[x3d-public] Flattening Scene Graph

[Michalis Kamburelis]

2017-04-27 17:56 GMT+02:00 Leonard Daly <Leonard.Daly at realism.com>:
> 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.

I wasn't aware that games are excluded from X3D scope? Is it really
said anywhere officially?

I've been using VRML 1.0, then VRML 2.0, then X3D, to make my games.
VRML and X3D are excellent formats to interchange 3D data for me.
"Rich" 3D data, that includes not only rendering and animation, but
also interactions and scripting. Sure, I do miss some features in X3D
(I wrote about them recently in a thread "X3D features missing, but
desired, by a game engine"), but they are not really "game-specific
features". They are better described as "modern rendering features",
and I think that other use-cases miss them too.

I know that back in the old says, the initial VRML 1.0 designers
planned that it's mainly for integration with HTML, but times have
changed, and I understood that the current mission of X3D is to be a
standard for 3D graphics interchange, in *addition* to being
integrated with HTML5. So far, these goals did not collide. X3DOM is
cool, and it works with the current X3D scene graph.

As far as I understood, the change of VRML meaning from "Virtual
Reality Markup Language" to "Virtual Reality Modeling Language" was
also a statement from the specification authors that "we're not
concerned only about HTML, we're concerned about interchange of 3D
data, and HTML is just one use-case".

Reading documents like
http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development also
makes me happy, as I see that a lot of work is being spent on keeping
backward compatibility, and adding new features.

This all stands somewhat in contrast to your proposition to "cut down"
X3D and essentially delegate it's core job (at least, "core" for my
usecase) to glTF.

Bottom line: as far as I'm concerned, X3D doesn't need to have "games"
in it's scope explicitly. For my purposes, it only needs to be a
complete and open standard to interchange 3D data. On top of this, I
can build a game engine easily:)

> 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).

Indeed, people import models in various formats. The X3D Inline node
does an excellent job by allowing this already, and my own engine
allows to mix asset formats this way already (
https://castle-engine.sourceforge.io/x3d_extensions.php#section_ext_inline_for_all
). I remember that you already proposed adding support for other
formats to the Inline node in an earlier thread, and I applaud that
(as long as we choose formats carefully, preferably ones with good and
open specifications, like glTF).

But this doesn't mean that X3D itself cannot serve as a
self-sufficient interchange format.

In fact, that's how I was using X3D for years. Do some work in
Blender, export to X3D, load in the engine.

<sidenote>
The most popular interchange format of Unity3d and Unreal Engine is
FBX, in practice. There are other loaders (in principle, you can load
any format, since you can just write C# code to do it), but FBX
remains the advised one. Which is really unfortunate, as FBX is a
closed format (Autodesk deliberately refuses to publish it's
specification). I with it was replaced with something with a proper
open standard, like X3D or glTF or Collada.

That's one part where I hope my engine could shine, by using open standards.
</sidenote>

Regards,
Michalis