Like many of you, I read Maria’s article last December saying that Vivox was giving free voice service to small OpenSim worlds. I thought that was a nice gesture, but I confess I found it hard to believe, so I didn’t act on it. Until yesterday.

I decided to give it shot, because my projects could really use inworld voice, and I had nothing to loose just for asking. Yesterday was Sunday. To my surprise, I got a reply within 1 hour of my request. I filled out the license agreement. This morning an email was waiting for me with the precise instructions, down to the lines that I needed to add to my .ini, and a link to the blog post that Kitely wrote on how to enable voice. I just had to copy-and-paste the config, and I had voice working in 10 minutes! — 9 of which were spent figuring out which buttons to press on the viewer to enable voice all over.

I couldn’t believe it! Someone at Vivox must really like OpenSim! Wow.

D2-ers, don’t miss out on this fantastic opportunity! See Maria’s article and take it from there. No need for complicated and costly licenses. No need for horribly complicated and fail-ful Freeswitch installations. Small worlds just got as powerful as the big ones — or even more powerful, because big, commercial worlds need to pay for the service, and the small ones don’t. At least for the time being.

I usually don’t write about the future, I prefer to write about things that are already done and working. But I’m going to make an exception, because people are starting to ask about configurations of the Hypergrid that pertain to the next level; we’re almost there, but not yet. I am going to give an overview of what’s in the works right now that will result in the next big bump in the HG number: the big two-point-oh.

As usual, some context first.

The very first version of the Hypergrid, HG 1.0, was done back at the end of 2008, and continued through 2009 and 2010. That first version was just an exercise in feasibility and in interacting with the opaque, black box viewer. Could I trick the viewer to think that it was still on the same grid while in reality sending the user to a different grid? — that was the humble goal of HG 1.0. HG 1.0 was not concerned with security at all, as the main goal was to figure out how to use the viewer in ways for which it had not be designed. Once I mastered the signaling of agent teleports, it was time to take the HG to next level: more security all around.

The next version was HG 1.5. The conceptual work for it started in early 2009, although the actual coding only happened much later. This was because in order to implement the Hypergrid as a collection of additional, optional services that don’t interfere with the simplest configuration, OpenSimulator itself had to be considerably refactored. That took a long time. HG1.5 came with OpenSim 0.7 in July of 2010. It featured identity security as well as a semi-secure (or semi-insecure, depending on whether you are an optimism or a pessimist) Hypergrid inventory. It also had all the right architecture for enabling HG Instant Message and Friends. That’s where we are right now.

So let me explain what we’re working on for HG 2.0

Inventory

Hypergrid Inventory is going to be 100% secure and the Suitcase will finally be usable without external Web apps. This required some heavy hacking in order to understand how to further trick the viewer into submission (i.e. use it beyond its specs), but we did it. Here is what will happen. When a user goes out, her entire home inventory tree will be removed from the viewer and replaced with the Suitcase folder tree only. That’s the only portion of the user’s inventory that will be exposed to the outside and to the user while the user is hypergriding. That way, the user’s home inventory will be out of reach and completely protected. Once the user returns to the home grid, the Suitcase wannabe-root folder is replaced by the user’s real inventory tree again.

Depending on configuration, the Suitcase folder may or may not be available to the user when she is in her home grid. When it is available, it will be a regular folder under “My Inventory”; the user can then move stuff from/to the Suitcase to/from other folders using the viewer.  But some grids may not want their users to bring in stuff from the outside, they want to continue to segregate content, so availability of the Suitcase folder in the home grid will be configurable.

Appearance

The appearance that a traveling user has may or may not be the same as the appearance that she had when she left the home grid. Again, this will be configurable. But the idea here is that  some grids don’t want to allow the export of appearance assets at all, so they may provide generic appearances to their traveling users, and dress them with their appearances when they come back. Other grids may not care about this, and appearance will be preserved.

User Access Control

There will be a means to specify several policies of access control: who can go out and where, who can come in and from where. These policies are based on several pieces of information about the users themselves and about their grids of origin.

So for example, it will be possible to specify that only users of a certain level can Hypergrid out, while others under that level can’t (a requirement often heard in educational settings). It will also be possible to specify a limited set of grids that the users can visit; or a set of grids that the users cannot visit.

On the receiving end, it will be possible to specify only a limited set of grids whose users are allowed in; or a set of grids whose users are not allowed in; or no foreigners allowed in at all.

Assets Access Control

There will be a means to specify whether the grid allows asset exports to other grids, and which grids, as a whole. HG 2.0 will not support the specification of fine-grained asset exports, i.e. I can’t say that this particular set of assets can go out, while that other can’t. This will require a means for people to be able to express that, and we don’t have that means yet.

≈

What this amounts to is that the Hypergrid will be able to support different policies that better reflect different levels of comfort that people have regarding opening up their worlds. Grids that deal with protected content will be able to continue to protect that content while allowing their users to visit other grids, and even collect items there, and allowing foreign users to come in and mingle — without any asset ever being exported or imported from/into their main storage. Grids that deal with kids will be able to block them from hypergriding while allowing certain privileged staff to go out and get content and knowledge from other grids. Secretive grids will be able to prevent foreign visitors while allowing their users to go out. Grids can have only one or two regions available to foreigners, while the rest is off-limits. Communities can make up small networks of worlds that allow Hypergrid exchanges only among themselves. Etc.

I hope this clarifies where we’re going with the Hypergrid!

I know that the first question that everyone will ask is: when? My guess: sometime this summer, hopefully early.

Hi everyone! I’m happy to announce the personal Hypergrid Teleporter! Its goal is to make your Hypergrid travels a bit easier and more enjoyable. Get it here as iar.

Let me first give a bit of context. Hypergrid teleports have been possible for a long time. Using plain OpenSim installations, traveling on the Hypergrid can be done in a couple of ways: (1) via the Map by typing in the HG address in the search box; or (2) by establishing the hypergrid link in the OpenSim console with the “link-region” command. While this works well, it’s a bit inconvenient. The Map process gets very confusing if you are using Viewers 2-3, because these latest viewers assume that there is only one map. The link-region command assumes that you have access to the server console, which obviously not everyone has.

In order to make things easier, we have seen systems like the Hypergates emerge. The Hypergates establish a centralized service where people can register their worlds, and others can travel to them using an inworld teleporter — a scripted object that uses osTeleportAgent at its core. The inworld object is really neat; it’s inspired in the Scifi TV series Stargate SG-1. The object  is relatively powerful and complex. When you click it, you are presented with a series of options about where to go. Once you choose your destination, you step in and, with luck, you are teleported there. I say “with luck” because two of the major characteristics of the Hypergrid as it exists today are (1) the fact that many worlds are turned off as much as they are turned on, especially those hosted in people’s homes; and (2) the annoying 4096 travel distance limit. So, for a number of reasons, the teleport may not succeed.

I like the idea of inworld teleporters like the Hypergates. They make HG travelling a lot more fun than using the map. But the Hypergates is a bit too complicated for me. I wanted to have a much simpler object that just teleports me to a specific world that I already know and like. After all, osTeleportAgent is super easy to use.

Hence, the Metaverse Ink Hypergate Teleporter! It’s also Scifi-inspired, in this case the Star Trek teleporter. Let me explain how it works.

First of all, the Metaverse Ink Hypergrid Teleporter uses osTeleportAgent, an OS function that requires special permissions. The owner of the world needs to enable it. In the Diva distro, this function is enabled by default, but restricted to the estate owner and the land owner. So only those users can run this teleporter.

When you rez the teleporter, it comes with a default destination, the UCI Grid. You can try it as is. So how do you actually teleport? Very simply by walking in and stepping on the platform, just like the picture at the very top of this article illustrates. There is a 2 sec delay just for the fun of being showered with a particle beam, and then the teleport starts. The teleport may still fail, for a number of reasons. One of them is the 4,096 limit. Other reasons may be the cause; for example, the destination may not be accepting HG agents, or it may be misconfigured, etc. If the teleport fails for some reason, you will be told so.

You can change the destination by editing the object and setting a new destination in the Description field (see picture of the left). For example, if you want to set it to OSGrid, change the Description field to, for example,
http://hg.osgrid.org jump4000 (that’s accessible to the lower grids, jump8000 for the upper ones).
Close the editing window.

In order to get immediate feedback on whether that destination is up or down, “touch” the platform of the teleporter (the bottom part). This will perform a status check. If the destination is up and running, you will be told so, and the yellow particle beam will continue to flow; if the destination is off, you will also be told so within 30 seconds, and the particle beam will stop.

The teleporter performs an automatic status check on the destination every hour. If it can’t reach it, it turns itself off; if it can reach it, it turns itself on. In either case, it checks it again one hour later. So you can just let it be, and be assured that the particle beam  represents the status of the destination within 1 hour error margin. For example, on the left you can see 4 teleporters, each one set to a specific destination. The left-most one is offline at the moment I took the picture.

You can always check again any time you want by “touching” the platform.

But there’s more!

If you touch the top part of the teleporter, the search icon, it launches the Web browser on the Metaverse Ink Search page. Depending on how you have that configured, it may launch it embedded in the Viewer or external to it. What i’m about to explain works in both cases, although I personally prefer the embedded browser.

That first page has a few Hypergrid addresses that I personally recommend. You can go there simply by clicking on the Web links! That’s right — HG teleports can be triggered by Web links too! This works particularly well for OpenSim 0.7.3.1 and later.

But you can also search for other worlds using the search box on the top left of the page. I confess that I have been neglecting the Metaverse Ink Search engine, because I have been busy making the Hypergrid actually work. MI Search has issues on worlds running Opensim versions before 0.7.3.1, especially grids. But I am restarting to work on it. So as worlds upgrade to Opensim 0.7.3.1, MI Search will work  much better!

There are many improvements in OpenSim, most notably the new LSL NPC stuff — this allows you to create and manipulate Non-Player Characters (bots) directly from scripts. Really cool!

Hypergrid-wise, the most noteworthy development is the support for Friends across the Hypergrid. As explained in a previous post, I have created a world-to-world social network platform in OpenSim! Diaspora, anyone? Well, I get to actually do it and deploy it in  your worlds

Have fun!

P.S. I also made a new release for Wifi that works with Robust 0.7.2. Enjoy!

As the title says.

Over the weekend, I added the machinery for the new V2 map to work with vanilla OpenSim. If you want to try it out, watch out for the several changes in configuration files, especially those in .ini.example’s — make a diff to see what changed.

Note that viewer 2 is even more radical than viewer 1 when it comes to regions placed above 2,048. Most likely, the map won’t work there at all. (I haven’t tried it)

Also note that, for the time being, V2 map will get considerably confused on HG teleports. The first step was to make the map work. The next step is fixing the map for the Hypergrid. There’s a brute-force way of doing it, and there’s an elegant way of doing it. The elegant way of doing it requires collaboration with viewer developers. Let’s see what we can do together…

Enjoy!

UPDATE 6/10/2011: It turns out that the map breakage starts at 2,048, not 4,096.

Let me start by the observable consequences of this “bug.” (btw, I’m quoting this word because, as you will see, I came to realize that this is not a bug) There are at least two observable consequences:

1. The first observable consequence was first reported here 3 years ago in the context of OGP work between SL and OpenSim. In short: if you try to teleport between regions that are more than 4,096 cells apart in either X or Y, the teleport succeeds, but the viewer is blanked out. No crashes, but nothing rezzes. This issue, also known as the “long jump” issue, doesn’t just affect  interoperability mechanisms such as OGP and the Hypergrid; it affects teleports within the same grid too. As long as the regions are more than 4,096 cells apart, the viewer blanks out.
2. The second observable issue is a lot more subtle and more difficult to notice, but it’s there for those who care to notice. Here is the map of OSGrid around Wright Plaza: Do you notice something strange? No? Look again. After waiting several minutes, we get only the -4/+4 map tiles around Wright Plaza. There’s regions beyond that, in fact the whole space around Wright Plaza is filled with regions; but the map doesn’t show them… unless we explicitly click on one of those water tiles — that gets us another -4/+4 around that tile that we clicked. (depending on which version the sim you’re on is running, this may be +/-8 instead of +/-4).
   This happens because OSGrid is placed around 10,000-10,000 in grid coordinates. For grids whose coordinates are below 4,096 2,048 the map is always complete as far as there are regions in cells.

Very likely there are other subtle consequences of these numbers 4,096 and 2,048 which I haven’t come across yet.

Now that I described the observable consequences, you may want to know why this happens. I don’t know the answer to that question, I have just a few clues and hypotheses. Here’s what I know.

First of all, this is not an OpenSim issue, it’s a Second Life issue. It happens to affect OpenSim only because we use the Second Life viewers while deviating from how Linden Lab uses their servers. In Second Life, all the regions are placed between 0 and 4,096 in both dimensions. In OpenSim, for unawareness of any limitations, grid operators started placing their grids in arbitrary coordinates above 4,096. The main culprit was OSGrid, and then other grids followed.

I wish I knew the exact technical explanation for this issue, but I don’t know. It seems to be related to how the viewer represents region coordinates, but that doesn’t quite add up. Here’s the Math. The viewer represents grid coordinates using 64-bit unsigned integers which are, in essence, two 32-bit unsigned integers concatenated together, one for X and one for Y. Each number represents a point on the map in meters. So for example, the SW-most point of cell 1,000-1,000 is point 256,000-256,000. In principle, we ought to have 32 bits to represent these dimensions, which would give us 2^24 cells in each dimension (that’s 2^32 divided by 2^8 (=256), the size of regions in meters). Instead, we seem to be hitting the ceiling at 2^12 cells (4,096). There’s a tempting relation here — 12 is half of 24. Where that halving comes from… I don’t know. Maybe some optimization of Second Life. Perhaps some viewer developer could shed some light here having seen the viewer code?

Whatever the issue is, it seems to pervade the viewer code base in profound ways. Even though this issue has been know for 3 years, no viewer has it fixed. At least a couple of viewer developers have attempted fixing it; one even submitted a patch to Linden Lab (see the original bug report which still contains that patch). Unfortunately, I heard that that patch proved to break other things. In talking with Imprudence devs briefly, they mentioned that they, too, attempted to fix the issue in the viewer and came to the conclusion that the changes were so many that it wasn’t worth the trouble.

I made peace with the issue a few weeks ago. My peace with it started when I noticed, in horror, the second observable effect — the missing map tiles. It turns out that OpenSim has a horrible hack to cope with this behavior, that’s why we see +/-4 regions around, otherwise we would see only the current region and nothing else. It’s a horrible hack, and it’s there just because OSGrid is placed above 4,096-4,096. If we didn’t have the hack there, OSGrid would have no map! This horror was the beginning of my coming to terms with what’s going on.

The issue is not a bug at all. It’s a fundamental design decision of Second Life. Second Life assumes that a grid will never be larger than 4,096×4,096 regions. That design decision is reflected pervasively in the viewer code to the point that very smart developers don’t think it’s worth the trouble changing it. If you think about it, this is not an unreasonable assumption. That’s 16,777,216 regions! Would anyone in their right mind ever operate a virtual world with 16 million SL-like regions?! Very unlikely.

The argument so far for calling it a “bug” seems to have been this: “well, if this is the basis for the 3D web, then clearly there will be more than 16 million regions, just like there are more than 16 million web servers.” True. But not on the same map! Not under the same authority! Seeing the map as one single shared space between all virtual worlds is just… wrong! The map is a grid resource; different virtual worlds should have their own maps. They should be able to have regions on the same coordinates — region placement should not require global coordination. Sure, there are interesting things that one can do with shared maps, but in my view of things, the starting point for interoperability is 1 grid = 1 map. As opposed to all grids = 1 map.

So, having finally realized that this is not a bug, but a not-unreasonable design decision of Second Life, I came to peace with it. It won’t be “fixed” because that would require rewriting the viewers to the point of being unmergeable with the official SL viewer. It would be nice if Linden Lab hadn’t made this assumption. But they did, and we have to live with it.

It turns that “living with it” is not a big deal at all. It’s as simple as placing all the regions between 0-0 and 4,096-4,096 2,048-2,048, because that’s what the viewers expect. What could possibly make this an undesirable situation?

Perhaps OSGrid will have a hard time coordinating this change, precisely because it uses a global resource (the map) shared among hundreds of people. (This comes to prove what a bad idea that is…) I hope the OSGrid administrators will also come to terms on this, and force the coordinates change, so that we can finally have an open Metaverse free of hicups.

[UPDATED 6/2/2011] Added pictures!

Here’s a base case scenario. You run your own OpenSimulator VW, and you visit OSGrid with an Hypergrid teleport. Once you get to OSGrid, you meet someone there — maybe from OSGrid, maybe from some other VW –, and you want to add that person to your list of friends. People in your friends list acquire certain rights over your information shadow, and vice-versa: they may be notified when you login/logout (and vice-versa), they may change your objects (and vice-versa), they may see you on the map (and vice-versa), etc. An entry on your list of friends is a persistent reference to a user, so you can easily IM them, see their profile, etc.

Up to now, it wasn’t possible to hold references to users in other services. With these changes, that has become possible. An HG friendship establishes 2 pairs of data, each stored in each user’s user services. That data is “signed” with a random number known only to the 2 services and the simulator where the friendship was established, so that, even if the user services (hg friends, to be precise) are exposed to the Internet, no one but the holders of the signature can manipulate the friendship data. Here lies warning #1: don’t make friendships in worlds that you don’t trust — instead, ask the person to come to your world, or vice-versa, and establish the friendship there.

Independent of that, HG friendships established while you are Hypergriding require an additional confirmation step once you return to your world. Here’s a typical interaction: you go elsewhere, you ask someone to be your friend (or vice-versa), the viewer will tell you that the friendship was established. When this is done within your world,  the interaction ends there. With HG friendships, once you return to your world, or login the next time, you will be once again prompted for confirmation of the friendship. This is so that your friends list won’t get spammed with bogus entries sent by malicious components. Once you confirm that second time in your home world, the friendship is finally established.

Your HG friends can, by default, see your logins and logouts of the virtual world — to some extent, and this is where things are still work in progress. So far, they will be notified if they are in their own worlds. However, they will not be notified if they are elsewhere — not yet, at least.

This starts to show the really interesting challenges of these social functions done in a decentralized architecture: you can “move,” that is, your client doesn’t have a communication channel with one single server over your entire session; instead, your client “moves” from server to server. Keeping track of where people are (that is, which server their clients are talking to) is a major challenge! — especially without central servers. But I’ll come to this further down when I explain IM over the Hypergrid.

Another interesting aspect of the design of friends over the HG is the rights to edit each others’ objects. Within one world, once you give someone the right to edit your objects, that right holds for all regions of that world indiscriminately. With the Hypergrid, we have the option to differentiate between the worlds, and give rights to edit objects per world. In other words, if we are friends and I build things in your world, I can give you the right to change my objects in your world; but I may very well not give you the right to change my objects in my world. (or vice-versa). Right changes affect only the world where the action takes place: if I change rights in my world, those new rights will be stored in my world only, they will not be disseminated. When you HG-TP to a new world, you will be notified of the rights that you currently have over your friends’ objects there, if different from those in your home world.

This is a subtle semantic change. I like the more expressive capabilities, but I understand that people coming from walled-garden worlds may be somewhat confused by these extra options. We’ll see how this design decision fares as we go along.

One thing that is still work in progress: rights to change objects in 3rd-party worlds.

Now… Instant message.

The base case is very simple: you are in your world, your friend is in her world; you IM her, she IMs you back. Works. Simple. It works because the reference to your friend includes the URL of her world, so your world can forward the IM appropriately. And vice-versa.

Scenario #2: you jump to your friend’s world, you IM her and she IMs you back. No problem, that’s a local IM. Works. Simple.

Scenario #3: you go back to your world. Your friend IMs you. Not so simple! Your friend’s world needs to detect that you aren’t in her world anymore and needs to find out where you are. Your friend’s world fails once, but has a reference to you, including your world’s URL, so that’s what it uses to forward the IM.

Scenario #4: you HG-TP to a 3rd world. Your friend IMs you. More challenging! Now your world needs to find out where you are. Your User Agent service knows that, and forwards the IM to the world where you are.

Scenario #5: in that 3rd world, you IM your friend back. This is really challenging! — because that world knows absolutely nothing about your friend. No worries, it still works in this case. It works like this: that 3rd world knows about you, so it asks your world if it knows about the user you are trying to IM. Basically, all that world needs is a URL to deliver the IM. Prompted with that information request, your world first looks if the user is a co-resident of yours; if it is, it sends the URL of your world; if it’s not, as is the case in this scenario, your world checks if the requested user is a foreign friend of yours, which is the case here. Having found it, it sends the URL of your friend’s world to the 3rd world, so that the IM can finally be delivered.

Scenario #6: in that 3rd world you meet someone, and you start IM-ing with that person, who is not in your friend’s list. Then you go back to your world and you send an IM to that person in the window that is still open. Oops! — this won’t work! — at least for the time being. The reason it won’t work is because your world knows absolutely nothing about that person: it’s not a co-resident, it’s not visiting your world and it’s not in your friend’s list. Your world has no means to find the URL of that person’s world to send the IM to. Work in progress…

Note that throughout these IM interactions your location in the Hypergrid is known only to your user services; it is not disclosed to the worlds with whom you are IM-ing. Those other worlds simply forward the IMs to your world, and it’s your world’s responsibility to forward them to wherever you are. This is an important privacy-preserving design decision.

As I said, HG friends and IM is still work in progress. Use with caution, and be ready to go down to your DB and delete records in the friend’s table if things go awry. If all testing goes well, it will be in 0.7.2.

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)

It’s no secret that I have been fairly impressed with Unity3D. I find it extremely liberating in comparison to Second Life’s (and any other MMO) pre-packaged notion of what online 3D environments should be. I had to give a talk yesterday, so I used that talk as an excuse to taking my knowledge of Unity3D to the next level. I decided to make my presentation in Unity3D, and have the audience be part of the presentation at some point — similar to what we see in SL/OpenSim, but with the experience on the Web browser and under my complete control. Go here to see the result. Let me explain what you see there.

The whole thing starts with what looks like a vanilla 2D, yet-another-PPT-on-the-web, kind of feel. I added a few buttons to control the slide show (I love the GUI programming options!). Go ahead, “load” the presentation, and play with the buttons on the right. Also don’t miss left-click+dragging the mouse for a cool fire trail effect.

On the left there are two additional buttons: the “World” button on top, and the “Roam” button on the bottom. The “World” button takes you to another scene that feels like a traditional virtual world — landscape, trees, ocean, fire, ambient sounds, etc. You can move around with the arrow keys, page up/down, mouse scroll, and pan using left-click+drag. If you wait long enough (about 5 minutes) you’ll actually see the weather changing into fog, and then back to sunny. There’s also a few Orbs floating and producing sounds; you can click them to get information about some of my papers (ok, lame, but it was the first thing that came to mind to exercise a bunch of things at the same time: OnMouseDown action, local resources, and moving labels

Note that the World is not synchronized with anyone else who visits, so you won’t see any avatars in there. That world is a scratchpad for me to experiment with the single-user-to-system interaction capabilities in Unity3D. When you’re in the world, you need to find your way back to the presentation! (hint: find the object that’s clearly out of context) So go ahead and find your way back.

The “Roam” button reveals the true nature of the 2D presentation. It’s actually a 3D scene. It just so happens that, by default, I have a fixed camera, and no movement control. Only when you “roam” can you perceive the 3D space. Yes, it’s MY scene, and I can control the entire user interaction however I want! YEY!

Once you’re in roam mode, you can move around in the same way as in the World. But the other little thing I did is that this roam mode enables the visualization of visitor presence. Each visitor in roam mode is represented as a yellow ball head. There are no names or identifiable labels; just yellow ball heads, possibly moving around. Yes, it’s avatars controlled by other people, and you’re seeing them! But that’s pretty much the only thing you can do — see them. There’s no chat (yet). Some yellow ball heads you see may be corpses of past visitors who didn’t “Fix” their view before they left — I don’t have automatic garbage collection yet.

The presentation itself has a few slides explaining what I did in order to synchronize presence and location, if you’re interested in knowing that. It’s a hack — a couple of 20-line python scripts called under timers on the client side. Ugly. It’s just a proof-of-concept for me to start looking into the networking capabilities of Unity3D. I feel like a kid in yet another candy store…!

How is this different from building in SL/OpenSim? Well, everything you experience was scripted by me, down to the camera and movement control, the fire trail effect and the GUI elements. In the World, I used a skybox developed by someone else that adds moving clouds. For the most part, I was able to figure everything out with the right keywords on Google. Not surprisingly, the part that I had most trouble with was… creating the yellow ball head itself I still don’t know enough about 3D modeling and texturing, so something as simple as this yellow ball head doesn’t come easy to me. I used Wings3D, and after a few fails, I finally was able to create the UV map for the smiley face that I then textured in GIMP. Complicated stuff!

So, yes, the options are almost endless, but that means that whoever builds these scenes needs to learn how to exercise those options. On my part, I very much enjoyed learning all of this. Unity3D is doing a lot of things “right”. Indeed, authoring tools will be the key to the massification of 3D; their conceptual models and scripting APIs need to be simple enough for lots of people to be able to use them (like SL/OpenSim), but still powerful enough to express everything one might want to express in 3D. I have my fingers crossed that we will start seeing open source projects doing the things that Unity3D does, especially making the scene creation be powerful and easy.

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…