OpenSim on half a buck a day

I recently decided to see what the big deal was about OpenSim. After initially installing it on my desktop computer and connecting to it with the latest Release Candidate viewer, I decided to try to set it up on an inexpensive hosting account to see how feasible it was to run a real sim live on the Internet. Today's blog post talks a bit about how I did it, it's not a how-to guide, and you'll probably need to be a bit of a Linux geek to follow along, but hopefully you find it interesting.

The first step for hosting OpenSim was to find a suitable hosting account. Many people try to simply connect a server to their home DSL or Cable Internet service, but there are many disadvantages to this approach, mostly arising from the inexpensive equipment provided with such services often not being particularly easy to set up for inbound connections and the fact that most Telco and Cable service providers discourage the use of home Internet connections for hosting servers. Generally, if you want to host your own server, your best bet is some form of hosting provider.

There are a number of options for server hosting, including some people who are renting pre-configured OpenSim servers. Given that you can get a nice OpenSpace region (interesting to note the similarity between OpenSpace and OpenSim, intentional?) from Linden Lab for $75/month, it's my humble opinion that it defeats the purpose of setting up your own OpenSim server if you have to pay anywhere close to that much. That said, you're not going to be able to host OpenSim on a typical inexpensive shared hosting account, because it needs it's own dedicated IP addresses and ports as well as needs to have software installed that most shared hosting accounts don't provide. Luckily, there has been a recent trend to offer what's called "virtual private servers", which uses virtualization software like VMWare or Xen behind the scenes to host multiple virtual servers on a single physical server. To you and the software you install, virtualization makes it looks like you have an entire server to yourself. After some research, I found that SliceHost offers a $20/month virtual private server hosting plan which appeared to provide enough bandwidth and computing resources to comfortablely host an OpenSim simulator. Following the excellent instructions on the SliceHost website, I was able to start with an Ubuntu Hardy Heron OS image, and install Apache, MySQL, PHP, Perl, Python, Mono, and phpMyAdmin. One key point of divergence from the SliceHost instructions was when configuring the server's firewall, it was necessary to allow access to all the ports necessary for OpenSim to operate.

I initially tried to use the same pre-built OpenSim binaries that I used on my desktop. After a few mystery crashes, I decided to use svn to get the latest version of the OpenSim code. The instructions on the OpenSim website were fairly straightforward, and I was pleased that I was able to reasonably easily compile the latest version of OpenSim.

By default, OpenSim provides very minimal physics features that don't do things like prevent you from walking through walls. The recommended physics engine is called OpenDynamicsEngine, and a pre-built binary was also included with OpenSim, but this version had problems as well, forcing me to also rebuild the OpenDynamicsEngine from source to get it to work.

OpenSim can be run in either standalone mode, as a private grid, or connected to another grid. The documentation of standalone mode versus as a grid is somewhat unclear in that standalone mode is technically a simple form of a grid in that you can have as many regions as you want in a standalone simulator. I was initially confused and thought that you needed to run a grid in order to have multiple regions, but this is in fact not the case. Typically, you'll probably only use grid mode to connect a region to an existing grid, such as OSGrid. In my case, I wanted to have my own set of regions that were part of my private sandbox grid as well as have one or two regions connected to OSGrid. This proved simple to do with a couple of caveats. First of all, when I set up the firewall, I needed to make sure that I opened enough ports for all the regions I wanted to serve. The only thing that the documentation didn't explicitly state was that I needed to create two copies of the opensim/bin directory so that I could run two instances of the simulator code, one for my private grid and the other for the regions I intended to connect to OSGrid. I'm still not sure if this is absolutely necessary, but I'm pretty sure that you have to keep these installations in separate directories because they need different configuration settings in their respective OpenSim.ini configuration files. One other detail was that it was necessary to change the setting "http_listener_port" in the OpenSim.ini file for my OSGrid simulator to be the first port number in the series of port numbers assigned to the OSGrid regions.

There were a few other things that I needed to learn through trial and error and reading between the lines of the documentation. One important tip was that OpenSim isn't yet set up to easily be run and administered in a "headless" fashion. When the OpenSim server starts up, it goes into a command-line mode where you are able to administer it by entering in commands. In order to do this without having to stay connected to your server all the time, a tool called GNU Screen can be used to allow the server to run in command-line mode while still letting you disconnect and reconnect to your server via SSH.

After completing these steps, I had 3 regions in a private grid and another region attached to OSGrid, all on a $20/month hosting account. It's hard to beat that kind of price/performance ratio, although this certainly wasn't a project for the faint of heart. If there is enough interest, I'll put up a page with the start to end steps I took.

Of course, once you do this, you'll still have to grapple with the issues of having a Ruthed avatar with bad hair and skin. Using Second Inventory and test LibSL TestClient, it's possible to move some of your SL content into OpenSim (only stuff you made yourself or you bought and paid for, of course), but that's the subject of another blog post.

Painting on the Second Life Map with Prims

If you look at the Second Life Map, you often can see designs and text on the various regions. In most cases, these are fairly primitive - simple block lettering or geometric shapes. The map is updated on a weekly basis by a program at LindenLab that first creates a picture of the terrain detail using terrain elevation and terrain textures and then looks at the prims that are below approximately 400 meters in altitude. In order to make it harder to put things on the map, though, this program only looks at the color data of the prims as well as reducing the entire texture to a single color value, so, for example, a 10x10 cube will only appear as a single color when it renders on the map. Putting a megaprim up with a photographic texture will only result in large monochromatic shape.

So, how do people manage to put more complicated designs onto the map? The answer is that they construct the image out individual colored prims arranged into whatever design they want to repesent. There are some very nice examples of this out there, but they tend to be the result of a lot of work by determined individuals.

After some thought, I realized that you could automate the process, and after a lot of hair-pulling, figured out how to do it. Here are some pictures of the results of that effort:





And, if you want to see an example of this on the map, look here (click on it to go to the SLurl map page):



Now, to see how these pictures were actually rezzed in-world, here's a video I made of the process:

Click To Play

Figuring out how this could be done turned out the be the easy part, implementing it was considerably harder. First of all, using a single prim for every color "pixel" would have used too many prims for this to be practical. Luckily, the answer came from the popular XYText script, which uses a technique of flattening prisms to create a rectangular shape with 5 upward facing surfaces, allowing 5 pixels of color to be displayed per prim.

The second challenge was how to get the color information into Second Life. The goal was to make this easy enough that anyone with an image in any of the standard file formats (GIF, JPG, PNG, BMP), could turn these into a MapPainting. Writing a Java application to take these images and turn them into textual data that LSL could work with was largely straightforward. Unfortunately, the result was still enough information to fill several notecards. The first version of the project simple wrote out a set of textfiles which the user could copy and past into a notecard within the Second Life viewer. This proved cumbersome for the testers, all of whom were fairly sophisticated SL residents. The solution was to turn the desktop application into a web application, and simply allow people to upload their image onto the NowhereVirtual.com web site. The in-world scripts connect to the web application which feeds them exactly the data they need. The result is a much simpler process, the user simply uploads an image on a web page, clicks "Rez" from an in-world menu and away you go.

The final challenge was how to rez this many prims this quickly, given that LSL automatically slows down the scripted creation of new prims to make griefer scripts less effective. We'll keep the solution to that problem a trade secret for now. ;-)

The final product, MapPainter, is available in two versions, the full version which can fill a sim, and the lite version, that will fill a 4,096 square meter parcel. You can purchase it in-world or on SLExchange and OnRez:

MapPainter at SLExchange
MapPainter at OnRez
Nowhere Virtual Ministore

For more information, visit the Nowhere Virtual website:

MapPainter Product Page at Nowhere Virtual
MapPainter Documentation Page at Nowhere Virtual

TerrainTool and more on Sculptie Sim Models

In my last post from way back in June, I mentioned that I was writing a program to help produced sculpties from sim RAW terrain files. I've been delinquent in following up on that, and to that end, have finally uploaded a copy of the TerrainTool program that will let you do this. You can find it here:

http://www.nowhere-sl.com/terraintool/

This was part of an effort to make a more full-featured terrain visualization tool in Java, which perhaps at some point will happen. In any case, it's quite useful for producing sculptie textures that can be uploaded into Second Life and used to make scale models of sim terrain.

One thing that can be useful when making these types of models, is to texture them with the actual image from the grid map. Here's a short script that will let you get that for the region you're in:

string getSimMapURL() {
    string regionName = llGetRegionName();
    vector rc = llGetRegionCorner();
    integer regionX = (integer)(rc.x / 256);
    integer regionY = (integer)(rc.y / 256);
        
    llSay(0, "Region \"" + regionName + 
        "\" at: " + (string)regionX + 
        ", " + (string)regionY);
        
    integer mapY = 1279 - regionY;
        
    string mapApiRestEndpoint = 
        "http://secondlife.com/apps/mapapi/grid/map_image/";
    string mapImgUrl = mapApiRestEndpoint + 
        (string)regionX + "-" + 
        (string)mapY + "-1-0.jpg";
       
    llSay(0, "Map Image URL: " + mapImgUrl);
        
    return mapImgUrl;
}

default {

    state_entry()
    {
        llSetText("Click me to get the Map URL for the current region",
            <1,0,0>, 1.0);       
    }

    touch_start(integer total_number)
    {
        getSimMapURL();
    }
}

Simply drop that script into a prim, click on it, and you'll get an image URL like this:

http://secondlife.com/apps/mapapi/grid/map_image/926-344-1-0.jpg

Following that URL will take you to the actual image from the grid map, which should look something like this:



Simply save that image and upload it as a texture into SL, and you can apply it to your scupltie sim model.

Making Region Sim Models Using Sculpties

Check out these pictures of the scale model of the Nowhere sim that I made using sculpties. Turns out it's not too difficult to create a sculptie texture using the region RAW file and Photoshop. I'll post detailed instructions for doing this by hand as well as a tool for automatically generating these soon.

Open-Sourcing my Update Server scripts

I posted the code for the update server I use to update the teleport pads on Nowhere on the Second Life Wiki. I use AubreTec Teleport Pads for teleporting between locations in the sim, and I've been quite happy with them. The problem is that the pads are configured with two notecards, one of which contains the locations and the other than contains authorized users. Whenever I add a friend to the list of authorized users or add a new teleport pad, I need to visit each pad and copy new notecards in, which gets pretty tedious. Since necessity is the mother of invention, I wrote up an update server which distributes these new notecards automatically. I later started using this system for updating Freeview screens and anything else that gets configured this way. You can find the code on the Second Life Wiki at the following link:

Intra-Region Update Server

Hope you find it useful!

Emma vs. the Subway

Emma vs. the Subway
Originally uploaded by Emma Nowhere.

I meant to post this earlier... I took this picture at Downtown on the day it opened to the public. I can't say enough how beautifully crafted this place is, or to do justice to the emotions it provokes in those who visit it. I really wish I'd saved this picture to disk as a high resolution file rather than as a 512x512 texture, but I still love it. I really wasn't sure what would happen when the car hit...

Twittering from SL

I've read a number of blog posts by Ordinal Malaprop, Kisa Naumova and others about using Twitter from SL. Very cool stuff! The great thing about Twitter, from a scripting standpoint, is that if you just want to do updates from within Second Life, you can do it with just a few lines of LSL code and post directly to the Twitter servers. Here's a simple example that I hope you'll find useful:

//put your Twitter username and password here
string twitter_user = "";
string twitter_pass = "";

updateTwitter(string update) {
    if ((twitter_user != "") && (twitter_pass != "")) {
        string url = "http://" + twitter_user + 
            ":" + twitter_pass + 
            "@twitter.com/statuses/update.xml";
        llHTTPRequest(url, [HTTP_METHOD, "POST", 
            HTTP_MIMETYPE, 
            "application/x-www-form-urlencoded"], 
            "status=" + llEscapeURL(update));
    }
}

default {

    state_entry() {
    }
    
    touch_start(integer num_detected) {
        updateTwitter("Hello from LSL");
    }

    http_response(key request_id, 
        integer status, 
        list metadata, 
        string body) {
        //always returns a 415 error
        //unless it fails, in which case
        //a 500 error is returned
    }

}