Re: request for guidance: centralized extensibility for HTML5 using X3D graphics

On Feb 18, 2010, at 6:47 AM, John A. Stewart wrote:

> ...However, the Web3D Consortium also wishes to address the millions (or tens/hundreds of millions) of graphics capable devices out there that currently do not, or will not support WebGL.

But wouldn't it be far easier to implement WebGL on these devices (unless one of the browser vendors beats you to it)?

> Whether the solution is X3D, or some subset of X3D, or even another graphics language is of relatively little consequence; we just wish to work with the W3C and produce an open standard for platform-agnostic 3D models.


Here's an interesting thought experiment. X3D is an outgrowth of VRML, which was designed at a time when embedding 3D in a plugin in a web browser seemed like the best idea. We know now the pitfalls that causes (poor page integration, plug-in ghetto, the need to do everything, including scripting and image loading, in the plug-in, etc.). If we were designing a set of 3D nodes for the web today, how would we proceed differently? For instance, would we have EAI or SAI interfaces? Certainly not, we would use the DOM and the scripting capability already built into the web browsers. 

Designing 3D as elements in the DOM would have tons of resources available that VRML and X3D did not have. Not only a scripting language and DOM, but CSS (including CSS Animation) an event model, XHR, Image loading and caching, video/audio, application cache and web workers, just to name a few. 

Just look at CSS Animation alone. It adds a 4x4 homogeneous matrix and the ability to animate it (as well as animating colors, opacity, and other CSS properties). This eliminates the need for transforms and the entire set of X3D interpolators.

So what nodes would you need? You'd of course need a structural node (groups), transformable via CSS. You'd need a representation of mesh data and a set of material nodes to apply colors, textures and lighting. This could be a very simple set of nodes if you do what we did in WebGL, support only shader based materials. So you'd maybe just need a few nodes to define a set of shaders and the parameters sent to them (probably CSS based). Then you'd want some Sensor nodes, which would allow user interaction and would feed resultant events into the DOM Event Model. GeoNodes, metadata, and even all the primitives (Box, Sphere, etc.) could be easily done in a JavaScript library and kept out of the core node set. There would also be no need for TimeSensors or other timing or animation related nodes. You could also eliminate the complexity of Prototypes, which can be done in a JavaScript library.

On top of this core layer you might want physics, higher order surfaces (NURBS, etc.), and maybe particle system nodes. But those could be a later profile.

What I'm getting at here is that, if designed today, I think 3D for the web would be a much different and much simpler set of nodes than we see in X3D. That's why I say that WebGL is a good first step. It allows us to take the most appropriate steps toward the best 3D solution.

-----
~Chris
cmarrin@apple.com

Received on Monday, 22 February 2010 20:11:20 UTC