Infrequently Noted

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.

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...

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

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.

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.

@Ray: SVG doesn't have a scene graph, it has a markup language --- "feel the difference" (tm). 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.