[X3D-Public] Fwd: Re: [X3D] X3D HTML5 meeting discussions:Declarative 3D interest group at W3C

[Chris Marrin]

On Jan 2, 2011, at 10:40 PM, Philipp Slusallek wrote:

> ...
> 
> The issue even with shader arguments in CSS is that CSS does not allow
> arbitrary name/values pairs with unknown data types in CSS. It is
> strictly a fixed function model, where all parameters and their types
> must be known in advance at spec time. The spec even explicitly states
> that additional parameters are not evaluated. I am not entirely sure
> what the reasons behind this explicit behavior are and how difficult it
> would be to change this to a more open model that we would need for
> arbitrary shader arguments.

The reason for this is because CSS is all about "style". It's not the job of CSS to give you arbitrarily variables to use in your content. It provides color, positioning and other more specific functionality (like border-radius) to HTML elements to allow them to change their presentation without changing the underlying data model. Of course this all gets very grey when you add something like animation. A button with some ambient animation or a highlight effect is certainly style. But CSS Animation is being abused to give all sorts of behavior to content. The animation is integral to the content; It's not just style. But HTML lends itself to this sort of abuse. In fact that is one of it's strengths; Simple tools that can be combined in surprising ways. Of course 3D objects have this problem in spades. Is the position of an object in a scene style or content? Best not to get too worried about this, it can lead to madness!

> The other processing that you need is essentially arbitrary geometry
> processing from morphing, skinning, and skeletal animations to freeform
> deformations, (adaptive) subdivision surfaces, displacements, and more
> esoteric stuff. I do not see how you can put this into CSS at all as
> even the set of inputs is unknown (e.g. for keyframe animation).

It's easy to imagine using CSS to control the animation of a 3D character. Assign it a .wave style to make it wave and a .run style to make it run. With clever style rules, you can have a character that runs while waving. CSS is very powerful that way. But you can do wave and run animations with simple CSS Transforms. Skinning and morphing is much more difficult and might be beyond the abilities of CSS, which was never designed for such things. Maybe you use some hybrid approach, letting CSS somehow drive animations described in DOM elements. That's not to say that new properties, specific to 3D elements, can't be added. But there are limits, and I think shaders are way past that limit, at least for now.

> 
> Using the typed array API of the data elements, anyone is free to do all
> this in JS, but short of a data-parallel extension to JS (for which
> there is some early work), I do not see this as fast enough, as this is
> at the inner loop of interaction and very performance critical (there is
> a reason this stuff is in the OpenGL pipeline and on the GPU now, where
> NV and AMD are pushing this as the main competitive battle in their
> latest chips).

Don't get too hung up on it not being "fast enough". I had those same misgivings about WebGL. But JS interpreters are getting incredibly fast and when you have build-in nodes, you can add specific optimizations so JavaScript operations on those nodes are faster still.

> 
> I am not so sure what you mean by the paragraph about "perceived way to
> do 3D the right way". Which part did you not like or thought would be
> hard to get W3C support for? XFlow? -- for this reason, we carefully
> designed it as a separate module independent of XML3D (even though I
> believe its important for dynamics -- see above).

That comment was not focused on XML3D specifically, but on other statements I read from various sources which troubled me. I appreciate the value of X3D and the last 15 years of work. But I don't think the "X3D way or the highway" rhetoric is useful. There is quite a lot of HTML content out there, and many recent examples of rich interactive content. This is all built on top of the HTML DOM and event model, and JavaScript. So before saying that PROTOs, or ROUTEs or the X3D event cascade or timing model are crucial, step back and look at what the browsers already provide and try to fit into that model. It's a much lower impedance path.

For instance, if you did nothing but add a set of nodes that rendered 3D meshes with shader based materials, what sorts of 3D applications could you easily produce? What could you do, but with great difficulty? Would JavaScript libraries help make more those difficult applications easier? And finally, what applications would either be too complex to run efficiently or too difficult to implement reasonably, and how important are those?

There are many WebGL demos available today. But to me the most interesting is GWT Quake. It uses stock WebGL, along with Web Sockets for multiplayer support. All the animation, AI and user interaction is done through DOM events and JavaScript. It makes real-time frame rates on average hardware. It's implemented in GWT, which is something of a cheat. Redoing it directly in JavaScript would not be easy, but it would be possible and would certainly perform better than GWT (that is no slam against GWT, just acknowledging that running directly on a runtime is always faster than running an interpreter that runs on that runtime).


> 
> If you refer to the ability to sprinkle 3D objects anywhere within HTML
> page (like with you 3D transformation applied to a plane), we have been
> discussing that back and forth. However, we had a hard time coming up
> with intuitive semantics for this. How would you specify which objects
> get rendered via which camera (there may be multiple views that you want
> to show of either the same or different scenes), etc. The point is that
> your 2D stuff comes with a well defined 2D position, that you apply a 3D
> "warp" to.

IMHO I think composite operations need to be a secondary consideration. Gotta run before you walk. These more advanced concepts should be kept in mind, but I think it's important to get the basics down first.

-----
~Chris
chris at marrin.com