robsmart.co.uk

I thought I’d write a quick article on the possibilities of writing a client for OpenSim using Unity3d, I’m writing this as there has been a lot of discussion around this recently after the Unity3d indie version became free.

I’ve done a fair bit of prototyping and investigation on this in the past, so I’ll share what I’ve discovered and where I have got to.

Firstly I want to make clear a couple of points about the way Unity3d applications can be deployed. One option for creating a client is standalone mode, in this the produced client will be an executable desktop app that works on Windows or OS X. The second and most attractive option for an OpenSim client is deploying as a Web Plugin that can be embedded in any webpage.

Now I’ve made these two options clear I’ll point out the additional difficulties of creating a Web Plugin client. Firstly any Unity3d app deployed as a web plugin is security sandboxed just as a java applet would be. In practical terms what this means is that certain standard API calls in the embedded Mono engine are not allowed. For example one fairly critical class that can’t be used is System.Net.WebRequest. As far as I can tell there is not a list anywhere of API functions that do not work, it’s a case of trial and error and trawling the Unity forums.

The second issue with the web plugin is that you can’t use any additonal C/C++ libraries you can however use c# dlls. The restriction this causes though is that your included c# dlls can’t rely on any platform specific external libs, think System.Drawing and libgdi.

So now lets look at what we need to implement an OpenSim client. First off we’re going to need to communicate with the server so we need libOMV, for creating a standalone unity application using a pre 0.7 libomv libary there is no problem, it works straight out of the box. Why pre 0.7.0 ? Because in 0.7.0 some features of .NET 3.5 have been introduced (see this opensim-dev post for detail) and Unity3d is on a back level version of mono, i’m not sure exactly which but i think it’s around 2.0.

It is possible to work around these changes and get libomv 0.70 working in Unity for a standalone client. However try deploying your simple log on and chat client as a Web Plugin and you will soon find that you don’t even get to the login stage as libOMV uses HttpWebRequest which doesnt work in the browser plugin. The fix for this is to rewrite parts of libOMV to use the unity WWW object instead.

So next up we’ve got the issue of 3D object formats which luckily is solved (in the most part) by the availability of the PrimMesher library written by Dahlia. I spent some time the other week getting this working and shared the Unity side of things with Dahlia who has gone on to get sculpties working as well. The remaining issue with objects is texturing and more specifically the decoding of jpeg2000 images. At the moment I’m decoding these to regular jpegs on the server side before assigning the textures in Unity.

I guess that leads onto the discussion of whether to bother with trying to get libOMV working in the browser, personally i think it’s worth it. Many would disagree as they don’t see a client embedded in the browser as any different from a desktop app, however this argument is neutralized somewhat by the fact that Unity can communicate via javascript with the page it is embedded into, this leaves open the possiblity of widgetized system for things like inventory management, chat etc. etc. and custom widgets for different opensim grids.

The alternative option of course is to write a Unity specific client library and implement the matching iClientApi, this may in fact be a better solution as keeping a forked libOMV version just for unity will be a bit of a pain. The down side of this alternative is that the client won’t work with the main Second Life grid.

So that’s the end of this little brain dump,I hope it has informed anyone thinking of tackling a Unity client for OpenSim and also hope it hasn’t put you off at all.