As OpenSim becomes more stable, many people are looking into developing new businesses on top of it. That is great! An ecosystem of businesses is exactly what we want to happen, if OpenSim is to fulfill its potential. However, let me add a word of caution in the form of a personal plea regarding doing businesses on top of OpenSim: be careful with what you patent, or you may put yourself out of your business before you even create it by placing obstacles on the way of the infrastructure.
The OpenSim Library has been a neglected part of OpenSim since I can remember. Apart from a few animations and example scripts, there hasn’t been anything interesting there. Even though it was possible to add things to it, the process was so cumbersome and error-prone that no one cared to do it. So the Library stagnated. That stagnation has finally come to an end.
OpenSim now supports the concept of megaregions — several regions stitched together without borders. I love megaregions. For the kinds of applications that I am involved with, megaregions are a must — try sending traffic over a region border! (horrible). The diva distro comes with a megaregion.
However, megaregions have a few quirks and because of those quirks many people don’t use them. One of the major show-stoppers is importing content from existing non-mega regions. Yeah, it doesn’t work very well. But if you know the right incantation, it’s actually quite workable. I have been doing this regularly for the past 3 weeks, so I thought I’d make the incantation more public. I’m going to describe my exact situation — extrapolate for yours.
Today, while we were doing load tests in Wright Plaza, I was also doing another kind of load test on my standalone. This one relates to server-side bots. I was able to have a 3×3 megaregion with ~2,000 prims, 200 bots and my client connected to it!
My client was quite happy. The only thing that didn’t seem to be working was the walking animation. Apart from that, I was able to walk, fly, chat and generally interact without much lag. Pushing it to 300 didn’t quite work well yet, I was stuck in 10, 10, 10 on login.
We hit a milestone today in OpenSim. We piled up 52 avatars in OSGrid’s Wright Plaza sim, under 600M of RAM, and after an uptime of 10 hours. It eventually crashed, probably due to a lurking ultra-conservative lock somewhere in code. But hey! — this is fantastic news for OpenSim-based worlds. I can see 1.0 on the horizon.
Over the last few days, one of the key components of OpenSim, the code that deals with packets from/to the clients, has been replaced with a new packet handler written by Intel’s John Hurliman. This is proving to be a Good Thing. Also last week we have identified and eliminated a major memory leak that was making OpenSim eventually run out of memory.
Hopefully when we get to 1.0 we will be able to consistently support 50+ avatars simultaneously under 500M of RAM and without crashing.
There is a new diva distribution available. It is packaged out of the bleeding edge OpenSim, revision 11056. If you have the previous release installed, you can simply run Update.exe.
In the past 2 weeks there has been a lot of plumbing in OpenSim, and things have improved considerably. First and foremost, we have identified and eliminated a memory leak that was causing OpenSim to use all memory over time, and eventually crash. Now OpenSim runs on much more reasonable memory footprint, and stays within that limit [for much longer].
Second, we have rewritten the grid service from scratch. The grid service is the part of OpenSim that manages region registration and lookup. All OpenSim installations have a grid service, even if they are standalones. In fact this distinction between standalone and “grid mode” is becoming fuzzier and fuzzier. So much so that it is now possible to have grids by stitching together standalone installations of OpenSim — without having to run any other servers!
It’s no secret that I love OpenSim standalone installations more than “grids”. For most things I envision doing with virtual worlds, including installations in my university, I can’t see the value of having a huge virtual space that is both shared between several tenants and centrally managed. The things I like to do fit perfectly in a few regions managed and controlled by me. The UCI Grid is about to become a web of hypergrided standalones. I suspect that many people are on the same boat. It used to be the case that standalones were solitary worlds that didn’t connect to anything or anyone; with the Hypergrid, that has changed. Standalones now can connect to the rest of the Metaverse — OSGrid, ReactionGrid, your friend’s standalones, etc. It’s a big world out there, and you can access it from your own small world.
I’m happy to announce Metaverse Ink’s “Diva Distribution”– a lean and mean OpenSim distribution targeting hypergrided standalones that comes preconfigured and that is very easy to keep up to date with newer releases of OpenSim. The Diva distribution is, literally, my personal preferences using the many configuration options of OpenSim. Here is what it consists of:
- MySQL as the DB backend. I used SQLite for a long time. SQLite is really easy to use, it requires no installation, it’s great for beginners. However, it’s clear that SQLite doesn’t scale well for long-term worlds. Moreover, using a MySQL server on the backend enables very interesting hybrid architectures that I will be talking about soon. The diva distribution requires some expertise for setting up MySQL, but it’s worth it. The instructions that come on the distribution make the MySQL setup for OpenSim really easy.
- ODE Physics. Easy choice here. Even the official OpenSim distribution is about to change to ODE as the default physics engine.
- XEngine as the scripting engine, and lsl as the scripting language. XEngine is the most stable of the scripting engines we currently have, and lsl is the most widely used scripting language. All other language support is still experimental and fairly insecure.
- One Megaregion of 512×512 meters. That’s right! Megaregions just made it into OpenSim, thanks to Teravus, and they are working great. With megaregions there are no border crossings, everything is very smooth.
- MetaverseInk Search. If you want to make your world searcheable, mark your parcels “Show in search”, and they will be listed on MISearch’s engine. Others can teleport to your world from search results. Everyone can do this on their OpenSim by setting a certain configuration variable; the diva distribution has that preconfigured.
Over time we plan to add more goodies to the diva distribution, so stay tuned.
Additionally, the diva distribution contains two tools that make it really easy to configure and update your installation. They are:
- Configure: this is the tool you should run after unziping the first distribution. Be ready to tell it (a) the name you want to call your world; (b) the password for the MySql DB opensim account; (3) your externally visible IP address or domain name. Once you answer these questions, Configure will do all necessary configurations for you. You don’t need to edit any .ini files.
- Update: once you get the first installation set up, updating it is as easy as running the Update tool. Update asks no questions from you, it just does the right thing.
While the diva distribution comes preconfigured with my own preferences, it is possible to change these preferences to yours. For example, if you want more than a 512×512 megaregion, you can add more regions. The instructions for how to do that come in the documentation that is included in the distribution.
So where can you get it? Get it at http://github.com/diva/d2/downloads — the file to download is called diva-rNNNN.zip, which is listed at the bottom of that page.
Unzip it, read README, and follow the instructions from there.
Let me finish this post by reminding everyone that the current version of the Hypergrid, which we call HG1, is fairly insecure. Don’t take your favorite avatar to places that you don’t trust. HG2 is coming, but it’s not here yet.
Well, well, well. I’ve been so busy, I haven’t had time to post anything. A lot has happened since my last post. First and foremost, I got so much into OpenSim that I ended up being invited to become a core committer, back in December. This threw me into a serious case of programming addiction, of that kind that you neglect everything else. It was great! My recent one-month vacation got me out of the addiction, let’s see for how long… But here’s what I got so excited about: the Hypergrid.
The Hypergrid (HG) is a system architecture supporting decentralized virtual worlds. In other words, you host your world and it can interoperate with worlds hosted by other people and organizations. Yes, it’s a Web of virtual worlds. Users can teleport seamlessly between worlds.
I did the Hypergrid back in October/November, and it got integrated in the main distribution of OpenSim since then. Lots of people have their sims HG-enabled, including in the main open grid OSGrid.
The work on the Hypergrid is not over yet, it’s only half-way there. One thing is to enable this kind of interoperability; another thing is to make it safe for everyone. Since March or so I have been working on that second side of the issue — security. It requires changes in the client, so it’s a bit more tricky to deploy these changes. But they’re coming.
I will keep making posts about the Hypergrid. In the meantime, here are some useful links:
… and if you want to find Hypergrided sims, simply use MI Search.
You knew this was coming, and here it is: Metaverse Ink Search is now serving OpenSims around the world! This has been in the works for a while — in fact, it has been working for a while — but we kept it under wraps. A month ago or so, Eric Reuters wrote an article about it, but we still didn’t say much of how this whole thing works for OpenSim. This post explains it.
We worked with the OpenSim project in implementing the basic plumbing for search engines to operate in virtual worlds. We think this basic plumbing is the right support for searching virtual worlds, be them closed or open to the world wide web, and we are happy to see the grid-wide search project now using this same basic plumbing. The fundamental design philosophy is that the region’s data exposure to clients other than the viewer is a decision that involves 3 authorities: grid operators (if regions are connected to grids), region administrators, and parcel owners/content producers:
- Grid operators decide whether the grid is to be closed or open, and the amount of openness. For closed grids, their data should be off-limits to external search engines like MI Search, just like the data in Bank Of America is off-limits to Google. This can easily be achieved by setting region configuration variables appropriately. Those configuration variables can be set so that only a grid-wide search engine can access the regions’ data.
- For open grids and standalone sims, region administrators decide whether to expose the data, the level of data exposure, and *which search engines can access it*. This last part makes virtual world search subtly different from web search, and for the better. On the web, search engines find web servers, and their pages, by following hyperlinks. All data reached is assumed to be public and, as such, indexable. This has caused a lot of pain on the Web, so let’s not go there. The idea here is that region administrators decide who indexes their data, and how much data is exposed to them. Data can be exposed to one or more virtual world search engines.
- Finally, parcel owners and content producers decide what data is intended to be found by checking the “show in search” check box in parcels and objects. In OpenSims, that checkbox tends to be free of charge.
All this is accomplished by configuring a core module of OpenSim called DataSnapshot. The configuration is done in OpenSim.ini, in the section pertaining to the DataSnapshot module, and it allows the variety of behaviors described above. So if you want the searchable data in your region listed with MI Search, go ahead and configure OpenSim.ini for it.
A second optional module deals with serving images (see how it looks here). This module, called ImageService, is a region module that extends regions with the ability to serve images onto the Web, so that explicitly marked, rich 2D content can be shared within a grid and/or with the whole world. The only images served are those whose keys are exposed via the DataSnapshot module, i.e. images related to things marked for search. That way we avoid exposing the entire collection of textures stored on the grid/asset server. The ImageService module is available from OpenSim’s GForge. If you want MI Search to show pictures of your wonderful regions, go ahead and place the dll of the ImageService in your OpenSim/bin directory.
The DataSnapshot module has been part of OpenSim since April 2008; the ImageService is our latest addition. OpenSim region operators have been able to figure it out, even though there were no announcements whatsoever. So much so, that we now have hundreds of regions on our opensim index in a variety of places, grid-ed and standalones. We are really excited to provide the first glimpse of the emerging Virtual World Web!