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

[Chris Marrin]

On Dec 23, 2010, at 12:20 AM, Kristian Sons wrote:

> Dear Chris,
> 
> comments below.
> 
>> ...
>> Actually, having been involved in non-X3D web efforts and especially
>> since coming to Apple and working on WebKit, I think the hesitation
>> about a 3D declarative language is more than just "we're too busy
>> right now". WebGL worked its way into the browsers because it was a
>> tractable problem. There were those who thought a 3D API on
>> JavaScript would not fly (and some still do). But no one thought
>> OpenGL ES 2.0 was too complex for today's systems. X3D (as the most
>> popular example) is seen as too cumbersome and not integrated to be
>> included.
> 
> I fully agree on that. But I also think that with XML3D and X3DOM we made a good step forward into the direction how a tractable solution could look like. I don't say it's perfect, but I guess we learned a lot.

What I think I've learned from those efforts is that WebGL is up to the task of rendering models. No doubt there will be native implementations of the renderer in the future. But for now I don't think that's the big issue. CSS is the technology I believe is extremely useful in the management of the 3D domain, yet the hardest to represent purely in JS. I also learned that browsers are currently deficient in the area of handling binary data. We're making good progress on the data handling and not very well in CSS handling.

>> ...
>> We did WebGL in Khronos because we wanted to take advantage of the
>> expertise of the Khronos participants. I think you have good
>> expertise in 3D declarative forms already, but I would recommend you
>> stay close to other W3C efforts to be able to draw on their more
>> general web expertise as well. As a WebKit developer, I would also
>> recommend you pull a WebKit tree and understand it. We already have a
>> cross-platform 3D rendering API (GraphicsContext3D). WebGL uses it
>> already, and Google is beginning to use it for accelerated 2D
>> rendering. GraphicsContext3D allows you to work on multiple
>> platforms, including D3D via ANGLE, with a single implementation.
>> Putting your declarative elements on top of it would be relatively
>> simple and would speed development. The same may be true of Mozilla,
>> but I'm not familiar with their codebase. But being completely
>> unbiased, WebKIt is way better :-)
> 
> In fact we already did modify WebKit for the XML3D project. We have a Chromium browser that supports XML3D. My colleague Sergiy Byelozyorov did all the WebKit, V8 and Chromium modifications and introduced the asychonouse rendering. The modified version is based on Chromium 6.0.x. I don't know the corresponding WebKit version. I suppose there happend a lot recently in the render engines to get the 3D canvas into the compositing process. Thus it's certainly worth looking at GraphicsContext3D, thanks a lot for the tip.

I would be very interested in seeing that work. Is it some mechanics for improve CSS access? Or was it just for rendering? Speaking of rendering, there is experimental work going on in the WebKit and Mozilla trees to improve the mechanics of rendering. Here's a WebKit bug managing it:

	https://bugs.webkit.org/show_bug.cgi?id=51218

That also have a link to the original Mozilla work. I'm not sure where it's going but it might have overlap with your work.

>> ...
>> I agree that a pure API approach is out of scope. But you will have
>> some sort of API for your nodes because of the DOM. The big question
>> is how much API you expose in the DOM of your nodes.
> 
> That's a good wording. Of course we have to define the IDLs for the elements, Events and probably some data types. Thus we are not API-free ;)

IDL is a good way to do design of these sorts of things. We found that it not only gives a representation that makes clean what we're talking about, but it also showed us where the limitations are. If you can't represent it in IDL, you should question your design! I believe we actually influenced the IDL WG a bit in firming up parts of that spec. So maybe it's even better now at representing what you want to do.

> 
>> My personal
>> opinion is that it would be valuable to let authors "crack through"
>> into an underlying WebGL API to do advanced things. But that's just
>> my opinion.
> 
> That is a difficult topic. I clearly see the benefits for this "crack through". On the other hand it restricts to a certain API and rendering mechanism again. Perhaps there could be something inbetween. It could be nice to have the result of the declarative scene in a render buffer thus it can be used to do i.e. post processing in a WebGL enabled browser.

Exactly. It would actually make your work simpler in some ways. You don't have to conceive of a node set that would let authors do complex post-processing; you could give lower level access so they can go nuts. It follows the "make simple things simple, make complex things possible" philosophy.

I think it would be interesting to try working within the constraints of WebGL as a rendering API. Many declarative 3D scene graph engines today are built on top of OpenGL, so it should not be difficult. Of course WebGL is OpenGL ES 2.0 which chops out some of the more complex functions of OpenGL 3.0 and above. But staying within the confines of GLES 2.0 would mean you have a much better chance of running on mobile devices, which will get increasingly important as we go forward.

> 
> I think we should focus on the renderer independent part but should keep the "crack through" idea in mind so we don't screw the possibility in the design phase. But that's just my opinion.

I understand your reluctance. You don't want to get yoked with constraints early on. But if you start going down a path of defining rendering functionality that can't be represented by WebGL, it should at least raise red flags about implementability on a large variety of hardware.

>> ...
> 
> Anyway. Great to get your input and perhaps you can join formally at a later stage?!

I'm not sure what's needed to "formally" join an XG, to tell you the truth. Apple is a member of W3C, so that shouldn't be an issue. I am on the Audio XG and there was no formal process for that. Let me know when you have the group setup so I can join the mailing list.

By far the most important issue in starting an XG is the name. So make sure you pick a good one :-)

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