Re: request agenda time to present X3D summary at HTML5 TPAC meeting

Hi Henri,

> On Oct 30, 2009, at 19:40, Shelley Powers wrote:
>
>> Being able to use X3D in an HTML serialization, based on the
>> _precedent_ set by inclusion of SVG and MathML would be a very
>> interesting discussion item.
>
> I don't see SVG and MathML setting a precedent for X3D.
>
> When support for SVG and MathML was added to the HTML5 parsing  
> algorithm, rendering SVG DOMs was already supported by 3 out of the  
> top 4 browser engines and the fourth also had support for retained- 
> mode markup-based 2D graphics (VML). So at that point in time, there  
> was vendor consensus by implementation behavior showing that  
> retained-mode markup-based 2D graphics were worth implementing and  
> enabling SVG parsing in text/html was the shortest path of enabling  
> retained-mode markup-based 2D graphics in text/html in the largest  
> number of browser engines *given* what was already implemented.
>
> Likewise, given what was already implemented in Gecko and Opera for  
> MathML DOMs, adding support for MathML in the text/html parser was  
> the shortest path of adding inline math support to text/html.  
> (Furthermore, there's a stronger case for why math should be inline  
> than why either 2D or 3D graphics should be inline.)
>

I totally agree that we are in a different state right now but we also  
believe that 3D, as more and more application move from the desktop to  
the web, will be a key building block for future application. I  
personally even think that there will be different 3D technologies  
available in future browsers and standards (Simular to how SVG and  
canvas coexist es 2D technologies ). One which will be an imitiate  
mode system simular to WebGL (even so at least one company will  
properly never support something which is based on OpenGL) and one  
retained mode graphics system. High-end online games and visualization  
apps with very specific internal data-models will probable use the  
imitiate mode. Web-application developer which just need some kind of  
3D graphics technique for there 3D-UI, visual analytics or store-app  
would probable love to use a declarative markup model. Simular to what  
the already know: HTML.

We also believe that it's importend that the elements or nodes of the  
retained mode system will be part of the DOM to make it a first class  
citizen for web-application developer. Plugins never worked for  
different reasons. Accessibility is really a key feature to get this  
technology into the hands of application developer.

Therefore we followed the current HTML5 Spec for declarative 3D data
(http://www.w3.org/TR/html5/no.html#declarative-3d-scenes)
and implemented a system which allows to insert X3D scenes directly  
into the HTML document:

http://www.x3dom.org

This system is written in JavaScript, uses WebGL for rendering, runs  
with FireFox and Webkit nightly builds
and manages/renders a live X3D scene in the DOM. Changes to the  
retained Model are done while
modifying or adding/removing DOM-elements. No Plugin or Plugin- 
interface needed.

This system is not the final solution and really only for evaluation  
purpose since it has two major limitations which can not be overcome.
Feature and performance. The current JS/WebGL layer does not allow to  
implement essential features like spatial sound and video-textures and
even so WebGL is an impressive step forward we still have to do all  
the scene management and updates in JS.

However, it allows us to work on and evolve the integration model,  
hopefully with both communities (W3C and Web3D) and the browser  
developer,
before we start to integrate and provide our existing C++ code-bases  
for different browser engines.

But the systen and implementation is really only the supporting  
vehicle the get the main idee evolving.

What we really hope to see is some kind of 3D markup inside of the  
HTML spec and we believe that X3D is a excellent candidate.

(Side note about inlining 3D data: since 3D models can be easily giga- 
bytes in size, we need, especially with inline graphics, a way to  
reference and include externel resources and data. The X3D standard  
already includes a solution with the "Inline Node". However, this is  
open for discussion and maybe a more generic HTML-like solution is  
more adequate)

Best regards,
Johannes

> In the case of X3D, there's no pre-existing native support in any of  
> the top 4 browser engines, so even if there were consensus that HTML  
> should support inline markup-based retained-mode 3D graphics, it  
> wouldn't follow that X3D being the format would be the shortest path  
> to having the concept implemented.
>
> (This email shouldn't be read to be for or against X3D. I'm just  
> pointing out that SVG and MathML don't set an applicable precedent  
> here.)
>
> -- 
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>
>

--
Dr. Johannes Behr

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-510  |  Fax +49 6151 155-196
johannes.behr@igd.fraunhofer.de  |  www.igd.fraunhofer.de

Received on Wednesday, 4 November 2009 07:07:53 UTC