A Tour Through Unity3D for SL/OpenSim Aficionados


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.


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.


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.


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.


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…


10 replies on “A Tour Through Unity3D for SL/OpenSim Aficionados”

  1. Neil Canham says:

    Great write up – it’s good to see more OpenSim experts casting their eye over Unity. I’ve also dabbled a bit in Unity and came to similar conclusions – fantastic freedom and depth, steeper learning curve than SL but not as steep as other ways of assembling complete games/environments from industry standard components. In terms of the networking / MMO-ness, a lot of people start with the networked island demo that smartfox built on top of the standard Unity Island demo. However, one way to get up and running with a full networked virtual environment on top of Unity is to pay for Reaction Grid’s ‘Jibe‘ VW toolkit

  2. Pathfinder says:

    Great summary, Diva. Thank you for sharing your experiences like this.

    You said: “…if you want to create a virtual world with Unity3D, you need a lot of extra engineering work.”

    Yep. And that’s precisely what ReactionGrid’s Jibe platform does. Jibe is a framework that lets you build scenes in Unity and then make them part of a multiuser virtual world. You can visit my own multiuser Jibe world here on the web.

    When you were animating your cars, did you use the free iTween tool to move them around? I’ve been playing around with iTween and find it very handy.

    And if you’re interested in talking with other people exploring how to create multiuser worlds based on Unity, we’ve got a pretty active Unity3d-Jibe Google Group with lots of good discussions going on.

  3. Chris says:

    Great article Diva, thanks. I too have recently started creating content with Unity. Your observations chime with mine in terms of the pros and cons. For my own project, however, Unity has allowed me to do very easily some things which were previously a HUGE headache in Second Life; specifically anything involving audio longer than 10 seconds…

    I’ve looked at the Jibe system the other comments mention and it looks like a good way to ease the multi-user side of things. I’m still building and testing a single user scene in Unity. but I intend to bring it all in to Jibe once it’s ready.

  4. Per Eriksson says:

    Thank you for sharing your thoughts.

    I get a similar feeling when I look at Unity 3D. A step closer to what the “professionals” use, or the look I am used to see in their finished work. To me Opensim is my sketch book a place where with no fuzz I can sketch an idea in a few minutes. Primitive maybe? It works for me. To get a really polished look in Opensim requires a bit more work and in the end will still look different to a “professionally” modelled scene. (To me Opensim/SL looks more hand crafted like shaping a piece of wood by hand instead of using a router or a lathe, (a look that most of the time appeals to me.) I like how Opensim and Unity 3D work together in the browser al la Tipodean. Laughing at your Blender comment ( I know that feeling well) I have tried Blender many a time, after having seen some stunning work made in Blender. I guess I have to try harder :-)

  5. Toni Alatalo says:

    Hi Diva – great to see that you took that journey, and thanks for sharing! I think it’s much needed that developers of different platforms know more about others too — have been learning Sirikata, OpenWonderland and MV3D myself lately, besides using Opensimulator and realXtend for work. Haven’t had a chance to really use Unity yet, so this was quite informative.

    Perhaps you will have the chance to take a look at the new reX stuff at some point too. The new Naail & Tundra SDK are in some ways similar to Unity — reX is sometimes described as an open source alternative to Unity 3d. In the sense that both are now generic engines with an extensible scene model, and where application code determines the user experience, instead of some hardcoded viewer & protocol feats like with slviewer. There’s a quite short & clear article that describes this, also discusses the plan of refactoring Opensimulator to have similar extensible scene model: https://github.com/realXtend/doc/raw/master/arch_article/simple.pdf

    One difference perhaps is that reX, like SL & Opensim, is inherently networked: by default, every object (scene entity) that you create is shared and synchronized among all the participants. But there is also the option to create the entity LocalOnly, both on client and server side, which I’ve recently used exactly for a similar case than your traffic simulation: in our upcoming demo there is a fish game (again!), where you swim around as a little anchovy eating plankton. The planktons clouds are composed of several particle systems, and to ease network traffic, the individual particle systems (which finally include the particles) only exist on the client side. But the bigger cloud entities are shared, so all clients see them in the same area in the water, just not in exact same positions. This should work well enough for the multiplayer game. Also physics can be done on either side, or both.

    A company that has been developing reX and doing projects with it recently made one project with Unity3d too, but is now making another using reX while developing core features there too — they also came back with nice ideas for improvements :)

    I think Unity and many platforms are fun and useful to have, and believe that there is room for both closed, proprietary packages like Unity3d and for open source such as Opensimulator and realXtend.

    For the scene editing side, reX currently differs from Unity so that we mostly bring in ready made scenes .. use e.g. Blender or Max as the level editor. And there is a project to make this integration tight, having custom VW authoring UI in Blender, with a real-time connection to the server (already works agains opensim+modrex!), https://sim.lorea.org/pg/groups/5/b2rex/ . Naali/Tundra does have in-world editing, asset views, property editor etc. too .. but quite rudimentary still.

    I think it’s a very interesting question: what creation tools should be an in-world experience, and what are fine as offline? Even SL users use separate apps to draw textures :) I’m currently working on a simple waypoint graph / walk path editor myself — originally had the idea to author the paths in Blender and export, but after I made the first test walk path (for a NPC deer) with in-world tools (just placing invisible objects as walk targets), and has so much fun tweaking the path nodes live while the deer was walking, decided to instead do something that can integrate to the platform directly. Decided to do it, surprise surprise: browser based! Because we use js for game logic, so can use the same underlying js graph lib, and as the viewer embeds a browser (like slviewer does too), can use it ‘in-world’ too. Put a little proof of concept test up at http://www.realxtend.org/world/lvm/pathedit/editor.html and will continue work on it in https://github.com/antont/pathedit next week. As also Unity3d supports js, perhaps unity projects could use the same waypoint graph editor even 😮

    I hope we’ll get cross plat interop going on in such high level things — the custom cameras that you mention are my prime candidate for that.

    Thanks again for the interesting post, let’s see where we end up with all these developments going on :)

  6. Diva Canto says:

    @Toni, thanks for the comments. You definitely need to try out Unity3D, it’s worth the time investment. It’s a different paradigm — and one that I think will be the dominant one in the future, because it addresses the main need without imposing strong constraints. People need to build interactive 3D environments, and that includes the “viewer” experience. Rather than hard-coding one particular way of viewing those environments, Unity3D allows us to program the entire user interaction. They give us enough options to develop everything — GUIs, cameras, levels, etc. They separate building from experiencing. The builders build the entire user experience. Then, with the click of a button, we can generate viewer components for all sorts of different platforms — including, I suspect, WebGL when it becomes good enough. I can’t stress enough how relevant Unity3D is for the community interested in interactive 3D, networked or not.

  7. Toni Alatalo says:

    I perhaps failed to say this clearly — realXtend Naali / Tundra allows the same, the entire UI is now loaded from the server when logging in .. so different servers / scenes / regions / applications can have a totally different experience. For example, whether there are avatars or not, what does the mouse control, how the cameras behave etc.

    That works also againts Opensimulator, with the modrex extension that allows to put extra data to the scene (for example client side javascript script references, which implement the UI for that app).

    So AFAIK the paradigm in reX and Unity is the same. Still certainly is good for me too to actually test it.

  8. Very intersante your post, because it shows how an experienced developer of OpenSim Unity.
    In my case, I am by testing OpenSim, realXtend, Taiga and Tundra recently, from their first days, and last year I’m studying Unity.
    A great choice Unity is the land or directly import objects created with external programs, which, from the point of view of large projects, it is very interesting. Thus, using for example because Vue, Terragen or digital elevation data for terrain, and Sketchup (converting format. obj to FBX), is a great option.
    If a version of opensim, allowed to handle scenes of Unity, I think it would be a giant step forward.
    Personally, I see Tundra option difficult to understand and manage, for this reason our group has moved to Unity to handle scenes.

  9. “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”

    Sorry, but it’s not true. You can create a multiplayer environment only using Unity (even the free version).
    You can learn how to do it reading my tutorials at:

    Como você fala portugues ten tutoriais em português e inglês.
    Um abraço,

Comments are closed.