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

[Michael Aratow]

Leonard

Thank you for that concise, clear and pragmatic summary of a possible 
bright future for an X3D V4.

 From a user and business standpoint, your approach puts X3D out in 
front and provides a path towards wide adoption and sustainability.

I fully support your strategy.

Mike Aratow

Member of the Board and Co-Chair Medical Working Group

On 6/7/16 9:29 PM, Leonard Daly wrote:
>
> 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/
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160608/cfe924c1/attachment.html>