WebGL and O3D

You may have read recently that Khronos is implementing something called WebGL. The objective of the project is to expose all of OpenGL ES calls to javascript. Thus allowing hardware accellerated 3d graphics within a browser.
Google has also been working on an alternative, called O3D.

Let’s first talk about the technical differencies between the two projects.

O3D and WebGL while both trying to bring accellerated 3D graphics to the web have taken two fairly different courses. As I mentioned in the introduction to this post WebGL’s plan is just to expose to JavaScript OpenGL ES 2.0 APIs. Whereas Google’s solution is based on a browser plugin.

If we think about this we’ll soon realise that WebGL depends entirely on JavaScript. JavaScript, as of today, is a fairly slow language. This point was made in a discussion thread on the O3D project website.

WebGL, being 100% dependent on JavaScript to do an application’s scene graph, is going to have serious problems drawing more than a few pieces of geometry at 60hz except in very special cases or on very fast machines. This means WebGL requires JavaScript to:

*) do all parent-child matrix calculations for a transform graph.

*) all culling calculations (bounding box to frustum or other)

*) all sorting calculations for dealing with transparent objects.

*) all animation calculations.

As an example the kitty demo in O3D is doing linear interpolations on 2710 floats to animate 170 transforms. The point is not that the artist that created the kitty should probably not have used 170 bones. ;-) Rather the point is it seems unlikely that JavaScript
will be able to do that anytime soon and if it can then just add more than one kitty to pass its limits.

Also we have to keep in mind that not all hardware supports OpenGL ES.

O3D, By virtue of being a browser plugin written in C++, so an additional (hopefully fast) abstraction layer on top of the GPU, allowed Google to define a new set of APIs to expose to JavaScript and keep us (the JavaScript developers) away from the hardware. O3D will take care of the interaction with either DirectX or OpenGL.

Furthermore Google has open-sourced O3D through its Google Code website. Which means we can all have a look at their code and participate in the project. This resulted in a lot of documentation being available. For a full overview of how O3D works check out the technical overview on the O3D project page.

Do you think that this is the making of a new “Standards war”? Both Google and Khronos are adamant that they are not competing. However I believe that ultimately only one project will come out as a standard. As the complexity of 3D web applications increases it is not feasible to write code for both “APIs”. The only question for me at this point is who will come out on top.

To answer this I would look at the audience of the two projects. OpenGL has been out in the wild for a long while and many developers of videogames, or general graphic application, are already familiar with the APIs and the way it works, therefore it would probably make sense for them to embrace WebGL.
Nonetheless O3D still stands a chance. For a very simple reason. It’s the web we’re talking about.

Frankly I can’t see myself playing a big videogame like fallout in a browser window anytime soon. These APIs will be used to enrich web application. Some examples are already coming out using O3D. Have a look at this Home Designer. Can’t you already see IKEA using it.
My point here is that we’re not likely to see game developers switch to the web. We’re much more likely to see web developers start working on games or application involving 3d graphics, and this is where Google wins.

O3D extends application JavaScript code with an API for 3D graphics. It uses standard JavaScript event processing and callback methods.

As a web developer I can keep writing JavaScript code as I’m used to without having to change the way I think to how a game developer does.

What do you think?

Tagged , , , , , , ,

16 thoughts on “WebGL and O3D

  1. niczar says:

    JavaScript, slow? Unless you’re running IE or Opera, you have the *fastest* general purpose dynamic language right in your browser. Firefox’s Tracemonkey, Chrome’s V8 and Safari’s Sunspider beat the crap out of Python, VisualBasic, Perl or PHP in raw power.

    There’s plenty to say about JavaScript, but slow? No, it’s not.

    • Stefano Buliani says:

      It is slow compared to the language more graphic-intensive application are built in. C/C++. It’s also completely different and has a completely different purpose so mine is an unfair comparison. But if we’re talking about building videogames then that’s what we have to compare with.

  2. is says:

    In a video game design light its slow..fine for 2d but 3d needs more POWER

    • Stefano Buliani says:

      That’s why I argue that O3D has the right idea by pushing all the heavy lifting down to the plugin written in C++ and leaving javascript in control of things on a higher level

  3. [...] at SAPessi, Stefano Buliani compares WebGL and O3D, and comes to the conclusion that O3D is a better choice for 3D graphics on the web. His view is [...]

  4. Adam says:

    It’s -perhaps- early to judge but the relative sophistication of each of the demos seems to make it pretty clear what will be most likely to give us working “web3d”

    O3D is producing demos like “beach” and webgl seems to be struggling to produce even simple objects in it’s demos.

    I’d be interested to hear someone familar with webgl would say about how close webgl is to being able to produce a workalike to the o3d beach demo in terms of performance and perhaps some of the ease of use features.

    I agree too that webgl seems like a stretch for most of us to produce anything interesting with (I’ve done a small bit of opengl but wouldn’t look forward to much more ;) ).

    • Stefano Buliani says:

      Adam, I don’t think WebGL is in any way less powerful than O3D. I’m also sure that you’d be able to reproduce the same O3D demos with WebGL.
      My main arguments here are:

      1) WebGL is likely to be slower since most of the heavy lifting (CPU-wise) is left to javascript
      2) The people most likely to play around with these APIs are web developers and not game developers. An OpenGL game developer could probably produce a spectacular demo with WebGL in a couple of days. However the web is populated by people like me. Who are familiar with JavaScript event processing and callback methods.

  5. Ced says:

    I think the latter point in favor of O3D is just a temporary one.
    WebGL, thanks to its total flexibility, allows building easy APIs to build 3D stuff, so for web designers in the end they could actually get things easier done through WebGL, albeit indirectly. For instance I’ve seen an interesting experiment that takes a 3D markup language ala SVG and Javascript quickly processes it to display a WebGL representation of that object. Coding is not even required in this case.

    All that without limiting more advanced developers to do some crazy things that they could not do with a higher-level API like O3D.

    • Paul says:

      100% agree with you. Even if O3D looks the most attractive I think we’ll regret it in the long run if it won out. Javascript is getting faster all the time as are CPUs and the extra control you get from webgl more then out weights the short term gains of O3D.

  6. Social comments and analytics for this post…

    This post was mentioned on Twitter by tek_news: Reddit/p: WebGL and O3D http://bit.ly/3PMrz6

  7. [...] JavaScript games – more thoughts on O3D By Stefano Buliani Technology, Thoughts, WWW Add comments This week I wrote a post comparing O3D and WebGL. [...]

  8. Offillata says:

    Other variant is possible also

  9. uplicate File Finder locates duplicate files and folders on all drives and removable devices. This utility lets you compare and preview graphics, HTML, text, and other types of files. … Weaknesses: Not free does not find all duplicates. I found a …

  10. Flo Morini says:

    nearly give up when I in the end found your site! THX !

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: