Fig 1. O3D Beach Sample

O3D has the advantage of being really the first proper 3D implementation for a browser to market (I won’t count Flash3D here since hardware accelleration is key to doing serious work with 3D.), it’s in ECMA/Javascript which makes it pretty accessible to a wide group of developers – and the API appears to be logical and powerful.

It’s backed by Google which will make overall deployment better – and I would be keen to wager that this endevour goes a lot further than Lively did. The runtime is even availible under the BSDL – which makes it very attractive to commercial users.

Could someone implement a virtual world with it?

I think for singleplayer games O3D is perfect – it’s easy to deploy, easy to write, uses standard file formats. Multiplayer – where VW’s come in is a much tougher nut to crack because there is still a dearth of reasonable communication standards for browsers.

AJAX is by communications standards not very powerful – it relies on the idea of a single thread carrying request/response packets. It can be hacked up into supporting threaded packeted communications – but I believe any virtual worlds using O3D will probably be those that can survive a larger latency (eg There.com(R) versus Second Life(R)) – worlds using it will use a lot more clientside processing to minimise connection loss.

The discussion on #opensim-dev this afternoon about O3D has been promising – it holds a lot of potential, and whether we can utilize it to write a simple browser plugin is going to be an interesting project for the next few days.

Graphically O3D has most of the niceties that a modern 3D engine expects (Shaders, etc) – the keys are going to be in the difficulty of writing scene and state management in Javascript, and making sure the communications systems are as simple and efficient as possible.

The ease of install and the lack of serious memory limits on the 3D scene means this may be a better option than Java3D for an accessible virtual world. Stay tuned.