<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Leonard</p>
<p>Thank you for that concise, clear and pragmatic summary of a
possible bright future for an X3D V4.</p>
<p>From a user and business standpoint, your approach puts X3D out
in front and provides a path towards wide adoption and
sustainability.</p>
<p>I fully support your strategy.</p>
<p>Mike Aratow</p>
<p>Member of the Board and Co-Chair Medical Working Group<br>
</p>
<div class="moz-cite-prefix">On 6/7/16 9:29 PM, Leonard Daly wrote:<br>
</div>
<blockquote
cite="mid:d2b2d031-fab9-0d74-5422-3a9ebcb229ef@realism.com"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<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
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://tools.realism.com/specification/x3d-v40"><a class="moz-txt-link-freetext" href="http://tools.realism.com/specification/x3d-v40">http://tools.realism.com/specification/x3d-v40</a></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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
x3d-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<br>
</body>
</html>