<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">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.<br>
<br>
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.<br>
<br>
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. <br>
<br>
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. <br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
</div>
<blockquote type="cite"
cite="mid:CAKzBGZNN5gRk8YRMKE_2Fa1j10VGtJ1B-Nhf8HLA3vVxmzV4Lg@mail.gmail.com">
<pre wrap="">2017-04-27 17:56 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="">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.
</pre>
</blockquote>
<pre wrap="">
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
<a class="moz-txt-link-freetext" href="http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development">http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development</a> 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:)
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">
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 (
<a class="moz-txt-link-freetext" href="https://castle-engine.sourceforge.io/x3d_extensions.php#section_ext_inline_for_all">https://castle-engine.sourceforge.io/x3d_extensions.php#section_ext_inline_for_all</a>
). 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
</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>