An Now For Something Entire….Oooh! Shiny!

The Google O3D team just launched and the news stories are already starting to trickle out.

Ok, so it’s shiny…but so what?

First, O3D embeds V8. This means that while you might be running your O3D code in a browser with a terrible JavaScript engine, or worse, an engine with terrible GC pauses, your O3D content isn’t subject to those problems. This is a Big Win (TM). Most of the web can limp by with bad GC behavior, but interactive 3D just can’t. You might have seen the difference this makes by running Dean’s Monster demo in Chrome and then trying it in other browsers.

Next, O3D presents a scene graph. Direct-mode proposals to the 3D-on-the-web discussion are based on the idea that JavaScript programmers will ship enormous toolsets down the wire in order to re-create the scene graph and/or to parse shape descriptions. Having direct access to the OpenGL surface description is incredibly powerful, but I suspect not sufficient in the long term to really bootstrap a world where 3D is a first-class citizen. Also, using the web as a way to break-open some of the closed interchange challenges of today’s 3D world isn’t going to happen when everyone’s description of things is entirely programmatic, so I’m excited by the direction of O3D as a force for good.

Congrats to the O3D team. It’s a big day for them and the deserve huge props for shipping concurrently on Windows and Mac.

6 Comments

  1. Ray Cromwell
    Posted April 21, 2009 at 1:31 pm | Permalink

    This is a extremely cool, but there was a reason that scenegraph approaches fell out of vogue in the past, which is that a) developers didn’t get control over visibility determination algorithms (BSPs, portals, etc) and b) they didn’t get control over rendering passes. The latter is critically important if you’re doing multi-pass rendering, like shadow volumes, shadow buffers, or G-buffer based deferred rendering.

    O3D seems to solve this partially (from my quick reading), by giving you declarative control tree traversal, as well as the ability to specify render targets

    Still, I would like to see both OpenGL and OpenCL exposed directly, even if O3D is built on top, just like there is a place for both SVG and Canvas.

  2. Gavin Doughtie
    Posted April 21, 2009 at 3:26 pm | Permalink

    You can indeed control draw list traversal with o3d. (see http://code.google.com/apis/o3d/docs/reference/classo3d_1_1_draw_list.html and http://code.google.com/apis/o3d/docs/reference/classo3d_1_1_draw_pass.html)

    The issue with direct surfaces is that you need highly performant execution of the code that’s managing your custom scene graph, hit-testing, etc. Even V8 is going to run really hot doing this, though things like http://code.google.com/p/nativeclient/ should help.

    Alex is probably sick of hearing me rant about “expose more hardware to web developers” by now…

  3. Posted April 21, 2009 at 3:41 pm | Permalink

    Not sick, sympathetic = )

    If the browser is an OS (and I suggest not-so-humbly that it is), it’s got to be productive and safe to succeed it’s predecessors in a meaningful way. Java exposed lots of hardware in craptastic ways which is why lots of discussions about doing interesting things on the web end at plugins but always give you this weird “it’s going to hurt” kind of taste in your mouth. I think O3D is doing better there by putting productivity first and control second. There’s a strong case for both, but the productivity horse is clearly pulling the cart.

    Regards

  4. Posted April 21, 2009 at 7:46 pm | Permalink

    Finally somebody decided to acknowledge the importance of the scene graph and made it explicit. Let’s hope that Canvas will take the same path eventually.

  5. Ray Cromwell
    Posted April 21, 2009 at 10:32 pm | Permalink

    There is already a scenegraph for 2D, it’s called SVG. :)

    Gavin,
    Yes, that’s true, but often you end up still need to manage the scene graph anyway, or some lower res pre-baked version, even if the render loop is handled for you. “Picking” is a low hanging fruit for many games. For example, if you’re doing path-finding algorithms, you need to walk a scene graph yourself. Or maybe you’re doing objectobject collision detection for rudimentary physics.

    I’m sure one of the first thing someone’s gonna do is port ODE to JS.

    I agree managing all the pipeline state in JS could be slow, then again, with DIsplay Lists it might be manageable.

    Anyway, with respect to Java, I think Java2D/JAI exposed things in a rather nice way, but Java3D’s scenegraph left alot to be desired (except for the very nice geometry compression) Java had the problem of trying to support multiple platforms which had poor interoperability (Linux had *really crappy* font and 2D capability when Java2 was first released, and DirectX still sucked then). Nowadays, all 3 platforms (Win/OSX/Linux) have very nice 2D and 3D mature APIs, so it’s alot easier to expose low level APIs than it used to be. Anyone trying to do multiplatform libraries back in those days had their work cut out for them. Even interoperability on Windows between cards was poor.

  6. Posted April 24, 2009 at 11:09 am | Permalink

    @Ray: SVG doesn’t have a scene graph, it has a markup language — “feel the difference” ™. Can it be used to buils scene graphs? Yes, to some degree.

    As a matter of fact there are several areas that can be automated in the interactive computer graphics, e.g., a picture regeneration, an animation, an event processing, and so on, and strictly speaking these needs could be better served by different scene graphs with different organization.

One Trackback

  1. By WebDevGeekly » Blog Archive » Episode 11 on May 2, 2009 at 5:55 pm

    [...] Releases O3D * Announcement http://code.google.com/apis/o3d/ * Alex Russell loves it http://alex.dojotoolkit.org/2009/04/an-now-for-something-entireoooh-shiny/ * Chris Blizzard on the differences between O3D and the open 3D work being done in Firefox [...]