My first reactions to Google’s new O3D JavaScript API is “Thank God someone finally did it.”, a more detailed examination appears to yield something like Mozilla’s proposed Canvas3D but with practical implementations for all the major browsers and platforms (IE, FF, Win, Lin and Mac) – something Canvas3D was unlikely to get.
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.
I agree with you that AJAX communication is not enough to create multiplayer applications, but I think it’s easily solvable by other technologies. The simpliest solution is to embed a Java Applet to the page, which can do the communication part of the application. I can imagine an MXP player which is made upon O3D and JavaScript, and for the UDP communication, an Applet is used. Applets are easily accessible from JavaScript and ideal as communication/protocoll interfaces.
Merlin
22 Apr 09 at 9:23 am
Right, we were discussing on IRC using Flash to do TCP.
There are some other considerations here – networking behind the firewall is one. UDP breaks badly on most firewalls – so we need to do a lot of work with cleaning this up with various hacks if you wanted UDP.
I’m at the moment experimenting with a HTTP/JSON clientstack for OpenSim – if it works out alright, it might just be usable.
Adam Frisby
22 Apr 09 at 10:07 am
HTTP/JSON songs good. Standard communication format, firewall friendly, etc., but is JSON the right format for communication? I have no real world experience with VR protocols, but I think they must be very data intensive. So, maybe a binary protocol upon HTTP can be better choice. The Google Protocol Buffers (http://code.google.com/intl/hu-HU/apis/protocolbuffers/) witch is used in the MXP reference implementation can be a better way to implementing the communication interface. Google Protocol Buffers have a JS implementation (http://code.google.com/p/protobuf-js/), so hypotetically it is possible to create a full Javascript based client upon O3D.
Merlin
22 Apr 09 at 7:23 pm
Interesting.
I was not aware google have a protobuf JS implementation – since I have not written the serialiser yet, this actually may be a good target.
The reason I suggested JSON was that it is very simple to parse and is widely used within the JS space.
Adam Frisby
23 Apr 09 at 1:07 am
If you have a flexible architecture, replacing JSON to protobuf can be very easy. I think the bigest problem will be the HTTP’s request/response model. How the client side will be noticed about the events? As I know, the standard way is polling, but if the poll frequency is big (it must be for the VR experience), it can be also very data expensieve. Although, a flexible architecture (try to use Applet/Flash with UDP, and if it not works, change to HTTP) can help.
This new firewall friendly architecture is very impressive. I am really excited about the results of the development.
Merlin
23 Apr 09 at 3:54 am
Events are a tough one – I am debating using COMET versus polling. COMET has some advantages in that it provides realtime feedback – the disadvantage is it breaks program flow.
That being said – this isnt being pushed as a next gen protocol. The reason being there are better ways to do that – eg, MXP is a lot more interesting as a full VW protocol.
Adam Frisby
23 Apr 09 at 4:29 am
AJAX is under-estimated for communication in VWs. Two things to bear in mind:
1 – Polling is not as expensive as you’d think, just make sure each individual poll sticks around for a while. I’m fond of sending a POST every few seconds (if there isn’t already one pending) and then having the httpd sit around keeping the socket open for about 10 seconds until an event comes in. In-between polls, events are queued up.
This is fairly similar to how EQG in SL already functions I believe and i’ve tested it quite a bit for tunnelling purposes. It also works wonderfully on google app engine contrary to popular belief, and can be used to simulate background threads (I have a cool little system that serialises the full function closure between each request and stores it).
2 – You can offload some of the processing to the clientside and thus reduce network communication. Physics can be done very nicely like this, just resync every now and then. Security issues need to be taken into account of course, but in a worst case scenario a client may think it’s at location A while it’s really in location B – if done right it can’t actually manipulate location A or even see what content is there.
Gareth Nelson
27 Apr 09 at 6:28 am
EQG is basically COMET – it’s the idea of not returning immedietely, but waiting until you have something to return. So we’re on the same page there.
Re: doing more clientside processing – big catch here, Javascript. Doing physics processing in Javascript strikes me as not quite feasible — I think you realistically with O3D will be trimming most of the realtime interactive stuff away and ‘live with’ a 200-400ms latency between action and reaction.
Adam Frisby
27 Apr 09 at 10:46 am
Who mentioned javascript for client-side processing?
Java applet, Flash, O3D mods even….
Gareth Nelson
27 Apr 09 at 4:32 pm
Well, if your going the Java route you may as well go Java3D (apart from the incredibly crappy 64MB applet memory usage limit.); but realistically doing interop between clientside plugins is messy at best. O3D mods are probably the most sound of the lot – but then you need to handle distribution of your custom version.
Adam Frisby
28 Apr 09 at 7:00 am
Good point about Java3D – though it’s not got as nice an API. Another nice approach is to use Firefox 3’s support for sockets in chrome code, of course that leaves none-firefox users out in the cold.
Gareth Nelson
28 Apr 09 at 12:55 pm
Right – the big catch is going it in a way that covers at least the main three platforms. Relying on flash somewhat nerfs you there a little, since Flash on Linux is always sitting a version or two behind and is generally badly supported.
Adam Frisby
29 Apr 09 at 12:40 am