Search Unity

Many exciting new features are coming as part of the Unity 5.x release cycle, but we are also making improvements to our existing features and workflows. One of those areas is our level management and scene editing.

For various reasons, it is sometimes necessary to divide a game level into multiple scenes in Unity. This could be because the level is big and/or you want to support streaming of parts of the level. You might also decide to divide the level to make it easier for multiple people to work on the same level without creating too many conflicts in the scene files.

Whatever your reasons for dividing a level into multiple scenes were, you probably had to write some editor tools for supporting multiple scenes. If you used it for level streaming, you probably wanted to have multiple scenes in the editor in order to align geometry properly or maybe you wanted to combine multiple scenes into one scene before building the player.

At runtime in the player it is already possible to load multiple scenes at once using APIs like Application.LoadLevelAdditive. Unfortunately, there has never been the equivalent UnloadLevel. So while loading additional data is straightforward, unloading data required for you to do bookkeeping of the game objects created when loading additional data or to structure your scene in a way that made it easy to destroy the scene again.

For those of you who are familiar with these issues, we would like to introduce you to the SceneManager. The SceneManager is a new API that makes it easy for you to manage your scene at runtime. It handles all the necessary bookkeeping of game objects, so you do not have to think about which game objects to destroy when unloading a level.

Loading a scene additively is simple a matter of calling SceneManager.LoadSceneAdditive(“MyScene”), unloading the scene again is simply SceneManager.UnloadScene(“MyScene”).

There are a few more APIs for handling which scene newly created game object are added to and moving game objects between scenes hierarchically (not spatially) as well as asynchronous versions of the load scene APIs, so you can keep you player busy while loading other parts of your game level.

On top of the SceneManager you can implement the level loading or streaming that suits your game, whether that be based on tunnels and portals or player proximity is completely up to you.

In the Editor, we have used the SceneManager to implement what we call Multi Scene Editing. This feature allows you to have multiple scenes loaded at the same time in the Editor and will look somewhat like this:

Now it will be easy to align you level objects across scenes and move objects between scenes. We are working on how to support the baking of navmesh, lightmap and occlusion culling with multiple scenes loaded. The goal is to have it all working together smoothly.

A bonus that comes with this workflow improvement is that the edited state of each scene is now tracked through the undo system, which will reduce those strange cases where the scene was marked as edited when rearranging tabs or inspecting materials even though the scene was never touched.

NOTE: This feature is not shipping in Unity 5.0 but we are working on it for a later release

74 replies on “Multi Scene Editing”

[…] after Unity 5, new features are being developed for the Unity product. One of those is Multi Scene Editing, which will expand Unity’s ability to stream multiple levels. This will introduce a Scene […]

@STEEN @DEVIL_INSIDE — in 4.x you can mark an object as locked — needs an editor extension though. My «Unity Editor Enhancements» does it if you want to look at the code.

What a wasted time and energy. This functionality is completely obsolete after finally we get nested prefabs (which is requested for years now and told to be included even in the unity 4 cycle). Scenes are nothing else than prefabs + some meta information (from which only the meta information of one scene can be active at a time).

So please don’t waste time with this useless feature by reproducing features which are already there.

Dang. I don’t know weather to rejoice or to cry because I’ve sunk quite a bit of time into writing my own scene management system and level loading/unloading queue. In any case its definitely a feature in very high demand. Sounds like this will be the perfect implementation, leaving us to decide how exactly we want things to load in.

also another feature request i think would be very nice. when we load a level can we offset the scene by a certain amount? this wouldn’t just be for connecting world tiles but also dealing with floating point precision problems. this would be really useful. anyway just a thought =3


Some times scene post process takes a long time and loading scene in playmode lead to big pause and inability to test gameplay in editor.

Please add cache of postprocessed scenes for ineditor gameplay testing :)


for most open world game which are already very memory heavy they use dynamic batching. asset store has a really good and cheap one. however i still think baked batching with streaming is important. options are always good! many large levels will want it but be to large to bake all at once.

«I think this workflow is not suitable with open world games with 500 x 500 kilometers world that can consist of 250000 scenes and hundreds Gigabytes of content that can not be loaded into memory for lightmap, occlusion culling, navmesh… generation.
64 bit editor don’t help here.

We absolutely need independent baking.»

So you are making a streaming 500km x 500km level? Awesome!

I think the best way for us to support such a setup with baking is to make it so that everything is split well defined on a grid, and then always load the surrounding geometry in order to perform the bake of one level. That approach can be made to work with the different baking system we have. But at that point we are making a lot of specialized assumption for how your streaming scenes are split what surrounding levels are needed etc. So most likely it would involve some baking API’s that are not exposed via the builtin UI.

Anyway, i dont think this is the most important case to make work well first.
Our first priority is to make Open all scenes, hit bake workflow work. And unity will split the data for you automatically and so at runtime only the needed data is loaded.

I think a scenario where loading all streaming scenes in one level can be loaded in the 64 bit editor without running out of memory and is quite reasonable, for the majority of streaming cases.


I think this workflow is not suitable with open world games with 500 x 500 kilometers world that can consist of 250000 scenes and hundreds Gigabytes of content that can not be loaded into memory for lightmap, occlusion culling, navmesh… generation.
64 bit editor don’t help here.

We absolutely need independent baking.


I don’t quite see why. In my understand, option #1 of baking, is not really feasable for any baking type on streaming scenes. Thus umbra not being able to do it at all is not a real world problem.

The right way to bake streamed scenes is to bake them when all scenes are loaded and split the baked data into chunks so at runtime only the necessary data is loaded. This works for lightmaps, navmesh & occlusion culling consistently and with good results.

So that is what I think the default workflow should be.

Have you guys though about rolling out your own occlusion system? Umbra have been ever since a limiting factor in Unity when it comes to streaming scenes, additive scene loading an the thus.

«Scenes can be split into blocks for which the occluder data can be individually computed. »
To clarify some more. It would be great if it was this simple. But in practice. The blocks must be perfect boundary sizes + overlapping geometry must be included for both scenes for correct results. Thus in practice both scenes must be loaded so the data can be extracted.

Baking scenes completely seperately from each other is thus impractical in umbra.

@Jes: Why you can not bake this blocks and load it individually in runtime?

Like i described. In Approach #2 streaming can be done and data can be split. however umbra does not support baking scenes completely independent from each other. At bake time all the umbra scenes must be loaded.

«Is this workflow possible with multi-scenes? (Maybe by setting the “owning scene” of the editor-only created GameObject to “null”?)»

Currently unity scene save and asset saving is driven by calling SetDirty (EditorUtility.SetDirty for scripts) or builtin components do it automatically on every property change. Our intention is to move away from this system and instead drive everything from undo. This requires that every single edit has undo, it puts that requirement on any tool from the asset store too. This does mean that some asset store tools that do not handle undo will break because the scene / asset will not be saved. But relying purely on undo, as you have already said, has an incredible array of benefits we can tap into long term.

@JOACHIM ANTE : For umbra this is impossible due to how umbra streaming works.

@From Umbra
Scenes can be split into blocks for which the occluder data can be individually computed. At runtime you can stream in the blocks that are required for visibility queries. This significantly reduces the run-time memory footprint and allows for infinite game worlds.

Why you can not bake this blocks and load it individually in runtime?

«A bonus that comes with this workflow improvement is that the edited state of each scene is now tracked through the undo system…»

An related-but-not-quite-related question: Does that mean that it will be possible to *not* having the scene become dirty when editor scripts do things like creating game objects or temporary changing values?

1. Editor tool script creates a hidden, non-saved GameObject (currently scene becomes dirty :( )
2. User makes a change X (scene should become dirty)
3. Editor wants to undo only the creation of the hidden GameObject (this should not make the scene clean again)
4. User undoes his change X. Now the scene should become clean again.

Is this workflow possible with multi-scenes? (Maybe by setting the «owning scene» of the editor-only created GameObject to «null»?)

@Joachim Ante most games would benefit from having multiple tags. i dont imagine the overhead for an array of strings would be that much compared to a single string. its something that would help people design games of all kinds. 80% of the people i work with use a multi-tag system. which as its a hacky-workaround still has little impact. however it is a pain to use and i think unity should have a real tagging system rather than just another layer you can set. its up to you guys but i think its a problem and holding it back doesn’t seem to benefit. maybe you can give me some number’s on how much this would hurt performance to have an array of strings on objects rather than just one. as far as i can tell you have an external list of strings that are referenced by a byte. just have an array of bytes instead? its 4 bytes per object for the array and as unity already chugs with 1500 objects i cant imagine the 4byte per object overhead would slow the system that much more. not trying to be bossy just confused. if its impractical and i just dont see it then you know better than i do. but if you could it would be an amazing feature/fix. =3 still looking forward to this scene manager!

«Sounds great. Will this work with Umbra? One problem we have with additive scene loading is not being able to use occlusion culling data.»

There are generally two approaches to solving this.

1. At bake time, bake different scenes completely seperate from each other. Then at load time somehow «merge it».

This approach may work on the surface for some things. Eg. you could have multiple lightmaps from different scenes and then you just make sure they still reference the right lightmaps afterwards. But in practice you want that tree at the intersection between the levels to cast a shadow into the other streaming block.

For navmeshes, in Unity 5.0 we can load an additive scene as a seperate navmesh, with the only way to connect it via an offmesh link. So you need to place offmesh links manually at all intersection points between levels.

For umbra this is impossible due to how umbra streaming works.
So overall this approach only works in limited ways.

2. Load all streaming scenes in the editor. Bake it, but save the relevant data chunks with each level so that at runtime memory is kept to what is loaded. Eg. the lightmap will contain the shadow from the tree in the neighboring scene, but the textures used by the neighboring level will only be loaded when that level is loaded.

This approach works for all levels very well. The practical downside is that a change in any scene, requires to open all the streaming scenes and rebake. And of course you need a 64 bit editor to not run out of memory while baking all those scenes at the same time (Thats the default in Unity 5)

We will support both approaches but they come with their tradeoffs of course.

Generally we are doing more and more in the area of incremental baking & caching. There is interesting optimization to this process in the future. Lightmapping will be the first to ship with this new approach in unity 5.

Sounds great. Will this work with Umbra? One problem we have with additive scene loading is not being able to use occlusion culling data.

Will LoadScene() return a Scene object? which would be the root node of the scene hierarchy, so that we can eg. query components inside the scene etc.
With this new system, things like Object.FindObjectsOfType() or Resources.FindObjectsOfTypeAll(), which return just about «everything under the sun and sort it out yourself» are starting to look pretty crude!

Adding this to the game object itself would have overhead for every game object even if you dont need it. I think it’s better to make a dedicated script that can handle custom layer needs for your specific game.

are there going to be editor commands for moving objects between scenes, appending new scenes, saving, loading, etc… i want to make an open world system where as you move objects they will be placed into specific chunks. also kind of a side-note. when are you guys going to allow either multiple tags or adding labels to objects or something(basically a list of strings on each gameobject). i ask because i could tag(or label) objects with different world layers. prop, architecture, etc… i use the layer system for rendering stuff and i pretty much always need more than one tag. this is really needed for open world zone tags and such. eg: mark a building as both architecture and cover.

@QuantumTheory: «Whoa whoa what’s that skylight happening at 3:11?»

We have directional ambient (sky/equator/ground colors; or alternatively ambient computed from the skybox). We’re also playing with the idea of having a simple «procedural sky» shader as the default skybox (with sky gradient + sun position). Someone should blog about these things soon :)

A usability request: allow me to drag a folder full of levels into the hierarchy to start editing them. this would make layered levels so much easier. example: if i was making an open world system and i wanted to load different parts of the zones at a time(buildings and terrain then interiors, colliders and set pieces then foliage and props, etc…) not a huge priority but would be really useful for not having to drag all the levels into the hierarchy! looks amazing and i cant wait! this will make open world a breeze.


How will the SceneManager.UnloadScene(“MyScene”) work with GameObjects that have been instantiated by the scene at runtime? Will they be affected by the scene unloading? Or is it only for the editor?

I don’t know why I start to look at scene as Prefab, Will you enable adding scene as children of scene in future? What if you make prefab tool more stronger like supporting nested prefab and remove all scenes idea

«If a data object is created by an editor script, how does it know which scene it should live in? i.e. new Mesh();»

Assets are always treated as dependencies and only stored based on the game objects that reference them. For example, if a mesh is created but then you assign the same mesh to two game objects in two scenes. (This is of course not something you would do in an editor script, but just to illustrate behaviour)

Then the mesh will be stored in both scenes, because both scenes reference the asset.
That is until you use AssetDatabse.CreateAsset, at which point the asset lives in the project and is thus reference from the scene instead of being pulled into the scene.

When locking a scene, there should be a little lock icon so you can tell easily. Beyond that, it’s very nice, very slick. Looking forward to it. Keep up the good work!

This is excellent! A lot of developers already use scenes in this way, so it’s great to have built-in support.
Does/will multi-scene editing have editor API support? Large projects will still need to be able to automate multi-scene hierarchies, complete with pre-locked groups (ie load in the «system» level, but don’t let the designers change it) and a selected active scene.
I really love where this is going. Keep it up!

This was not explicitly stated, but I would really much like ‘sub-scenes’ if it is not included.

A sub-scene is loaded like a prefab into the ‘current’ scene.

Right now I am using a ‘shared scene’ and loading it additive. This scene contains my common static components. Having to load it myself makes me write smelly loading logic. If this ‘sub-scene’ can be loaded with the rest of this scene on awake, I would be very grateful.

being able to blend lightprobe/lightmap data will be a huge plus.. but of course, only internals know the workings of the coming lightmapping system.

wish we could get more details on that too :D

Looks like a very cool new addition. Proper handling of global data like nav meshes, occlusion, and inter-scene object references will be really nice fundamental improvements.

For folks who don’t want to wait until Unity 5.x, SECTR STREAM ( already supports many of these runtime features and editor workflows, including lightmaps in sub-scenes, sub-scene unloading, and the ability to share scenes between multiple users. It’s even on sale (part of SECTR COMPLETE) for August Madness!

«B) Will it be possible to link objects between scenes? e.g. I have a public Transform member in an object in scene A, can I drag an object in scene B into that slot? And until scene B is loaded, that reference returns null.»

Scenes are meant to be loaded independently of each other and thus can not have direct references. Usually you would write some scripts to connect things dynamically when they are loaded. The whole assumption being that the streamed scene may or may not be there at any point.

«A) will this be a part of 5.0 or just somewhere in 5.x? If not 5.0, what’s holding it up?»

It’s simply that we have a lot of features in 5.0 to make sure that they work rock solid together. This one has a lot of impact on other features and wasn’t done when we had major feature cutoff for 5.0. Thus we delayed it for another release in 5.x after 5.0 has shipped.

Yes, an icon to show locked would be nice, plus also a setting for auto-locking added scenes (perhaps you’re only using them as reference).

Brilliantly simple implementation! I love it!
Two questions:

A) will this be a part of 5.0 or just somewhere in 5.x? If not 5.0, what’s holding it up?

B) Will it be possible to link objects between scenes? e.g. I have a public Transform member in an object in scene A, can I drag an object in scene B into that slot? And until scene B is loaded, that reference returns null.

This is amazing something I am looking forward too.

I have a quick suggestion for the Unity Team; when you lock a scene a Locked Icon should appear in the Hierarchy window beside the Scene that is locked, I could see developers having issues knowing which scenes are locked and not locked.

Additionally if you make scene an Unity.Object or gameObject than we can Activate/Deactivate it if we want and we often need to activate sceneObjects not in one frame but one by one so fps stays smooth. SO we need LoadSceneDeactivatedAdditiveAsync( Action loadedCallback ) and in callback we have root scene object so we can activate scene as we like. Also if scene will be GameObject we can add to it Script that represents scene in our game and all logic OnSceneLoaded OnScene Activated…

Make scene hierarchy view with scene root as default view even if we open only one scene opened and selecting scene in hierarchy must show all scene settings ( render settings, lightmaps…) in inspector.


Yes i have something like that in mind but not only for objects but for scene too (so you will see all objects in isolated scene but other objects from another scenes will be temporarily invisible )

Now that you’ve mentioned it, I’m not entirely convinced by the ‘active scene = object receiver *and* RenderSettings provider’ rule, especially in light of scene locking.

I can easily imagine working with a pair of scenes on a level:
1) One scene file that contains all the static level artwork — the artists check out and work with this one most of the time
2) One scene file that contains all dynamic and gameplay objects — the designers check out and work with this one most of the time, keeping scene 1 loaded but locked

In practice we’re going to want new objects to go into scene 2, but the render settings are an art thing and should come from scene 1.

Also, is scene locking going to automatically play nice with source control / read-only files?

i’m really glad that unity finally implement this. i have one question — there will be support for isolating scene and object via editor and via script? (so isolating temporary hide other object in scene and in hierarchy until we move to another scene or unlock isolate)

and asset provider related feature — what do you think temporary scene creating? I have in mind — no save scene functionality, completely isolated from other scene and — according to these restriction -bit better performance in editor (think as mode in Blender). It could be useful for some asset like 3d painting, modelling and so on. This feature could be exposed only in API because i think in normal workflow it would be close useless. I know it will not have high priority if ever but i will be glad if u comment this.

Although not directly related to scene management, but more to the notion of managing the connection between objects and the scene they’re related to — would it be possible to also unload assets from the project based on the asset package they came from? (e.g: Import custom package, and then remove all assets from that package?)

That’s a great feature!
Probably not very related, but scene locking got me interested: will it be possible to lock individual objects inside a scene? I sometimes really miss the option to lock an object so I can’t accidentally delete it / move it in space / move it in hierarchy.

Wow… after 5 years of developing with Unity and always implemented scripts which handled the unloading of scenes, it finally comes in the (near) future.
Now, please, add also events/callbacks/… anything where you can attach to and you will be noticed when a scene is completly loaded or unloaded!

Are you getting an object of the scene, like a parent object of the scene or anything where we can get objects of that scene? Currently we have a parent gameobject in all scenes, which has a script that will handle hierarchy when everything is loaded.

Moving objects between scenes, thats what i want to hear. Great feature and huge time saver. Runtime scene managment is also great. I am looking forward to use it.

Comments are closed.