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…

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.

Forget the “profile web page” hack we tried… that’s sooooo last month. Now we can truly integrate directly with the built-in search. Here’s the scoop:

Linden Labs included a new search feature in the Windlight release candidate client of Second Life. At first it looked like another closed system, but then DrenBoy Opus discovered that the search page is configurable via an obscure setting. Since Diva Canto and I have been running our SLBrowser search engine for the last 6 months, we’ve been looking for better ways to hook into SL. We turned DrenBoy’s discovery into something useful by creating Open Search for Seocnd Life to augment the Linden Search with some search alternatives. The Open Search page gives you quick access to multiple search pages, including SLBrowser, Linden Labs, OnRez, SLExchange, and Google. The line-up is subject to change, but this is our current offering. You get all the functionality of Linden Labs new search, plus these other great search engines. We believe that search should be open, and that the best way to improve things is for competition… where the users choose the best solution, rather than being forced to go with once choice. If you have the new Release Candidate (see the link above) you can easily configure it for Open Search. Thanks to Bettina Tizzy and DrenBoy Opus for letting us know about this possibility.