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

On Mon, Feb 15, 2010 at 3:25 PM, Chris Marrin <cmarrin@apple.com> wrote:
>> > * As a HTML implementor, I would like to see X3D mature a bit more
>> > in the web world before committing to implementing this. 3D on the
>> > web is still very new technology, especially in the form of markup.
>> > It's very hard for me to judge how likely it is that X3D is the
>> > solution that we'll want to go with.
>>
>>
>> Practically any past history of 3D on the WWW gets updated by a giant
>> step just looking at www.x3dom.org. Dr. Behr has provided these
>> examples just in case anyone wanted to compare X3D with any other
>> forms of encoding various themes showing declarative realtime 3D
>> shapes, lighting, navigation, and interactivity, including 'internal'
>> ecmascript. Essentially, the technique used for reading and rendering
>> X3D could be done for any syntax, so most anyone interested in
>> learning about 3D can pick anywhere they wish to start. I would say to
>> just go ahead and start with X3D because nothing you learn about basic
>> 3D stuff and h-anim is likely to be past history anytime soon.
>> Besides, most any 3D vendor will export X3D. LIkewise, most any X3D
>> tool chain will import Collada, KML, CitiML, and many others. And
>> really, it is no harder to hand edit X3D element structures than
>> HTML5.
>> ...>
>> > A javascript-based X3D player invokable from HTML content has been
>> > produced to demonstrate how these capabilities can work together
>> > closely. It utilizes the WebGL layer provided in Minefield/Firefox
>> > and Webkit/Safari/Chrome nightly builds, and also shows excellent
>> > performance results. Available at
>> http://x3dom.org
>>
>> >
>> > We are also prepared to extend these leading browser implementations
>> > to add open-source solutions for native UA rendering of X3D scenes
>> > within compound HTML5+X3D documents. Details at
>> >
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238#c26
>>
>> >
>
> I responded on this topic to the bug shown above, but I (and others) felt it would be useful to repost it here to garner better visibility and comments:
>
> The X3DOM experiment (http://x3dom.org) is a great proof-of-concept that X3D, as well as many other declarative 3D formats, can be accommodated in HTML 5 today without additional parsing in the browser. The reason for adding WebGL to WebKit and other browsers was to include the smallest set of 3D functionality possible and avoid locking in any one higher-level scene-based format. This both makes the implementation tractable and reliable as well as making it implementable on a wide array of devices.
>
> X3D is only one scene-based 3D format. There are many others that will surely arise using the same WebGL based mechanism as X3DOM. Some will have a large set of wide ranging nodes like X3D, others will be much smaller, targeted at specific applications like games or 3D visualization. The beauty of WebGL is that is can accommodate all these formats without the burden of building any of them into the browser.
>
> I worked on VRML, the predecessor to X3D, from its inception in 1994 to 2000. I was one of the authors of the VRML 97 ISO spec and I'm editor of the WebGL spec now. I've seen lots of cool and interesting things with 3D embedded content and I'm convinced that keeping the native 3D browser support as small and lean as possible is the right approach to enable X3D and many other 3D apps in the browser.
>
> With my WebKit implementor's hat on I can say that we wouldn't be interested in adding native X3D parsing to WebKit. But I would be extremely interested in seeing the X3D group put effort into improving X3DOM and creating other JavaScript layers on top of WebGL. I think there is huge potential there for all the 3D applications the X3D group is currently pursuing.

Hi Chris,

Great to hear your input. This matches my feelings with regards to
plans for mozilla. I'm far from the only person that has a say in what
happens as far as HTML and/or 3D support in firefox/gecko goes, and
it's likely that my feelings doesn't fully match others, but I know we
very intentionally wanted to do a low-level API for 3D. The goal was
to allow others to play with higher level APIs on top.

It's possible, and even likely, that some day we'll want a native
implementation of a higher level API. But for now I'd prefer to
implement lower level APIs in order to allow people to play around
with various higher level APIs.

/ Jonas

Received on Tuesday, 16 February 2010 02:23:28 UTC