The future of O3D
Monday, May 3, 2010 | 6:40 PM
Labels: O3D API Blog
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.
We’d like to thank the developers who have contributed to O3D by delivering valuable feedback, submitting changes to the plugin and developing applications. To help you convert your application to the new WebGL implementation of O3D, we will keep our discussion group open where our engineering team will answer your questions and provide you with technical advice. For those of you concerned about support for Internet Explorer, we’ll recommend using Google Chrome Frame once it supports WebGL, and hope to see IE implement WebGL natively someday. We hope you will continue working with us and the rest of the WebGL community on moving 3D on the web forward.
In the future, we will not be posting to the O3D blog. For updates on O3D and the 3D web, please subscribe to the Chromium blog.
Posted by Matt Papakipos, Engineering Director, and Vangelis Kokkevis, Software Engineer
8 comments:
Gavin said...
I think 3D is going to always need a retained mode API as well as an immediate mode system. Maybe with http://code.google.com/p/nativeclient/, we can have our scene graph O3D cake and eat it, too! Keep up the great work.
May 7, 2010 at 10:58 AM
pl4n3 said...
O3D plugin technology is/was great, but WebGL has brighter prospects, imo. So this is a good step.
May 7, 2010 at 11:00 AM
Unknown said...
This is an excellent direction. It gets O3D into a much wider audience... all HTML5 supporting browsers.
I cant wait to run my O3D app on my ipad!
May 7, 2010 at 11:15 AM
yopyop said...
While I agree on the long term direction, I think it is way too early to drop O3D as a plug-in right now.
Not only WebGL is far to be available in a large market share of the available released browsers, but a lot of issues are still to be resolved to make it as relevant/powerful as plug-ins such as Unity and Shiva (or the now abandoned O3D plug-in) as mentioned in this message "Because browsers lack some requisite functionality.. "
O3D as a plug-in should be maintained and exist to help content developer to create content today, and O3D as a javascrip/WebGL engine should be developed in parallel, with the mindset to help today content developers to migrate to this new technology when available and all browser issues have been resolved.
As it stand, an O3D javascript WebGL project without existing plug-in based content is not much different than existing open source projects such as SceneJS (http://www.scenejs.org/) and plenty other. I would rather see the O3D/Google team reach out to those existing opensource project, rather than creating another project.
May 7, 2010 at 11:40 AM
Unknown said...
I agree with yopyop.
Some type of marriage of O3D and WebGL is no surprise.
But the timing is a bit of a surprise considering the fact O3D is supported in IE and that O3D is in a more mature state of development than WebGL.
O3D has had the potential to make 3D content for the web more mainstream more quickly.
Google Frame development/support will also be vital to windows desktop applications which incorporate/use IE and wish to include/support O3D/WebGL.
May 7, 2010 at 4:08 PM
Anonymous said...
May 12, 2010 at 11:34 PM
Unknown said...
agree with yopyop
WebGL seems far to be available,O3D plug-in should live a long life
May 13, 2010 at 6:57 AM
Unknown said...
I m also disapointed about this choice ...
And I would like to know if Google will keep alive 1 url to the COMPLETE O3D maintenance plugin setup, because current setup is not 1 full package, it performs 1 download during installation ...
May 17, 2010 at 1:59 AM
Post a Comment