Modularity
OpenSim’s all about modules. Physical engine? No problem! By default, you have none enabled. But you have an option of four different ones. Just choose the appropriate one depending on your hardware (Open Dynamics Engine gives the best result but is also the heaviest). Problems with detecting volumes? (important for knowing when your avatar is going under an arch or bumping other avatars) Well, choose simple meshes (just cubes) if you have little CPU available; get complex meshes to get fine-grained volume detection. And of course you can mix and match OpenSim versions and setup different modules on each sim (or at least each server) for all your grid — Linden Lab called the possibility of having different versions of the simulation software in the same grid the “Heterogeneous Grid” and it was a masterful effort taking several years and dozens of developers. OpenSim does that from Day One.
We also remember the (thankfully short) issues about bringing Mono as a new virtual machine for running LSL scripts, which makes them run faster, have a bit more memory, and most important, keep resources low on the simulators. OpenSim is a full Mono application from scratch. The virtual machine that runs LSL scripts is, obviously, written in Mono as well. But there is more: LL gives you two options, compiling to the “old” LSL virtual machine or the “new” Mono virtual machine (faster). But the language for writing scripts is always the same, Linden Scripting Language (LSL2). OpenSim goes way further. First, you have an option of what compiler you can use — there are two. Then you can pick from among a selection of programming languages to write your scripts, of which LSL is just one — you can use C#, VisualBasic, or JavaScript, and if you wish more, you can easily add them by writing your own compiler. Even better: you can run a grid with individual sims having a different selection of programming language compilers, but all will run the compiled scripts, even if they come from different versions!
If you’re already drooling, there is more. Although LSL compatibility is around 85-90%, this means that a handful of LSL functions are still unimplemented. But to give you an idea on how fast the implementation of the full set is progressing, here’s an idea. I tried very early on to run Francis Chung’s free and open source Franimation Overrider, used by about a hundred thousand Animation Overrider packages, on OpenSim. The idea is that this is one of the most complex scripts I’ve got. A year ago, it didn’t compile at all, not even with serious tweaking. Half a year ago, omitting some functions, it did compile, but didn’t work. Nowadays, it works flawlessly — so in 8 months or so, OpenSim’s developers went from “crippled” in-world programming to “almost full functional” status. Not bad, considering that in the process they have added a lot of things that LL never ever dreamed about.
One of those “things” is the ability to directly call functionality from the server. You all know how the first-generation ‘bots worked to extract significant data like avatar metrics, land parcels, objects (for external search engines), and the like. LSL has poor support for all that. Things like sensors are painfully slow, consume oodles of resources, and don’t always get all the information. What those ‘bots usually did was to do several “passes” for each sim and update the information on external databases every time. These days, most of those ‘bots use libSL, because it has access to all information and bypasses LSL totally — it’s fast, efficient, and consumes few sim resources.
OpenSim goes way further than that. It includes those function calls in LSL — they’re extensions to LSL (functions get prefixed with “oo” instead of “ll”), and you can call basically everything you wish to know about the sim you are — directly. This naturally means far more efficient LSL-based “metrics robots”. It is also “dangerous”, so the OpenSim owner can turn those extensions off if they wish or limit the functions that are available.
But to get access to even more data, OpenSim includes a RESTful interface with web services to almost every bit of information. This means you can do simple HTTP requests to ask a sim how many avatars it has, where the parcels are, where people are, and so on. You don’t need to use LSL for that; you don’t need to log in with libSL; you don’t need to develop an application in LSL/C# but just use whatever you prefer for making HTTP calls. It can even be simple Javascript on a Web browser!
Now LL has been doing the same for years, since they also have realised that providing these statistics without needing LSL scripts or libSL-based ‘bots relieves the load on their servers. Well… allegedly, a large part of the web developer team at LL is doing exactly that for over two years now (which eventually became LL’s my.secondlife.com project, status unknown). You have probably seen those nice in-world displays that show you your own profile picture when you come near them — they use LL’s interface to get that data. And possibly you also have seen SignportMarv Martin’s huge effort to extend LL’s own web services and provide semantic extensions on top of that.
OpenSim has all of that already implemented.
Then come the whole plethora of external applications. These are one of the areas where OpenSim shines. It seems so obvious that it’s completely impossible to understand how Linden Lab never did the same.
When you configure your OpenSim for the first time, you can select on the configuration file if you wish it to run on “standalone” mode (just your sim). But with some simple changes, you can run not only your own private simulator, but all other servers as well — user server, grid server, asset server, inventory server, and messaging server (collectively known as the “UGAIM” servers). So, it’s the same code for all servers, all you need is to change some parameters on the configuration file. And you have several choices of what database to use. Die-hard MySQL fans will naturally use that as their database of choice (the same that Linden Lab uses, after all), but you have more, simpler options (granted, with less performance) if you don’t wish to use MySQL.
And, of course, you’re not limited to run one sim per server. You can run as many as you wish. One, four (like LL does), sixteen, a hundred, a googolplex… the choice is really yours, it all depends on how many your hardware is able to support.
But that is, obviously, not all. You can run those UGAIM servers on the same machine as your sims, or on different machines — one per UGAIM server, or one for all of them. Database storage can also be on the same machine or on a different one. This means that it’s easy to plan for your own personal mini-grid: start with everything on a single server, if you wish, then separate the servers as the grid grows and you require dedicated hardware for each external server. Your other servers on the grid can just run simulators (and no UGAIM servers) and point back to your UGAIM servers. Or if you wish to “move” your sim between grids, all you need to do is to change the UGAIM servers it points to (you’ll see below how this magic has been expanded to do quite neat intergrid connectivity).
But wait! There is more!
