Friday, May 7th, 2010

Great win for WebGL and standards; O3D becomes JS library

Category: Google, JavaScript, Toolkit, Utility, WebGL


This is fantastic news. A lot of people were claiming that O3D was going to beat WebGL because of performance. Then the O3D team showed that the two could be complimentary, and they have taken the next step on that journey. As of today, O3D will stop being a plugin, and will become a JS library on top of WebGL. This is fantastic, as we need a nice API on top of the OpenGL-y WebGL library.

Here are their thoughts. Congrats to the O3D team, to the WebGL folk, and to the future:

We launched the O3D API about a year ago to start a discussion within the web community about establishing a new standard for 3D graphics on the web. Since then, we’ve also helped develop WebGL, a 3D graphics API based on OpenGL ES 2.0 that has gradually emerged as a standard, and is supported by other browser and hardware vendors like Mozilla, Apple and Opera.

At Google, we’re deeply committed to implementing and advancing standards, so as of today, the O3D project is changing direction, evolving from its current plug-in implementation into a JavaScript library that runs on top of WebGL. Users and developers will still be able to download the O3D plug-in and source code for at least one year, but other than a maintenance release, we plan to stop developing O3D as a plug-in and focus on improving WebGL and O3D as a JavaScript library.

We did not take this decision lightly. In initial discussions we had about WebGL, we were concerned that JavaScript would be too slow to drive a low-level API like OpenGL and we were convinced that a higher level approach like the O3D scene graph would yield better results. We were also cognizant of the lack of installed OpenGL drivers on many Windows machines, and that this could hamper WebGL’s adoption.

Since then, JavaScript has become a lot faster. We’ve been very impressed by the demos that developers have created with WebGL, and with the ANGLE project, we believe that Chromium will be able to run WebGL content on Windows computers without having to rely on installed OpenGL drivers.

The JavaScript implementation of O3D is still in its infancy, but you can find a copy of it on the O3D project site and see it running some of the O3D samples from a WebGL enabled browser (alas, no Beach Demo yet). Because browsers lack some requisite functionality like compressed asset loading, not all the features of O3D can be implemented purely in JavaScript. We plan to work to give the browser this functionality, and all capabilities necessary for delivering high-quality 3D content.

Related Content:

Posted by Dion Almaer at 12:56 pm

3.5 rating from 2 votes


Comments feed TrackBack URI

Very cool. A great move, and helps push focus in the right direction for now which is consistent browser WebGL support and performance.

Comment by functionform — May 7, 2010

Hmm, how cool would it be for Resig to implement the 3d aspect of processing in processing js targeting WebGL. :D Very exciting indeed.

Comment by functionform — May 7, 2010

@functionform – the latest processingjs is already there – implementing lots of 3d goodness on top of webgl.
Realistically though I think that a canvas2d fallback for webgl is critical, ala three.js, as webgl penetration is rather low atm.
To me this is a repeat of the software quake/unreal vs their gl/d3d counterparts days – during the transition before everyone has web-enabled hardware 3d graphics, software acceleration is still a dealbreaker.

Comment by rdza — May 7, 2010


It is very good news indeed. I was also very for such library. The fact that it will be compatibible with existing usage of O3D, and that it will work transparently is only good thing. Of course performance can be slightly slower than a plugin in C++ talking directly to OpenGL, but JS is getting faster and there is already proposed standard for typed arrays for JS ,which will be very usefull in WebGL and other high performance JS computing. (typed arrays are actually propossed by the guys behind WebGL).

Comment by movax — May 8, 2010

“Realistically though I think that a canvas2d fallback for webgl is critical, ala three.js, as webgl penetration is rather low atm.”

software rasterzer should be implementes on the os level as is today . look at mesa galiums’ llvmpipe, directx reference softrast or comercially available rasterizers. They have quite good performance, and run just in the CPU.

The only problem with WebGL is that it could possible be overused for advertisments, as currently flash is used.

Comment by movax — May 8, 2010

Sorry to be a pedant, but I think you meant complementary, not complimentary.

Comment by Skilldrick — May 8, 2010

Comment by hackwaly — May 9, 2010

so using this, well done guys!

Comment by johnantoni — May 10, 2010

…and thanks Skilldrick for posting ymacs, that is indeed very cool

Comment by johnantoni — May 10, 2010

WebGL is still not easy for many web developer, flash is easier. But google does the right thing, webGL is the future.

Comment by zhaiduo — May 12, 2010

Leave a comment

You must be logged in to post a comment.