<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Wednesday (8 June 2016) X3D WG call is dedicated to discussion
X3D V4. Several people (including myself) have commented on the
ideas over the last couple of years. I am going to state my
current position here. I don't think it differs much from my
position a year ago; however, I'm sure there have been some
clarifications.<br>
</p>
<p>tl;dr</p>
<blockquote>
<p>X3D needs to run in the HTML5/DOM environment. A few nodes need
to be removed, but all capabilities remain.</p>
<p>Preliminary proposed V4 document at:
<a class="moz-txt-link-freetext" href="http://tools.realism.com/specification/x3d-v40">http://tools.realism.com/specification/x3d-v40</a><br>
</p>
</blockquote>
<p><br>
</p>
<p>I am going to start my position with a response to a question
asked by John Carlson on a different list (x3dom-users): are we
adding HTML5 capabilities to X3D or 3D (X3D in particular)
capabilities to HTML5?</p>
<p>HTML is the dominant environment world-wide. It provides text,
image, 2D graphics (SVG), video, and other capabilities. The size
of the HTML5 development community far exceeds the total of the
entire X3D community. Forcing HTML5 into X3D is a losing game
right from the start -- whether you want all of HTML5 or just a
portion. So in my mind, the only choice with a future is to add 3D
to HTML5. Running in the HTML5 environment means full integration
with the HTML5 DOM (or later versions when they happen). BTW,
there are already a number of non-Web3D Consortium efforts to do
so. We are not out in front of the effort and are about to be made
irrelevant. There is no more time for delays or debates.</p>
So now that the environment is settled, it is important to identify
what in current X3D (V3.3) is incompatible with HTML5. There are
only three obvious features - Script node, event handling, and case
sensitivity. There are other capabilities that are dependent on
these capabilities -- I'll discuss those later.<br>
<br>
Starting with the easiest one first - case sensitivity. HTML5 is
case insensitive. Relaxing X3D's rules on that allows existing X3D
code to run in a browser. If everything gets converted to lower-case
prior to handling (except quoted strings), then there is not a
problem.<br>
<br>
There is an obvious naming incompatibility with Script -- the name.
HTML5 is already using that name. Under my initial condition there
cannot be an X3D Script node. That does not mean all scripting
functions are given up. HTML5 provides a wonderful script interface
a more flexible structure. In X3D, Scripts are meant to process
events, so the function argument is always an event (except for
X3D-Script internal functions). Functions in HTML5 are a lot more
flexible and can include events, objects, scalars, arrays, etc. So
there is no loss of functionality by giving up X3D-Script.<br>
<br>
Event handling is different between HTML5 and X3D. In X3D events are
"routed" from one node to another. They allow one part of the scene
graph to "talk" to another part. In HTML5, events "bubble-up" from
the originator to the event through any handler that may be attached
to any parent node of the originator until the event is cancelled.
In all of my design work on V4 I have not found any instance where
HTML5-Scripts could not provide the same functionality as
X3D-Script+ROUTE. It requires a little different mind-set, but the
HTML5 mind-set is very familiar to JavaScript programmers and other
front-end developers. I also believe that a graphical development
interface can be built that completely simplifies the differences.<br>
<br>
The biggest issue I have seen with event handling is scene graph
updating. X3D updates the scene graph once all non-looping events in
the cascade have completed. After the scene graph is updated, a new
frame is rendered. This can cause a large delay between rendered
frames. HTML5 renders as it goes. Rendering happens asynchronously
to changes to the DOM. There is no concept of accessing the DOM
before or after all events for that frame. X3D worlds that depend on
that feature will probably not be able to be ported to X3D V4.<br>
<br>
Summarizing the three incompatibilities - with the exception of some
event processing, none will prevent X3D from doing what it currently
can do and all can be easily migrated to the HTML5 environment.<br>
<br>
<br>
There are a number of features that I think should not be included
in X3D V4, but these are just features and not fundamental
capabilities. These include all nodes that generate geometry (e.g.,
Extrusion, ElevationGrid, Text) with the exception of simple solids
and perhaps a couple of additions. My view here is based on the
availability of free modeling software (e.g., Blender) that does all
of the above, and a lot more efficiently than X3D can. Also by not
including these nodes, the resultant models will look better.<br>
<br>
Lastly (for now), I believe that there is no purpose for a PROTO
node. Without a X3D-Script node, PROTOs just become convenience
generators. To replace that feature, I am proposing a MACRO node
that takes X3D and does string substitution prior to inserting the
result into the scene graph (and DOM). I have a partial
implementation of this for X3DOM. <br>
<br>
Summarizing: The Consortium needs to get out and lead the way for 3D
on the web (and this includes VR) or it will be by-passed and left
with the relics of history like blinking text, and Flash. The
environment must be HTML5/DOM and X3D must stay current with the web
environment. There will always be someone who needs something
specialized that does not use a web environment, but those will be
individual cases and not worth significant volunteer efforts.<br>
<br>
<br>
<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>
X3D Co-Chair on Sabbatical<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>