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…

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.

Today, while we were doing load tests in Wright Plaza, I was also doing another kind of load test on my standalone. This one relates to server-side bots. I was able to have a 3×3 megaregion with ~2,000 prims, 200 bots and my client connected to it!

My client was quite happy. The only thing that didn’t seem to be working was the walking animation. Apart from that, I was able to walk, fly, chat and generally interact without much lag. Pushing it to 300 didn’t quite work well yet, I was stuck in 10, 10, 10 on login.

Mind you, server-side bots are a very light load on the server, much lighter than a regular client and lighter than a libomv bot. For starters, they don’t connect over the network, so there is no packet sending/receiving. Then, these particular bots I’m developing aren’t that smart yet, so they don’t request any assets from the server — their load is essentially the physics that comes with them and all the updates that are sent to regular clients as the bots move around.

I have been playing with server-side bots lately because I am involved in projects that require them for simulations. I will have to have at least 500 of these. We’re very close… I’m quite happy with the results today!

Google’s intention is great at face value. However, I can’t help but wonder what will Google do with all that content produced by thousands of people around the world. If Goggle ever monetizes Google Earth, will it give back to the creators of those buildings? Or, like what Google does on the Web, will it take the content and run its own business without paying back to content producers?