It has been a while since I made a D2 + Wifi releases. I had been waiting for OpenSim 0.7.1; the changes between 0.7.0.2 and 0.7.1 were such that I didn’t want to risk making a release in between. OpenSim 0.7.1 finally happened earlier this week, so here is the much awaited D2! Technically, it corresponds to OpenSim r15402, which is a couple of commits after the official release — I found a couple of bugs in the official release related to the Library, so I fixed them.

Things to pay attention to when you update your D2:

• This time after you Update, you need to run Configure again on your new installation, because of changes in configuration variables. In order for this process to be as smooth as possible, have your current config-include/MyWorld.ini open in one window while answering the questions for Configure in the new install. If you had made changes to your MyWorld.ini, simply add those changes to the new MyWorld.ini that is produced after running Configure.
• As usual, the Update tool will ask you if you want to preserve any changes you may have made to your Wifi pages. I always say “yes, I want to preserve my own.” By doing that, it’s guaranteed that the new Wifi installation will use the pages that I had before. However, this time there is a nice improvement in the splash.html page that shows some statistics at the bottom — see here for example. Not a problem. When Update copies over your old pages into the new install, it also places the new ones under WifiPages with extension .diva, for example, splash.html.diva. That way you can easily see the differences between the two and copy-and-paste the parts that matter. In my case, this time, I simply replaced the entire splash.html file with the new one; you may want to check your own changes.
• Marck added support for localization in Wifi (he’s German). Now you can have your Wifi installation in your favorite language. See here for how to do that (scroll down for the LOCALIZATION section).
• The Wifi administrator account has a teaser new link called “Console”, a new feature that we have been working on. It’s undocumented for the time being, because it’s not secure enough for me to recommend using it. It will come to life in a future release.
• Bad news: Teleports between OpenSim 0.7.0.x installations and OpenSim 0.7.1 installations are incompatible, because of a bug fix in libomv. You probably knew that if you had tried to HG TP to OSGrid.
• Good news: most large grids, like OSGrid, are already running 0.7.1, so you can finally join the crowd there.
• To test HG TPs, feel free to use my own world, http://ucigrid01.nacs.uci.edu:9001. It’s somewhere in the 5000’s and reachable from all D2’s if you haven’t changed your coordinates.

Have fun!

UPDATE (5/7): I realize that many people may not have noticed the subtle differences in HG addressing that happened between 0.6.9 (HG 1.0) and 0.7.0.x (HG 1.5), and then between 0.7.0.x and 0.7.1. Let me explain.

An HG address in the old HG 1.0 was simply the address of a particular simulator. HG 1.0 did not have the concept of “grid” in place, so even if a simulator was part of a grid, its HG address was the simulator’s address. For example, in the UCI grid you could reach individual simulators with addresses like ucigrid04.nacs.uci.edu:9007 (the Gateway 7000 region); note that ucigrid04 is the machine where that particular simulator runs, and 9007 is the HTTP port of that particular simulator.

With HG 1.5, the concept of “grid” has been put in place. A “grid” is a collection of simulators running under the same authority and that  share one single “Gatekeeper.” The Gatekeeper is central to HG 1.5 security and, in grids, it usually runs in the Robust server. The Gatekeeper is the entry point to every single incoming request like link region requests and agent transfer requests. In HG1.5 you cannot link directly to simulators anymore; you link to Gatekeepers wherever they live. For example the Gateway 7000 region in the UCI Grid is now accessed like this: http://ucigrid00.nacs.uci.edu:8002 “Gateway 7000″.  A few of things to notice:

• First, the “domain:port” syntax that was used before (and that is still accepted for the time being, but considered obsolete) has been replaced by a full-blown URL starting with “http://”. This is so that HG services can be implemented by regular web applications. For example, the Gatekeeper of ScienceSim lives in http://grid.sciencesim.com/grid/hypergrid.php — yes, a php script.
• Second, the URL is that of the Gatekeeper, not of the region itself. The region is referred to by name after the URL, and when the name has white spaces you need to use quotes. If you want to reach UCI Grid’s Gateway 7000 region, you can pull up the map in the viewer and type exactly what I just wrote in bold up there. Or if you want to use the link-region command on the sim console  you can type:
  $ link-region <local_x> <local_y> http://ucigrid00.nacs.uci.edu:8002 “Gateway 7000″
• Individual Gatekeepers may have different policies in place concerning incoming links, so a link request to specific regions inside a grid may very well fail; or it may be required. If you simply specify the URL of the Gatekeeper and omit the region name, the Gatekeeper is supposed to link you to a default region in that grid, if it is defined. If that’s not defined in the target grid, then the link request will fail.

For standalones like D2, there is no difference between “grid” and “simulator” — they’re one and the same. In standalones, the Gatekeeper runs inside the simulator. As a consequence, the HG address is that of the simulator itself. But  the points made above still apply, conceptually speaking.

UPDATE (5/8): well, foo! I found one wrong configuration variable in diva-r15402. I made a new release diva-r15402-b that corrects it. If you updated to diva-r15402, please update again, so that you get diva-r15402-b. No need to run Configure on this small update. Just run Update, switch to the new installation, run OpenSim from there and you’re done. (If you update from an older release, then you need to run Configure, as the instructions say).

Also, I found that it’s better to remove the old hyperlinks from the DB so that old formats don’t get in the way of your travels. It’s very simple. Login to your DB and issue this statement: DELETE FROM regions WHERE flags=524  (524 are hyperlinks)

I was sick-ish last week, so I decided to use my idle cycles to finally learn Unity3D. I thought I’d share my impressions, given that (a) I’m not a 3D modeler, not even an amateur one, and (b) my only experience with 3D environments has been Second Life / OpenSim. I suspect there are lots of people like me. Being an OpenSim aficionada, and fairly ignorant of everything else (mainly for lack of time), I always felt like I was missing the big picture. Indeed, I was, and I’m glad my cold last week gave me the opportunity to explore a completely different point of this large design space. The picture above shows one of the environments I created. The bottom line, if you don’t care to read more, is this: the Unity3D ecosystem feels like Second Life for grown ups.

Some Clarifications First

Before I describe my impressions, let me clarify a couple of things.

First, Unity3D is not a replacement for SL-style virtual worlds. It’s not even in the same ballpark. Unity3D is, first and foremost, a scene editor — a glorified building tool with powerful delivery options. Whether the scenes you create are single user, multi-user or MMO, that’s entirely up to you, the environment designer, to decide. Unity3D gives us enough hooks to create whatever we need in terms of networking. While it’s relatively easy (emphasis on “relatively”) to create single-user, non-networked scenes, it’s a lot more difficult to create multi-user environments; and by “multi-user” I mean environments that network a few shared objects among a few people. Unity3D doesn’t  support MMO environments like Second Life and OpenSim — it leaves that to 3rd party servers and client-side libraries, of which there are a few commercial ones. In other words, if you want to create a virtual world with Unity3D, you need a lot of extra engineering work. The more objects you want to share, and the more users you want to have, the more complicated things will be. Doing an SL-like virtual world, where everything is shared and where users can create new content, would be a major endeavor.

Second, when it comes to hooking up Unity3D to OpenSim/SL, the current conceptual model behind Tipodean and Rezzable is to develop Unity3D-based clients that download and render existing SL content. While I admire those efforts, and hope they continue, that’s not the only possible way of connecting Unity3D and OpenSim. As I said above, Unity3D doesn’t support MMO-ness. So there is the opportunity to develop that with OpenSim (some version of it) on the backend, but using Unity3D to create the scenes and the content in them. I am more interested in exploring this other model, not just because Tipodean is doing a great job with the other one, but also because I see many exciting things in Unity3D as scene creation tool — things I wished existed in the SL ecosystem, but don’t.

The Building Experiences

Having gotten those clarifications out of the way, lets now look at Unity3D for what it is: a tool for creating interactive stories with rich media. Which, to some extent, is what SL/OpenSim is (ignoring the social network aspects). So let me compare it with the equivalent in the SL ecosystem: how and what we build there. I’ll talk about the pros and cons of each.

Terrain

To create the scene pictured above, I imported a terrain I had, which I used in the previous blog post to explain sculpted terrains. (Side note: that terrain was one of the main reasons why I decided to look into Unity3D this week, I wanted to see how the same thing could be done there). It took me a very long time to figure out how to import the heightmap, more than I dare to admit — not easy to navigate through the variation of formats and options for these files… Anyway, I finally figured it out, and the terrain appeared as I wanted it in the Unity3D scene. Unfortunately, Unity3D doesn’t smooth the heightmap values out by default, so I had to do the extra work of smoothing the whole thing (it’s a large, 768×1024 terrain). With that done, I then overlayed the aerial image and added the water. This is how that scene looks like in the editor:

I can now make the first  comparison between building with Unity3D and with SL/OpenSim: when it comes to terrains, Unity3D wins by a long shot. In SL/OpenSim I had to make that hack of using sculpted prims in order to get the overlayed image on; in Unity3D that comes without any hacks: just import the heightmap, and overlay the image, as one would expect.

Cameras

Next, I had to learn about cameras — a concept that is hard-coded in SL. In SL we learn that there is exactly one camera that usually sits just above the avatar’s head, and that we can move independently by a combination of keys and mouse. In Unity3D the scene creators have a lot more options. There can be any number of cameras, each behaving in a different manner. For starters, I used the preexisting “First Person Controller” which includes basic movement with the arrow keys and the mouse, and a camera that follows that movement. Coming from the SL ecosystem, I confess I am in awe with this new concept of programmable cameras — they give so many more options for building user experiences! On the other hand, it’s a bit overwhelming to have to learn how to exercise those options — and this is a theme that pervades the comparison between the two. Indeed, I tried to program a camera behavior that would be more like SL (zoom in/out, pan, etc.) and got only half way there, based on a script I found in the Unity3D forums. I’m not giving up, I’ll get it working eventually.

Sounds

Next, I added a simple sound effect — birds chirping in a certain part of the scene. That was very easy. It’s easy in SL too. In Unity3D there are a lot more options regarding these sound effects; I didn’t explore them yet.

Scripted Movement

Next, I thought I’d reproduce the basics of my traffic simulation in OpenSim by adding a car moving on the road. (You can see the car on the road in the first picture up there). I didn’t think I would be able to do it in a couple of hours, but… I was wrong. It was dead simple. It took me longer to find a free model of a car than to code up the movement.  Granted, I reused all the knowledge I already had about making cars move in roads, but I wasn’t expecting it to be this easy. Looking back at my traffic simulation in OpenSim, and comparing it to what can be done in Unity3D, there is one very important observation to be made:

• For the purposes of my traffic simulation, it has always been an overkill to have the traffic be controlled by the server and distributed synchronously in almost real-time to every client connected to it. My traffic simulation has more the flavor of a particle system — it’s something I want to show to users, an illustration, but I don’t necessarily want everyone to see exactly the same thing. In other words, running it unsynchronized on the clients is just fine, and it frees the server of a lot of computation and networking.

Of course, this would break the underlying design philosophy of SL: complete shared state of the world. That is a very strong principle of the SL environment, and it makes sense for the kind of user experience they want to provide. However, it’s clear to me that that’s not the only possible model for these kinds of environments. As a scene creator, having the freedom to decide what runs independently in each client and what must be synchronized is a very good thing, indeed! Unity3D starts up by not sharing anything among clients, i.e. each client gets the scene and runs it independently. Then we, the scene developers, may choose to put some scene objects under the constraint of synchronization in a multi-user environment. Eventually, we may hook this up with a 3rd party server that does the synchronization more efficiently. I definitely like this model! But, again, it makes it much more difficult to develop shared environments, whereas in SL/OpenSim there is nothing but shared objects.

Objects

Next, I decided to create a building and add it to the model. (You can see that building in the pictures above) In SL/OpenSim, building things is the essence of the user experience: click the build button, tweak a few parameters, upload textures, apply them to the faces — done. Not so easy in Unity3D! In Unity3D, we can add the same “primitive” objects as SL: they have cubes, spheres, etc. But tweaking and texturing is another matter entirely, and this came as a shock to me. There is no simple way of applying different textures to different faces of objects. Instead, the conceptual model seems to be this: don’t use Unity3D to build the objects themselves, use it only to integrate them together in the scene. So in order to get my simple box-like building up in the Unity3D model, I had to give myself a crash course in 3D modeling tools. I started with Blender and quickly gave up (expletives omitted). Then I moved to Wings3D. Wings3D is noobie friendly, and the tutorials out there help. I was able to model a parallelepiped, and I learned about texturing — the pro version of it. I can see how much more powerful this pro version of texturing is, but, man…! How difficult would it be to add to these tools the simple version of texturing that SL provides? — select the face, associate it with a texture and you’re done. Oh well. I guess they don’t really care about noobies, they want people to act professionally and do “the right thing.” Anyway, here is a picture of my Wings3D model:

Eventually, I finished my box building and produced the texture for it, so I imported those 2 things to Unity3D and placed the building in the right place. That part was easy. But the overall experience was completely different from building in SL. I can’t say it was worse — it was different. Not being able to do simple things inside Unity3D  first came as a shock, but once I figured the basics of Wings3D I started to enjoy it; it gives me the feeling of being a super powerful 3D modeling ninja! No more being limited to half-a-dozen primitives — modeling with the full power of meshes is so much more empowering! Having to switch tools between individual objects and the scene is both good and bad. It’s good, in that it allows people to focus on each object at a time, possibly dividing the modeling job among many people independently. It’s bad, in that the immersive building experience (something that I, like so many people, greatly enjoy in SL/OpenSim) is cut off in chunks.

The Larger Ecosystem

In searching for free objects, I came across Unity3D’s Asset Store. This is the equivalent of SL’s Marketplace and the newer market places that are starting to emerge for OpenSim content. There aren’t a lot of freebies in the Asset Store, and the prices seem to be almost one order of magnitude higher than SL prices — something that would costs US$15 in SL costs US$50 in the Unity3D world. This probably reflects the pulls and pushes of these markets. It’s so much easier to build things in SL that lots of people do it competently, so competition drives prices down. Also the buyers in SL are people who buy things with their own personal money, so you can’t have high prices; in Unity3D, the buyers are professional game developers, so a $50 purchase is not a big deal.

Bottom Line

The building experiences in SL/OpenSim and Unity3D are completely different. Everything in Unity3D seems designed to support professional scene creations, whereas everything in SL seems designed to support amateur content. In SL, building is a large part of the SL “game,” of its entertaining user experience; in Unity3D building is a serious matter, it’s the activity with which entertainment is produced for others to experience. As such, Unity3D provides a much larger spectrum of options than SL. And, as a consequence, the learning curve is much steeper than SL’s. For every 100 people who can build in SL, there are possibly 1 who can build in Unity3D.

But did I enjoy building in Unity3D? I confess I had a blast! I absolutely love the many more options that I am given to create the immersive stories with this tool. Whether the stories are worth experiencing or not, that’s, of course, another matter…

I do a fair amount of work with people in urban planning. Realism in those virtual environments is the starting point for the imagined plans they have in mind. The very first thing they want is the realistic terrain of the area. It has proven difficult to get the elevation data of specific areas, but we always end up finding it in some obscure place or other. Unfortunately, the terrain by itself doesn’t quite give the feel of the area as it exists today. Instead, it gives the feel of the area as it might have existed 10,000 years ago! — no signs of human civilization. Which, as nice as that may be, doesn’t quite do the job for urban planning. This weekend I was finally able to generate realistic terrains in OpenSim overlayed with a realistic image. Here is the story.

Terrains in OpenSim/Second Life have always been a source of frustration for me. The problem is that the standard terrain in OpenSim/SL is textured with an inflexible combination of  4 textures, the details of such combination being completely hidden from us. We cannot do the simplest and most natural thing, which is to overlay one existing image on top of it. I have no idea why Linden Lab made this decision, as it seems like the single texture approach would be easier to handle than the complicated generative algorithm they have. But that’s what we have to deal with.

So far, my urban planning colleagues have managed to stay away from areas with interesting terrain, so we’ve simplified by flattening the areas and using mega-prims overlayed with the aerial images. However, recently we had to deal with an area with a non-flat terrain, and I could not escape the issue. Luckily the stars were aligned to my advantage.

My attraction to terrains is nothing compared to Nebadon‘s obsession with them. From all I can tell, he has spent hundreds (thousands?) of hours working on producing the most amazing sculpt-prim terrains. Here is an example, and here is another one. So I turned to him. We were talking about terrains last week, when he casually mentioned that Adam Frisby had given him a program that takes a heightmap and a texture and generates sculpt-ed terrain overlayed with the texture. That’s how he had been producing those amazing terrains. The tool was very rough, and he still had to do a huge amount of work manually. But at least the core of the algorithm for generating sculpties from heightmaps was there! I was excited, and quickly dived into the code — Nebadon was kind to share.

It took me about a day (yesterday) to clean that code up, and to understand the math, but I finally have the tool I wanted for the past three years! The result can be seen in the picture above, as well as many more pictures if you follow the link to Flickr. The tool now is completely parametrized, and, additionally to the textures, it also generates the prims themselves. Everything is automatic. I have a feeling I’m going to spend a lot more time on this amazing tool… at least until some viewer does the right thing and let us place our own images on the terrains.

For the past couple of months I’ve been flirting on and off with Amazon Web Services (AWS). This past summer my students started using it in some of our research projects, so I had to catch up with them. Those projects have nothing to do with OpenSim, but I made my own learning plan focused on getting an OpenSim instance to run in the cloud.

I must say I really like AWS, specifically Elastic Compute Cloud (EC2). I feel like a kid in a [computing] candy store! How much better can it get when you can have as many servers / storage as you want in a high-bandwidth / high reliability data center at the tune of pennies/hour?! Pennies per hour! Turn the thing off, and the charges stop! Very different, indeed, from billing model of traditional data centers.

Of course, learning how to operate non-trivial systems in AWS is not an easy hill to climb. Add OpenSim to the mix — a system with complex networking and configuration requirements — and it gets very challenging very quickly. But persistence will get you there, at least to the first milestone of having a diva distro server up & running in the cloud.

Geek fun aside, is it really worth it to use cloud computing for OpenSim virtual worlds? It depends.

First, let’s look at the benefits. You get a high bandwidth / high reliability data center for your virtual world, with a lot of flexibility regarding the cost. Compared to hosting in home networks, high bandwidth and high reliability is a very attractive proposition.  Home DSLs have notoriously limited uplinks; if you place a server like OpenSim in your home, uploads is what happens most of the time. As such, you aren’t able to serve that many external clients, and the ones served will feel lag. That’s what data centers are for. But traditional data centers are prohibitively expensive for casual hosting, as they have high fixed monthly costs, well above $100/month. Usually you need to have a business in order for a data center to become cost-effective; personal use is not really a use case for them.

Let’s look at the numbers in more detail. AWS is a flirt for any geek, because the prices, at face value, are so low. Look at AWS pricing, and you rarely see anything above$1. It’s all pennies! 1 server? $0.085/hour. 1GB of data? $0.10/month. Storage I/O? $0.10/million requests. Traffic in? $0.10/GB. Traffic out? $0.15/GB after a first free GB. Dirt cheap.

But pennies add up. If you want your server to be always on, the cost of the server alone is ~$60/month. Add to that  the I/O and network traffic, and this number can easily go well above $100/month if your world has a lot of action. The very smart people at Amazon know the economics of data centers… Nevertheless, if you make the calculations, AWS is actually very competitive with dedicated server hosting offerings, even in the always-on scenario. And the elasticity of the billing, the pay-for-what-you-use model, is a very attractive proposition.

Cloud computing only starts bringing real cost savings if one takes advantage of the elasticity of billing. Which means that one needs to make the server up-time elastic. In other words, turn it off if you’re not using it. Which is probably what you do if you host your virtual world at home anyway. Or if your use of virtual worlds is related to scheduled activities, such as classes.

So here’s my conclusion: for personal virtual worlds with not a lot of external traffic, home hosting is probably the best solution; you’re paying a fixed monthly fee for your DSL, you may as well max out the value that you get from your provider. But if you’re thinking about offering a virtual world for a larger number of visitors, and if that virtual world doesn’t need to be always on, then pay-on-demand seems like a very good idea indeed. Plus you help the environment.

It took a long time, but OpenSim 0.7 is finally here! It’s quite difficult to explain the value of refactorings and of  re-conceptualizations of the software, which is what happened to OpenSimulator between 0.6.x and 0.7. Those things tend to be intangible at first (“WTF? This does the same thing! And it has bugs that it didn’t have before!”, etc.); the ROI only shows up later.

As an example of the new interesting things that can now be done, this new release features an embedded Web application for handling user registrations. It’s called Wifi. The features of Wifi are quite simple:

• Account creation, optionally controlled by the administrator
• Configurable default avatars for new accounts
• Account updates by both users and administrator
• Account deletion by administrator
• Password recovery via email
• Simple user inventory management

These features are enough for the worlds I run; they’ll be enough for many people, I think. This is just the first release, I expect Wifi to improve as we go a long — especially if more people want to help… I welcome help on this!

See it in action in one of my test worlds. Feel free to create a dummy account, login to it, recover your password, etc. And login to the world afterward. You can also use it for testing your own installation of the diva distro by hypergriding to it. (Note: this world is just for demonstration of Wifi and of the latest diva distro release; it will be shut down in a couple of weeks)

Wifi has a few interesting properties that make it a good fit for small-to-medium OpenSimulator-based virtual worlds. First of all, it doesn’t require the installation of Apache or other Web servers; it’s all done within the OpenSimulator code base. If you’re like me, you will think of this as a major win. Not having to install an additional major component like Apache and PHP/Python/what-have-you means less administrative hassle, less load on the machine, and just plain joy. Web app! No Apache! Just OpenSimulator! Yey!

Second, using the OpenSimulator code base brings many technical benefits. This isn’t an immediate benefit, but it is a benefit in the long run. Unlike the Apache-based Web apps that interface with the DB directly, Wifi interfaces with the OpenSimulator services layer using the core code, and therefore it is isolated from future changes to the OpenSimulator DB schema. In short, and of interest to diva distro users, Wifi will probably never be in the situation that other apps of the same kind are, always on the verge of being discontinued due to the hassle of making it catch up with the OpenSim schema. In the long run, this is a very good thing.

Third, technically, Wifi is a set of components that can be loaded up by both standalone simulators and Robust servers. What this means is that the exact same thing can serve diva distro worlds as well as larger grids in one seamless environment, OpenSimulator. I haven’t packaged it up for grids, but I might consider doing it at some point. So if your world grows to a medium grid, Wifi can handle it with no hassle.

Enjoy!

And, of course, also enjoy the extra security in HG 1.5, but that is invisible.

Here are the relevant links:

• Latest diva distro
• How to set it up in 5 steps (6 for *ix)

If you already have a diva distro up & running, simply run Update.exe on it and follow the instructions. This time, it’s really important that you read the release notes.

One last important note: the sequence of upgrades has a ‘pivot’ release at r12751. In other words, r12751 is a mandatory stop from all older releases. From r12751 on, upgrade gets you the latest. This new release today is r13458.

Yesterday, Stefan wrote down his thoughts on Linden Lab’s troubles. I loved that post, he’s right on. Let me add to that by stating the importance of the work that many of the laid off Lindens did, and the role of OpenSimulator from here on, at the technological level and beyond.

Things are moving into 3D, including the Web. I’ve been very excited with everything that is going on with WebGL. Sure, WebGL is still not good enough to render very rich scenes like those we find in highly immersive games, especially when the scenes aren’t optimized, such as the case with user-generated 3D content. But I have very little doubt that the needed optimizations will happen, and that soon we will have immersion on the web browser. It’s already happening. People want it, Google wants, it will happen.

So, let’s fast forward to the time when the Web browser can render rich 3D scenes, which, at the rate that the Google people and the Unity3D people are going at it, it probably is only a couple of years away.

Technically, the client-side is not the whole story. In order to develop highly immersive real-time environments with that kind of viewer, we still need a server side that can serve those 3D scenes in real-time to several clients. HTTP alone won’t do, it’s too slow. All MMOs use some sort of UDP-based protocol for the rapid state change notifications. HTML5’s Web sockets are there precisely for that reason.

Bottom-line: the server-side must serve more than HTTP.

There are a few of these game servers out there, the vast majority of them proprietary. Which is fine for the companies that own them. In the scenario where the browser is the 3D viewer, those companies can easily develop the necessary JavaScript components that talk to their back-end servers via WebSockets.

All these proprietary servers, however, are a bottleneck for the massification of 3D content on the Web. Just like for the Web itself, we need open source 3D scene servers. At the very least, we need open, standard protocols, so that people can focus on developing content without having to reinvent the network connectors, and the servers, from scratch all the time. (But with open standards come open implementations, so the result is the same: we need open source servers). Yes, we need an Apache for RT 3D scenes. Hmm, where did I hear that before…?

OpenSimulator, of course. When WebGL is good enough to render those rich 3D scenes, OpenSimulator will be there to serve those scenes in real-time to multiple clients. For free. This is the real importance of OpenSim, its main contribution. Another, secondary, contribution is all the research work that we have been doing in secure, portable identity with the Hypergrid. This is something that doesn’t exist on the Web, but it can be ported back. I’m not entirely sure the 2D Web needs it, but I’m pretty sure a web of virtual worlds needs it. Not all 3D environments will want to be connected in a web of peer servers; but many will.

In all of this, we must thank Linden Lab, especially Cory Ondrejka and Marc Lentczner, for making their protocol public; that made OpenSim legally possible. All other game companies are protective of their protocols, to the point that they go after anyone who tries to reverse-engineer them. That was not the case with Linden Lab, and we must thank them for that. They allowed us to focus on the server side. The fact that the client was available independently, for free, was no small thing either: it made the effort appealing to lots of people who got instant gratification of a Linden-like world on their own computers. More people means more eyes, more energy. MW and Lbsa were right on from the very beginning!

Going forward, the main challenge for OpenSim is to step back from the monstrosity of LLUDP and LLCAPs, which were designed for one very particular kind of environment, and figure out the minimum set of messaging that’s necessary to serve 3D scenes in RT to multiple clients. Minimum is good. The good thing about OpenSim is that the client protocols are plugin modules; OpenSim is not tied to any one particular client, not even LL (in theory; the reality of the code is a bit different… that’s why I say that stepping back from the LL protocol will be a challenge for OpenSim).

I feel like we’re parting ways with a long-time, dysfunctional, companion who decided to make a left turn, and I’m looking forward to what’s coming!

The news came yesterday after lunch: major layoffs at Linden Lab, as much as 30% of their employees. Lindens who had been there from early on, respected engineers, all laid off. All of those who had, at some point, been involved in the idea of virtual world interoperability — gone. Then the new vision: Second Life on a browser, accessible to the masses via well-known social networks. Wow. This is what I call a 90-degree course adjustment.

Clearly, I know nothing about the internal situation at Linden Lab. Probably their VC money has dried off, maybe their revenue is not enough to pay so many people. Who knows what’s behind a 30% ‘rightsizing’… But the new vision is an indication that this is not just about balancing the budget sheet; it’s about redefining what Second Life is. LL’s CEO wants it to be more like FarmVille than like World of Warcraft. Too many people have commented on his vision, I’m not going to do it. He’s the head of the company, he should try to make his vision come to life.

What I want to talk about here is what this 90-degree course adjustment entails for OpenSim. I confess yesterday I had that familiar feeling of having reached the point of having to stand and lead. Not me, personally. But the OpenSim project, as a whole. The torch is on us. Let me explain.

In spite of being inherently a rebellious project, OpenSim has always existed in the shadow of Second Life. The rebellious nature was, indeed, just a confirmation of that dependency; the kind of relationship teenagers have with parents. A lot of people in the OpenSim community have been assuming that, sooner or later, the large Second Life virtual world would be trading avatars and money with OpenSim-based grids. The Open Grid Protocol (OGP) prototype, first unveiled in the summer of 2008, was a teaser; a promise of what could come next. Many OpenSim core developers have been deeply involved in efforts for virtual world interoperability, first in the Architecture Working Group, and, recently, in the VWRAP working group at the IEFT. Both of these working groups were led by Linden Lab engineers… who have been laid off.

In the wake of these layoffs, the idea that Second Life will be part of a larger web of virtual worlds is today more remote than ever. There’s no one left in Linden Lab to carry the interoperability torch, at least not of the kind we were thinking. It looks more likely that Second Life will be part of the Web itself, complete with the Web’s inability to deal with portable identity, and therefore eager to serve the largest pool of users on the Web, the 400 or so million Facebook users.

It’s always hard when the driver we were relying on suddenly makes a left turn from where we thought we were going. The question for OpenSim now is this: do we really want to follow Linden Lab on that left turn? Or do we take the torch and lead?

Personally, the last thing I want to do is to be involved in one more Facebook app. That’s the kind of interoperability project that I give my undergrad students on a 3-week time period. Not only it’s technically uninspired, but it’s missing the core of what I believe interoperable virtual worlds can bring to the Web itself: true, S2S portable identity. Not just “this is me” a-la OpenID, but “this is me, and I have a lot of baggage that I want to access while I’m visiting your site.” The vision of interoperable virtual environments is as exciting to me now as it was 3 years ago.

As usual, I don’t speak for the entire OpenSim project. And it’s probably too early to internalize what this course adjustment really means for OpenSim. But one thing is for sure: if there is going to be a web of virtual worlds, a decentralized S2S system of 3D environments that can seamlessly exchange user agents securely, that web will be made of OpenSim servers entirely, for the foreseeable future. Second Life is out of the picture.

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!

We’re delighted to announce that Metaverse Ink’s OpenSearch has been selected as the default interface for search in the new viewer realXtend, whose 0.2 release was announced today. The realXtend project has been working closely with OpenSim in order to add some major features to it, both in terms of graphics and in terms of the underlying architecture of virtual worlds. The most important addition is the idea of an “avatar system”, a piece of the architecture that sees avatars as entities that can move freely between worlds — not just sims on the same grid, but sims on different grids. An avatar has an identity and an inventory, and that’s what’s being served from that component. The avatars themselves can now be created with a standard 3D modeling tool.

We believe that OpenSim, with these realXtend additions and other additions that are already in the making, is the future of interoperable virtual worlds. We are excited to be a part of it!

So, download realXtend, and try it out. Don’t forget to click the Search button and see OpenSearch natively served. Now you have a choice on the search engine you use for each search, just like what happens in modern web browsers.

Happy Searches!