[x3d-public] Flattening Scene Graph

[Leonard Daly]

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. This is the way it is done in Unity, Unreal, 
film, TV, CryEngine, Lumberyard, etc. There will be times when the 
geometry absolutely needs to be a fully part of the scene graph. If the 
geometry is getting changed based on user or other non-pre-determined 
manner, than use of a format like glTF won't work.

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.

Note that in the Wiki document you reference there is the statement 
"Note that it is not a requirement that all features and capabilities in 
X3D V3.3 are included in V4.0" and "Our goal is to maximize, but not 
necessarily require, backwards compatibility in version 4.0 with the 
version 3.x specifications". X3D is by nearly all measures a large 
language. Many people consider it too large (or at least the language 
size is a high barrier for entry). 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.

If X3D is strictly to be an archive format, then it makes sense to 
monotonically grow the language. If X3D is to function as a run-time, 
then it makes more sense to be as lean as possible. The answer to the 
future of X3D is someplace in the middle.


Leonard Daly


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

-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170427/ef99e0c0/attachment.html>