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