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

[Chris Marrin]

On Jan 3, 2011, at 8:44 PM, Philipp Slusallek wrote:

> Hi Chris,
> 
> I largely agree with your CSS statements. But there is the key
> difference between a fixed function model for shading (say Phong) where
> all arguments are are predefined and programmable approaches, where they
> and their types are not known in advance and may even change when you
> change the shader program. We have done exactly what you proposed and
> have put the shader object back into the content and simply assign it
> via CSS. While this works, it leaves somewhat of a sour feeling. In
> particular, as we see no necessity to prevent CSS from providing
> arbitrary attributes. It might be worth removing this limitation.

Speaking as a WebKit developer, it would be exceedingly difficult to allow arbitrary properties in CSS. The properties are parsed into fixed structures for efficiency. Resolving style can be an expensive proposition, so keeping it efficient is crucial. But I''d like to understand your issues with keeping a fixed property CSS system and perhaps adding a small number of properties for the needs of the declarative 3D nodes.

> 
> I see CSS mainly as an orthogonal way to associate data with content
> objects. This works well for "style" but does not need to be limited to
> it. E.g. we used it to provide physics parameter (mass density, friction
> coefficients, etc.) to objects.

Hmmm. That gets into some murky areas of what is style and what is content. And I'm not sure if physics is a good example right now. I don't see a fully fleshed out physics engine being added to browsers in the short term. That may be a great addition in the future and would in fact have uses outside 3D. But I think it would be a mistake to include it in the first pass. I'm all about baby steps these days. It not only aids adoption, but it lets you see more clearly where the next steps should be.

> 
> 
> Regarding speed for geometry processing: Chris, at the moment we are
> talking about dozens of wide SIMD cores with optimized data paths for
> streaming operations on the GPU itself versus a far away CPU based JS
> implementation (that today at least still needs to transfer the results
> via a rather slow PCIe bus to the GPU for rendering). There are orders
> of magnitude between the two that no compiler optimization for JS (which
> have done amazing things, no questions) can address. I did talk about
> some proposed data-parallel extension to JS but they are still deep
> within research labs still and its unclear where this will go.

Baby steps. I don't think it's a showstopper if a web app can only push 100,000 particles rather than 10 million.

> 
> So for the time being, I simply see no alternative to something like
> XFlow to tackle the problem. I appreciate and fully agree with your
> approach of "lets start small and add only when we find out its really
> needed", but this is an area, where its clear from the start that JS
> alone will be insufficient. For these JS extensions we could simply
> expose CUDA/OpenCL/DirectCompute/whatever but this would bring us fully
> back to procedural land again and be counter productive to our main goals.

I was not able to get many details about XFlow from a web search. But it seems clear that JS alone IS sufficient for some compelling 3D on the web. The handful of WebGL examples proves that. Moving the rendering, event handing and (some) animations to native code can only be better.

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