guess what? today is OpenSim’s second birthday! that’s right it’s just two years old and already a pretty strong little (?) bugger. to quote the official OpenSim 2nd birthday page:

The consensus is that OpenSim was ‘born’ on Jan 29 2007, when Darren Guard (MW) made his prototypical c# 3D world server publicly available.

i became involved with OpenSim almost about a year ago: sean dague asked me whether i could help with trying to figure out why OpenSim on PowerPC was not quite working¹, which i eventually did² — and got hooked…

…since then i’ve been working on voice support, splitting the chat module, adding a couple of REST interface for regions, and have been heavily involved in IBM’s Sametime3D effort which extends IBM’s Sametime instant messaging product with the capability to extend a chat session into a 3D meeting space:

considering that it’s just two years since

…MW came on [#libsl] and said ‘I have a prototype for an c# SL server, but before I publish it I need somebody to log onto it to see if it supports multiple clients’… [OpenSim turns 2]

it is utterly amazing how far OpenSim has come already!

here’s to a brilliant future! to virtual world domination! happy birthday OpenSim!

the x200 i’m using has enough omph to power OpenGL on both the builtin display and the 1600×1200 external display. unfortunately whenever i moved that glxgears window on to the second screen it would just show…nothing. googling around for that showed that a number of people had the same problem but nobody had found a solution.

repeated staring at the intel(4) man pages resulted in the hunch to try and switch from EXA acceleration to XAA acceleration

Section "Device"
Identifier      "intel"
Driver          "intel"

Option          "monitor-VGA" "VGA"
Option          "monitor-LVDS" "LVDS"

Option          "AccelMethod" "XAA"
EndSection

an X server restart later, and, voilá!, glxgears shows its gears on screen 2. problem solved.

we currently are using LindenLabs’s SecondLife clients (and derivatives thereof) to login to and render our OpenSim based virtual worlds. as the SecondLife client is produced by LindenLabs for their SecondLife grid, it should come as no suprise that their client by default only talks to their grid(s). however, it is possible to tell the SecondLife client to connect to one of our grids…

…but the method is not very user friendly and rather requires “specialist” know-how — which is fine for developers but not really appreciated by normal users.

another issue that we face is addressing virtual world places in non-LindenLab grids: the SLURL way of doing this unfortunately works with the LindenLab main grid only, as it just translates the SLURL into a secondlife:// URI which addresses not a grid but the secondlife client itself and does not convey any information whatsoever about the grid on which the place is hosted.

so, we looked for a way to (a) simplify things and (b) allow us to address places in any virtual grid. we created a new URI scheme, the rezzme:// URI scheme (URIs are kind of the glue that ties the internet together: everytime you click on a link such as http://opensim.zurich.ibm.com/ you are using an HTTP URI).

rezzme:// URI scheme

each rezzme:// URI follows the scheme suggested by RFC 2396 and can either

• address just a grid:

  rezzme://opensim.zurich.ibm.com:9000/
  

• address a grid and a region on that grid

  rezzme://opensim.zurich.ibm.com:9000/zurela
  

• address a grid, a region, and an X/Y/Z location in that region

  rezzme://opensim.zurich.ibm.com:9000/zurela/128/34/23
  

• address a grid and include the avatar’s name:

  rezzme://Dr%20Scofield@opensim.zurich.ibm.com:9000/zurela
  

• address a grid and include the avatar’s name and password:

  rezzme://Dr%20Scofield:S3CR3T@opensim.zurich.ibm.com:9000/zurela
  

here’s an example rezzme:// URI:

    rezzme://opensim.zurich.ibm.com:9000/aluminium/128/128/33

rezzme:// protocol handler

the rezzme:// URI scheme by itself is just half the story: you need to have a protocol handler. luckily there is a “reference” implementation available over at the rezzme project on OpenSimulator.org’s forge for both linux and windows. it does require PyQt4 to be installed — you can however create a windows binary that has everything bundled.

the rezzme:// protocol handler parses rezzme:// URIs and extracts the grid server part. using the grid server part — opensim.zurich.ibm.com:9000 in the example above — it then attempts to obtain that grid’s GridInfo block via REST from the grid server and, if successful, uses the login URI information from the GridInfo block to configure the secondlife client (if it could not retrieve a GridInfo block it will use the grid server as specified in the rezzme:// URI instead).

if the rezzme:// URI included place information (region/island, X/Y/Z coordinates), the protocol handler will create a suitable secondlife:/// URI for the secondlife client.

other virtual world platforms

rezzme:// URIs are not just addressing OpenSim grids, far from it: the GridInfo block contains a platform value that is “OpenSim” for OpenSim based grids, but could be “SecondLife” for Linden Lab grids, or “ActiveWorlds” for active world grids. the reference protocol handler currently does not (yet) support values other than “OpenSim” or “SecondLife” but could easily be extended.

rezzme protocol handler features

other features of the rezzme:// protocol handler:

• bookmarking of rezzme:// URIs (including editor and quick access via system tray icon)
• support for external authentication mechanisms
• support for selecting and using different clients (different versions of the secondlife client, hippo client)

other schemes

aside from the already mentioned SLURL mechanism, there’s the OSURL scheme which is very similar to rezzme:// URIs but (currently) restricted to OpenSim grids.

a little while ago i posted a shell script to build mono 1.9.1 on ubuntu. since then mono 2.0.1 has been released and today i finally took some time to update the build script. have fun.