[x3d-public] V4.0 Open discussion/workshop on X3D HTML integration

[Leonard Daly]

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.

tl;dr

    X3D needs to run in the HTML5/DOM environment. A few nodes need to
    be removed, but all capabilities remain.

    Preliminary proposed V4 document at:
    http://tools.realism.com/specification/x3d-v40


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?

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.

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.

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.

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.

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.

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.

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.


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.

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.

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.


-- 
*Leonard Daly*
3D Systems & Cloud Consultant
X3D Co-Chair on Sabbatical
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/20160607/25949747/attachment.html>