The future of O3D
Friday, May 07, 2010
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.

7 comments:
Theo said...
This must have been a tough decision to make. I do feel though that many, many people will say that you are doing a good thing.
The future is 3D. It's just a question of when do we get there.
We will get there faster if "it just works" - no plugins, no installs, no extensions required. WebGL seems to offer that possibility.
But we will get there even faster if "it's faster!". The public will not put up with low frames per second rates. Your perspectives and insights gained in building the speedy O3D should be of great benefit to the WebGL community.
Please do as KP suggests: Live long and thrive!
May 7, 2010 11:25 AM
SunboX said...
Thats´s really great news! Can´t wait to have WebGL on 95% of users browsers. That would give developers endless opportunities to develop impressive web apps. I want this now, plz. :D
May 7, 2010 2:15 PM
Enrico Ros said...
Compliments for this decision!
The new O3D will be a better gift to the world.
May 7, 2010 2:16 PM
RikArends said...
Could you please make sure WebGL gets that nice software rasteriser from O3D? Buy the company that made it and opensource the engine if thats whats needed. Crappy 3D hardware drivers have held back 3D browser API's already for as long as both 3D and the web exist. I have seen Anark bluescreen my PC, Adobe ShockWave 3D crash it and i am horrified by how WebGL seems to be evolving currently in Chrome and other browers. Yes i already saw a nice (brand new) videocard driver crash. Although windows now manages to recover from these things a bit nicer, windows XP country will not be so lucky. Until the hardware accelerated 3D web is in any form as safe people expect the browser to be, it will struggle for adoption. By having a strong software rasterizer this transition can be done in a much cleaner way, piecewise enabling real hardware when tests prove certain drivers and OS combos are 100% safe. Bolting webGL on Direct3D does not completely solve the problem, although D3D drivers are arguably more stable than the worst OpenGL ones out there there will still be hordes and hordes of bluescreens and scary driver bufferoverflows ahead. Especially when opening the gates to shaders.
May 7, 2010 2:37 PM
Jim Ramia said...
Saw the amazing Quake2 GWT port - http://www.youtube.com/watch?v=fyfu4OwjUEI&feature=player_embedded (which uses a GWT WebGL wrapper).. Looks awesome no plugins required!
May 7, 2010 2:40 PM
yopyop said...
cross posting from http://o3d.blogspot.com/2010/05/future-of-o3d.html
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 5:36 PM
horace said...
i hope there also will be some enhancements to the audio capabilities of browsers? games need to be able to do effects like pitch shifting.
there will also be the need for an optimized javascript port of bullet physics. it for sure will be pretty slow but i guess for a low number of rigid bodies it still could work. maybe there could be a webCL in the future for accelerating physics? :)
May 10, 2010 5:03 AM
Post a Comment