Sansar to use Unity3D?

SL Press has an article up about the rumor that Project Sansar will be built using the Unity3D game engine. See: Project Sansar to run on Unity3d. The title makes it sound like a fact. While they give good reasons for saying it is Unity3D, it is still a ways from a conclusive confirmation. It also is a bit misleading to my way of thinking.

PS: 9:50 AM PST: Note Pete Linden’s comment at the end.


Unity3D – June 28, 2010

The latest information I can find where Ebbe Altberg says anything about voxels is to say they are experimenting with them. Early on there was more talk about using voxels. Voxels were a big thing for High Fidelity too. But, recently we haven’t heard much about voxels from either project. 

TerraVol: Voxel Terrain Engine – is a Unity3D product. This type of engine is for generating terrain from parameters. Like; how high do you want your mountains, depth of the sea, rolling terrain or cliffs? In SL we model our terrain, each vertex. The guess is TerraVol would be used to generate terrain in Project Sansar. I would expect this to work well in forests and natural terrain. I’m not sure it would be that great in a cityscape. So, we likely will have alternate ways to build terrain. No one from Linden Lab is saying just yet.

Using Unity3D and the TerraVol engine is also a big step toward Android compatibility. So, while not solidly confirmed, I suggest you NOT bet against it.

Unity also provides a ‘browser plugin’. So, it would provide a built in compatibility for those having only a web browser installed. If that leaves you wondering about Google and Firefox’s 2013 move and 2014 action to eliminate plug-ins from their browsers, see: Google/Firefox Dropping Plugins (2013).

Made With GAIA/Unity 5

Made With GAIA/Unity 5 – 2016


I haven’t done any Unity development. I have done a bit of development using the Unreal engine. I chose Unreal because the project I helped with was already being built in Unreal. When I was looking at the engines Unreal had their free to use if you did free to play. So, I leaned that direction because of cost not any great technical advantage.

As far as I know they are similar. In most cases they deal with pre-made, optimized content that is downloaded as part of the initial game install. The concept of a massive collection (as in petabytes) of user made content downloaded on the fly is not part of the package. But, it has been a couple of years since I played with either.

Since casual and one time use of ‘experiences’ is a primary goal of Project Sansar, a huge initial download before being able to enter the experience isn’t going to work.

Remember Blue Mars? There was a screen where you picked your ‘experience’ or world, waited for it to download and then entered. People don’t have that kind of patience with marketing information. Google, Amazon, and others marketing research is showing that web pages, or in generalities ‘the information’, has to arrive as fast as possible. For every 100ms of delay 1% of sales is lost. (Ref) No commercial enterprise is going to be interested in developing a promotion that takes minutes to load.

There are other limits that Unreal and Unity have which the Lab is going to have to work around. So, my thinking is that Unity3D and TerraVol may be parts of the Sansar system. But, to say Sansar will be run on Unity, or any other known game engine, is an incomplete statement.

If Project Sansar is not adding value and abilities beyond what Unity can provide, then what would anyone need the Lab for?

Those that use Unity generally provide a game and its content, not a platform. We know the Lab, from their statements and actions, is not interested in providing content in Sansar any more than they are/were in Second Life.

Below are examples of what people are doing with Unity’s terrain engine and voxel editing.

Below we are shown how real world terrain is brought into Unity3D. The last 5 minutes I found more interesting.

PS: Please read Pete Linden’s comment below.

The Unity terrain editing we see above may be a clue to the editing in Sansar… or not.


17 thoughts on “Sansar to use Unity3D?

  1. No, Project Sansar will not be using Unity (nor Unreal). As noted in this article (from a journalist who actually interviewed Ebbe):,30054.html – we are developing our own engine.

  2. I don’t think a Unity based Project Sansar would mean we all having to learn unity. I think it’s simply using the Unity tools and plugins to create a platform to easily make VR experiences. In a way i see that asa good thing as it means future technologies will be easier to add to Sansar thanks to Unitys big developer community.

    Thats if the unity rumour is true 🙂

      • yeah, and you believe them…ppppffft
        Anyone who works with Unity can CLEARLY see that they are using the same shaders’ code AND the use of C#, which ONLY Unity uses among all game engines, is one more evidence of it. They bought the source code

  3. I see that a post I made in a public thread on Sansar was quoted in the SL Press’ article. There was some confusion about that question. In a previous question I did in the thread to Ebbe I asked if LL planned to adopt Allegoritmic’s product, Substance. Ebbe replied they did, but what he actually meant was that they planned to use the material system used in Blocksworld (?) called with the same \substance\ name. Before the misunderstanding was clarified, I took Ebbe’s answer as a hint that LL planned to use Unity. In a later post Ebbe clarified that LL was developing its own engine.

  4. If Ebbe Altberg is looking at using code from \Terravol\ it will have unity in it. It’s a unity product as is the list of other unity tools they are looking at.

  5. I am glad Pete Linden commented. I am very likely to provide with massive content once again, this time for the Sansar platform and I am expecting an engine made by LL.
    I am dealing with truly humongous files on maya right now and being told that I am doing this for nothing more than Unity would have been bad news for me.

  6. Right when I read this line. \– we are developing our own engine.\ I cringed, with all the pains and a tribulation perception of another project going through another set of dubious development practice.

    People’s expectation are high right now. People tends to believe after years of bad experience will be reputed through to a better success after learning the mistakes and setbacks. Being told our inventory will not transfer over to Sansar will render their expectation blindly futher into thinking it will be worthwhile. Unfortunately, people don’t understand how deeply complicated software development are. Inventing a new world by starting from scratch is no small fest… in a world that already existed. No wonder why they needed top SL creators to fill them.

    My expectation is far too low right now, but I do hope Lindens will able to break my grim expectation at some point.

    Not for a moment I believed any of that rumors were true, but… honestly, as the more I thought about it. Seem like it was a good (and missed) opportunity for Linden Lab.

    Reduced development time, less bugs, wider platforms reach, vastly PC performance coverage from low ends to high ends, and both render support flexibility (DX and OpenGL). Unity is already aware of upcoming DX12/Vulkan/Metal graphic and the new multiple-cores computing era coming up this year.

    Those are something I don’t think Linden Lab can be prepared for.

    • Multiple cores are used by the operating system (OS). Software/apps opens threads and the OS figures out which core to run them on and switches cores between threads. The Lab has been moving more and more tasks into threads and figuring out how to avoid thread blocking. So, I’m not sure why you think they are not prepared.

      Multicore CPU’s and GPU’s have been around for years. But, you write as if it is a new thing….

      • Sorry, my comment about the multiple cores was poorly explained or just poorly choice of words.

        Multiple cores means that the CPU can performs more than one thing at a time. We know this isn’t new… But not all problems or calculations can be constructed to perform an instruction that can be solved or processed across cores. Regardless of the threads and assignments by the OS, their software has to be written to use multiple cores. It has to figure out how to best divide up the work that it’s doing because only that software know if what it’s doing even can be broken up between more than one core. Currently, the viewers does try to make best use of all the cores. Which is why I didn’t really try to weight my point on it.

        When building new engine from scratch with more added features, Linden Lab still has to divide those instructions in a better form of management without bottle-necking between CPU, RAM and the GPU. Assuming that the new engine will make use of the full RAM, in 64bit, instructions will be much heavier for the CPU.

        • You still don’t seem to understand. It is the operating system that divides tasks among CPU’s. The Linden made software is constantly being revised to break the SL system into individual threads which are independent of other threads. Instantiating a thread gives gives the OS the information it needs to use a core for that single SL process. Older versions of the servers and viewer had way fewer threads. In 2010, 11, and 12 it was considered pointless to enable multi-threaded processing for SL. There just wasn’t much performance advantage. That is no longer the case.

          Your original comment seems to imply the Lab was incapable of and SL was not using multiple threads.

  7. Pingback: Project Sansar: Hours to Build? Really!?! | Nalates' Things & StuffNalates' Things & Stuff

  8. Pingback: Projet Sansar : Unity ou Unreal ? | Pierre Ceriano

Leave a Reply

Your email address will not be published. Required fields are marked *