Anyway, there are people in Second Life that I like being able to communicate with. However, when I’m at work, it’s a lot of trouble to create an SSH tunnel home, then forward a text-only client like ommviewer-light just so I can log in and see who is online.

So, as I always do, I went way overboard and created a system that can relay chat between an IRC channel (or channels) and any location (or locations) inside Second Life (or any other grid that supports LSL). It can also check the online status of users and send them one-way IMs. I call the entire system slrelay, and you can get it here.

It requires a few things to work: a running webserver is absolutely necessary. If you want the IRC features, then you also need an IRC network of your choice and a machine that can execute perl scripts. I have my IRC bot connected to irc.slashnet.org.

slrelay has a number of possible uses. You could use it to relay chat between key locations on a large landmass (say, an area that spans 3 or 4 sims). It could relay chat between Second Life and another metaverse grid like OSGrid. It can be used as a simple IRC tool to check who is online very quickly. Or it can do all of these things at once.

Before we begin

You will need the following software for this tutorial. All of this software is free and open source.

• Blender, a professional 3d modelling tool. Blender is powerful but complex, and basic blender knowledge is assumed for this tutorial. Blender will be used to actually create the heightmap.
• The Gimp, a powerful program for creating and editing raster (i.e. normal) image files. The Gimp will be used for splitting the heightmap into RAW terrain files that OpenSim can use.
• gimpterrain, a plug-in for The Gimp that allows it to open and save RAW terrain files.
• terrainerizer (optional), a bash script I created to automate splitting the heightmap into RAW files. Terrainerizer only works on Linux, and still requires The Gimp and gimpterrain to be installed. It also requires ImageMagick.

In addition to the above software, you will also need a blank RAW terrain file. You could download a terrain file from OpenSim and transform it into a blank one (replace the Height layer with #ffffff, replace the factor layer with #808080), or you could just download this one that I have created for you.

Create a heightmap

A good tutorial on creating a generic heightmap in Blender can be found here.

The tutorial above creates a heightmap that is 512×512 pixels. However, an OpenSim RAW terrain file is only 256×256 pixels. This means that the above tutorial will create terrain for 4 regions, arranged in a square. If you need terrain for a different number of regions, you can modify the above tutorial to create different sized heightmaps.

For example, suppose you want to create an oblong island that is 2 regions by 4 regions in size. To do that:

1. Create the plane, but instead of scaling it to 2×2 blender units, scale it to 2×4 blender units. To do this, you can use this command sequence in blender:

• Right-click on the object to select it.
• Change the mode to Edit mode.
• Press ‘s’, ‘y’, ’2′, ‘return’.
• Press ‘s’, ‘x’, ’4′, ‘return’.

Now you should have a plane that is oblong instead of perfectly square.

2. When you configure the render settings, you will need to use different values.

• In the Scene settings (F10), SizeX and SizeY should be set to 256 * (number of regions). In our case, we have 2 regions in the Y dimension, and 4 regions in the X dimension. So, SizeX should be set to 1024, and SizeY should be set to 512.
• In the camera settings, the scale needs to be adjusted to fit the plane precisely. In our example, the scale should be set to 8. To get it just right, select the camera, and press Numpad0 to switch to camera view. You should see two concentric rectangles composed of dashed lines. Now, press F9 to view the Editing options for the camera. Now, adjust the Scale value until the outer dashed rectangle encompasses your plane completely, without including anything outside the plane. If the dashed rectangle is not the same shape as your plane, then you still need to set SizeX and SizeY in the Render settings.

Creating RAW terrain files with the Gimp

Now that you have a heightmap file, you still need to turn it into terrain files that can be uploaded into OpenSim.

Enter Domino Marama, creator of gimpterrain, an import/export plug-in for the Gimp that can handle the OpenSim RAW terrain format. Download gimpterrain and install it into your gimp plug-ins directory.

Now, if you are running Linux, you can automate the rest of this section with my terrainerizer script. See below.

We also need the blank terrain file that I mentioned earlier.

Armed with these tools, we can open a terrain file in the gimp and combine it with a portion of our heightmap.

1. Open your blank terrain file (blank.raw) and the heightmap in the Gimp.
2. Using the Rectangle Select tool, select a 256×256 pixel section of the heightmap, starting in the upper-left corner.
3. Click Edit -> Copy
4. Select the terrain file and make sure the Height layer is selected.
5. Click Edit -> Paste. You should see the section of the heightmap you copied appear as a floating layer.
6. Click Layer -> Anchor Layer. The Height layer should now look like the copied portion of the heightmap.
7. Click File -> Save As and save this file as a new file with the .raw extension.

Now, repeat this process for every 256×256 pixel section in your original heightmap.

Making it easier

Performing the steps in the previous section is very tedious, especially given how long it takes to save the terrain files. To make this easier, I have automated the process with the terrainerizer script.

If you are running Linux, simply put the terrainerizer script somewhere in your path. Edit it and specify the path to your blank.raw file, then run:

terrainerizer heightmap.png

Replace ‘heightmap.png’ with your heightmap file. Now let terrainerizer work. It will handle everything we did in the previous section automatically. It may take a while, depending on how large your heightmap is.

When it is finished, terrainerizer will leave several files in your current directory, named with this scheme:

heightmap-nxm.raw

Where ‘n’ and ‘m’ are numbers starting at 0 that represent the column and row for that terrain file. So, 0x0 is the top left region of your terrain, 0x1 is the next region (moving from top to bottom), and so on. Just upload these terrain files and you’re done!

Uploading the terrain files

Now that you have the terrain files, you can upload these files into OpenSim. There are two ways to do this.

1. From the OpenSim server console, you can simply:

change region RegionName
terrain load /path/to/terrain.raw

Repeat this for each of your regions.

2. From a viewer connected to OpenSim (assuming you are using Hippo or a similar viewer):

• Move to the region you where you want to upload terrain.
• Navigate to World -> Region/Estate -> Terrain
• Click “Upload RAW Terrain…” and select the terrain file you created for this region.

The Upload Terrain menu in Hippo

Repeat these steps for each region where you want to upload terrain.

While I was off not paying attention, it seems that almost all of my predictions have come true. An open-source server for running a simulator and/or grid, OpenSim, has been created. OpenSim appears to have solved many of the problems, and implemented many of the predictions, of my post from 2006.

One “problem” that remains, though, is economy.

The problem I outlined in my original post was that without a robust permissions scheme, economy would break down. Looking back, this seems terribly unlike me. Even in 2006, I had a strong dislike for anything that reeked of Digital Rights Management (DRM) even for the me that wrote that post. The permissions scheme employed by Second Life, after all, is just a DRM scheme. Like all DRM, it attempts to keep the user from using the things they purchase the way they would like, and like all DRM it is ultimately futile.

Economy on a Closed Grid

On the Second Life grid, you use real money to purchase virtual goods, which might have any of a number of permissions associated with them (modify, copy, and transfer). This permissions scheme is enforced by the fact that Second Life’s grid is a walled garden; Linden Labs controls the asset server, so your data all exists in their hands. They safeguard it, preventing nefarious users from copying your creations.

Except, not really.

Like all DRM, this scheme just plain can’t work. It can’t. It violates information theory. It is mathematically impossible to give something to someone and then keep them from having it. This is a corollary to the Law of Cake. I will elaborate.

For the Second Life viewer (aka client software) to render the object, it needs a copy of the object. This copy is necessarily sufficient to reproduce the object. Since any viewer that can speak the protocol can connect to Second Life, all you have to do is create a viewer that copies the object data being sent to it.

In fact, exactly such a viewer has been written. Linden Labs responded to this viewer’s existence by appealing to their Terms of Service. Whenever a user is caught using CopyBot, they are banned from Second Life.

In other words, there is no technical solution, only a social/legal one. This is because DRM is fundamentally flawed; it is trying to achieve the impossible.

Even without CopyBot, you could just decode cached objects from the official viewer’s data cache. Programs have also been created which do this as well, although they are harder to use than the infamous CopyBot.

The point of all this is that the assumption that the Walled Garden protects your Intellectual Property is simply false. As with the rest of the Internet, piracy is a given. Anyone creating and distributing content on the web must start with that assumption.

Economy on an Open Grid

I haven’t explored OpenSim enough to determine whether it supports any sort of monetary transaction, but let us assume that it does. In other words, assume that you can, via direct credit card payments or via a virtual currency, purchase virtual goods. Even if you can’t do this yet, I have little doubt that OpenSim will support it eventually.

Now, let us further assume that I connect to OSGrid via a region that I run myself. This means that I control my own asset server, where my inventory resides. If I purchase an object with restrictive permissions on another region, a copy of that object will be transferred to my asset server, where I can simply log in via mysql and change the permissions. Now, I can create multiple copies of this object, or give a copy to someone else.

What I have done here is to defeat DRM, just like CopyBot. It’s considerably easier, and much harder to detect. However, in practice this is no less secure to the Intellectual Property owner than Second Life’s walled garden. It still requires a reasonable level of competence (running your own grid/sim) to exploit, so piracy is likely to be similar in rate. Of course, the open metaverse has no Terms of Service (although individual grids/regions within the metaverse may). But the technical merits are the same; when looking at the threat of piracy, the open grid has the same basic properties as the closed grid.

Of course, even without our own asset server, we could still use the same techniques to copy data that I described for the closed grid. CopyBot and copying assets out of cache work identically on an OpenSim grid.

Not a problem

Okay, so the economy “problem” isn’t really a problem, just a fact of life. In the words of the OpenSim folks:

[The existence of piracy] is the kernel of the belief that open grids are hopeless for a virtual-goods economy. DRM discussion aside, maybe they are hopeless. But then, everyone thought the web was hopeless for selling music, and look at the success of iTunes in spite of all the piracy that still exists out there.

I am not proposing that piracy is good in any way, merely describing how it is inevitable. You simply cannot restrict how users will use the things you buy. You can’t keep someone from copying digital data, if they are determined enough to do it. You can use restrictive terms of service and try to sue or press charges, but there will never be a technological solution.

So, to current and potential content creators shying away from the open grids: piracy is an unfortunate fact of life. It will happen. Start with that assumption, and work from there. If this means you don’t want to create digital content, I’m sure the creative community will miss you. If, however, you realize that some people will appreciate your work enough to pay for it, without worrying about the details, then you are in the company of some fine artists.