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

[John Carlson]

The good stuff is at the very end.

> On Jun 8, 2016, at 12:29 AM, Leonard Daly <Leonard.Daly at realism.com> 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 <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.
> 
I think the only DOM items that are required are canvas and script.  These can be moved to X3D if name conflicts are resolved.

> 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.

Did you just throw out Cobweb which runs successfully in several browsers?


> 
> 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.

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.

Linkage of Scripts with ROUTEs is given up.   Data binding has to be reinvented, or borrowed.  Cobweb has shown that Scripts can be available in HTML5 browsers.

> 
> 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.

Agreed.

> 
> 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.
> 
What does WebGL do separate from HTML5?  We really need to find out what WebGL/Canvas does before jumping straight into DOM and HTML5.

> 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. 

I don’t think we should spend effort generating our our implementation of templates, unless done for efficiency.   Underscore, handlebars, meteor, angular, mustache  etc all present templating frameworks which are likely highly superior to MACROs at this point.  If all we are doing is manipulating DOM, we should use developed frameworks that other developers use, not invent our own templates.  If we are manipulating WebGL, then we should look at the WebGL or GL frameworks for what is done with templating.  Has anyone googled webgl templating or webgl macros?  Is that what we are ultimately doing, providing WebGL macros?
> 
> 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.

I believe our focus should be on providing a good component library or framework or integrated with an existing DOM templating system(s) as examples.   My favorite is D3.js, but it may be too JavaScript heavy for some users.  D3.js also leverages several extendable data models for tables, trees and graphs.  I think these should be leveraged to show that capabilities can be quickly built up to build apps.  We should make *H-Anim* and geo work well on the web.  My gut is saying don’t build our own templating system.  I think we should use existing data mechanisms (JSON ala meteor templates) to provide data to the templating system.  If we want to provide a way to send XML and WRL to a templating system, this should be investigated, but no one will likely use it (I think everyone has moved to REST/JSON).  If we can’t use X3DOM and Angular together, then perhaps that problem needs to be investigated with the Angular team.

For a not perfect sample of Meteor 1.2’s templating system with X3DOM look at the bottom of the following link.   {{ }} is what gets replaced, and the new tag is <template> and there are loops.

https://github.com/coderextreme/jsondemons/blob/master/client/jsondemons.html <https://github.com/coderextreme/jsondemons/blob/master/client/jsondemons.html>

I too believe that DOM should be used as the lingua franca in the short term, and if people need more performance, they can move to WebGL, PlayCanvas and Three.JS.  I think JSON may be superior in speed to DOM however (run some tests?), and we should investigate a WebGL X3D JSON Loader that skips DOM.


http://psteeleidem.com/the-javascript-templating-landscape/ <http://psteeleidem.com/the-javascript-templating-landscape/>

Here’s are the options of things to focus on:

1.  Providing declarative abstractions for the graphics card, since WebGL exposes the graphics card.  This means fragment shader, textures, lighting and materials. (CSS4+images+canvas)
2.  Provide a barebones structure for the scenegraph.  transforms OR groups, but not both. (DOM)
3.  Provide ways to generate simple generic geometry to build objects, like spheres which can be used by shaders, with configurable # of faces.  The surfaces can be manipulated with vertex shaders.  Provide ways to declaratively specify unique geometry (perlin noise, etc.)—Geometry Shader.
4.  Allow for more complex geometry specified by Blender. (SRC)
5.  Provide a way to apply fragment shaders and vertex shaders to objects (DOM).
6.  Provide a way to place and orient objects in the scenegraph.(DOM)
7.  H-Anim and physics.
8.  Geo.
9. VR
10. Mobile
11.  Templates or Macros of the above. (DOM).  I think the only way our own templating system is going to fly is if we apply it to HTML5 and SVG as well.
12.  Proper support for HTML5 events on X3D objects.

Wish List:

13. SVG Extrusions for 3D printing Blind visualization.

This sounds like a lot.   We need to figure out what we already have and apply resources where necessary.

There may be new items to standardize in 1) reflection, refraction, prismatic and DVD effects 3) easy ways to subdivide boxes and spheres (already in X3DOM, I think) 8) great circle interpolator 9)  eye and motion control 10) standardized shader variable names.

Here’s how X3DOM needs to be extended to meet the above focus items:

1. Add a templating system { CHOOSE ONE OR MORE, EVALUATE }
2. Add JSON { MEDIUM EFFORT }
3. Standardized shader variables. { PROBABLY EASY }
4. Access to CSS  from X3DOM (through id, style and class attributes).  { BIG EFFORT }
5. Add VR devices (this should come for free from the browser vendors)


The last 4 of these apply to Cobweb as well.  Perhaps those should be the ones we focus on.  If we want a JSON templating system, we’ll have to do that as well.

John



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