followers of the riveting¹ opensim-dev mailing list will have noticed that i “culled” AsteriskVoiceModule and SIPVoiceModule yesterday. the reason is quite simple: with the recent addition of the FreeSwitchVoiceModule we now have a voice module that works! and works without having to replace the SLVoice client that is part of the standard SecondLife® clients²

AsteriskVoiceModule which ansgar schmidt and i started last year — and which, together with work that alan webb and i did for the soon-to-be-released VivoxVoiceModule, provided the basis for the excellent work rob smart did for FreeSwitchVoiceModule — never really led to a complete voice solution as it required replacing SLVoice on the client side. rob figured out that FreeSwitch supported the same voice codecs that SLVoice was using and started experimenting. though FreeSwitchVoiceModule doesn’t (yet?) do spatial voice nor speaker indication it already works together quite nicely with SLVoice, so we decided to drop AsteriskVoice (and its little brother SIPVoice) from the opensim tree.

our Sametime3D test server is running a number of regions, some of them are rather on the monster side of things with gazillion scripts (ah, those brainstorming boards). until recently our opensim startup scripts would just grap a copy of mono and let it loose on OpenSim.exe and things would be working just fine.

sometime over the course of the last 10–14 days opensim must have crossed some (invisible) line drawn in the sandy thread beaches of monomania, as all of a sudden we noticed that three-avatar-meetings were working fine (chat & movement work) but as soon as we were joined by the fourth avatar, things came to a grinding halt: no movement, no chat (voice was still working but that’s to be expected as SL voice is pretty much running independent most of the time from what’s going on inside the region).

after some nose cone polishing, some more befuddled staring at the log files, and not finding anything immediately obvious, i went and discussed this problem with fellow opensimers on our intranet IRC opensim channel — sean had the good idea of mentioning the MONO_THREADS_PER_CPU environment variable. checking our startup script (just to make sure) showed that we were not setting it — and, thus, it was at its default setting of 50…

…so we went ahead and added it, setting it to 500. why 500? good question. and a question to which there is no clear answer: ask two opensimers and you’ll likely get three different recommendations, i’ve heard 75, 500, 1000, and also 2000. ralf haifisch recently tried to obtain clarity on this issue but so far the exact value for MONO_THREADS_PER_CPU remains a bit of magic.

and, guess what? that did the trick, it seems. we got over the three-avatar-limit.

here is the updated mono-build script for ubuntu hardy (intrepid might work as well).

update: since posting this i’ve been experiencing intermittent (that is, non-deterministic) mono crashes when running OpenSim, and have reverted to mono 2.0.1 which runs much more stable.

charles krinke, stellar director of osgrid, blogged about the first OSgrid metaversity C# classes that took place on teravus plaza yesterday:

Normally, I am one of the most conservative members of OpenSim, but to see a teacher, SnowDrop Short gather 12 students together, form teams of three, exchange e-mails, assign a little independent study is so exhilarating that I needed to describe it tonight.

this is really what 3D platforms are about: collaboration, learning together, accomplishing something together! excellent stuff!

also, considering that OpenSim is just a bit over 2 years old — not a bad accomplishment!

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!

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.

i was just reading Mo Hax’s post “caveat creatores: second inventory?” and got tickled enough by what he wrote to start a reply — which got a bit long in the end, so i’m posting my thoughts here…

what got me tickled were the following sentences:

Full permissions or not, moving any content from SL outside of SL seems unethical and probably illegal. I was sure I would find a legal statement expressly forbidding the copying of content from SL into other systems, like OpenLife or any OpenSim grid. But after rereading the entire TOS and all the SI FAQ I could not find it.

[...]

Using Second Inventory might actually be hurting OpenSim development. SI is becoming something of a defacto content migration tool for use in OpenSim grids. There is no real system for content around OpenSim grids and when pressed SI consumers usually respond, “Well I don’t think there is anything wrong with it.”

There is something wrong with it. Second Inventory combines open source libraries (that do most of the heavy lifting) with its closed code and security encryption asking buyers to just trust its copyright policies, which, according to the FAQ are ‘coming soon’ and have already made LL leery. So while Second Inventory makes money for its closed and ethically questionable product, OpenSim misses the support, even pressure, to improve.

i think we have to distinguish two cases here:

1. i create something entirely from scratch (my own textures, my own scripts, and so forht): according to the LL TOS i give LL a license to use what i upload/create (albeit a pretty broad license, agreed), but i still retain the IP

2. i buy something with full copy permissions from a vendor in-LL-world, that is i acquire a license not the IP.

in the first case, i can do whatever i want to do with my content: i can take it with me to whatever place i want, i can sell it, i can give it away for free, i can do all of that at the same time since i own the copyright (which is the IP in this case).

with the latter case we do have a problem: what exactly is the license under which i obtained the content? what does it allow?

the answer: we don’t know for sure. did the content creator own all the rights to the content parts she used in making the content she sold to me? from a (perhaps naïve) user perspective all we have are the permissions.¹ we assumed those were full copy permissions, so i can claim that i do have a license to copy the content in whatever way i want, including taking it with me to an OpenSim grid.

i can see that LL’s “permissions” system is basically a kindergarten version of a “license” system (it certainly is not a DRM system and was never intended to be that). it in no way addresses real “IP” licensing issues — and i seriously doubt that all of the content creators in SecondLife have thought about things like certificates of originality and about making sure that they do have the required licenses to actually sell (license) their content.

i argue that in the absence of a proper licensing system we cannot then complain about content being used in ways that we have not expected (i.e., full copy permission content being taken to other virtual world).

what i fail to see, however, is how this damages OpenSim. all it can do is give SecondInventory a bad name (perhaps deservedly, perhaps undeservedly) and it does point to (yet another) deficiency of SecondLife: no clear way of specifying licensing terms (how can you even express GPL licensing terms with the permissions system?).

for our Sametime3D build we have some rather script heavy regions (a brainstorming region, a scripted auditorium, and a fairly innocuous open space meeting area). having just installed sean dague’s excellent serverstats module for opensim i decided to compare the two OpenSim script engines, DotNetEngine and XEngine — we knew from first hand experience that DotNetEngine seemed to be more resource hungry, but didn’t really know how resource hungry and how it compared with XEngine.

in both case we had 5 regions running: two theater regions with lots of scripted chairs and a screen object, two brainstorming sessions with lots of little, scripted objects and the one innocuous open meeting space with a screen and a fountain in it. with both test runs i waited until all objects had rezzed and all scripts had been compiled and were started (and in both cases i clean out the bin/ScriptEngine/*/*.{dll,state} files). the base system is a standalone OpenSim system (compiled from subversion r7123).

here are the results:

the graph above shows CPU uses by DotNetEngine (blue area) and XEngine for my 5 region OpenSim. what’s surprising — perhaps even shocking — is the vast difference between DotNetEngine and XEngine. the Y scale is in %, so 2.0K % means, DotNetEngine drove our poor server up to loads of 2000%, whereas XEngine is just barely noticable (in comparison). that difference is confirmed by the next graph:

DotNetEngine (again, red area) seems to guzzle up what it can get, XEngine (again, blue area) is much more “reasonable” in its memory consumption.

very interesting. just from this brief comparison, XEngine seems to win hands down — if, that is, if we manage to get rid of the deadlocks during startup that we see every so often.

yesterday matthias schüssler and roger zedi from digitalk along with their technically well-versed dog visited us in rüschlikon to do a podcast about virtual worlds! having always been on the receiving end of podcasts (i just love listening to podcasts) it was a very interesting and exciting experience to be for once on the “sending” end.

so, if you understand german and swiss german and are interested in hearing dr scofield live tune in here.