[x3d-public] V4.0 Open discussion/workshop on X3D HTML integration
Leonard.Daly at realism.com
Tue Jun 7 21:29:35 PDT 2016
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.
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:
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
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.
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...
More information about the x3d-public