What is the point of the new feature: Multi Scene Editing ?

I am at a loss. This feature seems to add drawbacks without adding any actual usefulness. So I assume I am simply missing the obvious?

At first I was extremely excited about this feature, especially when reading Unity’s release notes. (Ohh! Streaming worlds! Solving big world problems!?)

When actually messing with this though, I quickly realized it doesn’t seem to be any different than what I was already doing: Having a single “GameObject” act as the “Scene” or chunk of world. With everything being handled by that master gameobject.

Changing it to a scene format, and it seems as though I am simply getting rid of that master gameobject and replacing it with a “Scene”. However, to move everything within that Scene, since the Scene itself has no transforms, it seems as though I’m still better off using a master gameobject even within that Scene.

Well, what about loading/unloading scenes? This seems to be done in the Editor, not during Runtime. During runtime, from what I understand messing around, you do what you’ve always done: either load a single scene (LoadSceneMode.Single) which is identical to what we used to do to change Scenes, or LoadSceneMode.Additive, which is no different (or just another unnecessary step) to loading a master gameobject that loads a “Scene” (all the gameobjects). Except that we now have the extra annoyance of having to constantly switch the “ActiveScene” since there can be only one. Is this a step BACKWARDS from what I was already doing? (I didn’t need to change the “ActiveScene”, just enable/disable master gameobjects and handle them in code. Which is exactly the same, minus the line of code “SceneManager.SetActiveScene”.

What am I missing? I understand that multi-scene editing can help with

  • Collaboration

However…how is this any different than simply exporting/importing Prefab packages? (The exact same method of collaborating on a “Scene” by collaborating on a single master gameobject Prefab.

  • Streaming Bigger Worlds

Does this resolve the floating point issue big worlds have? How is this so? All scenes would still need to be overlapping one another (in which each scene needs to have its own camera settings, render layer, or what not.) This is no different than doing the exact same thing though with master gameobjects. To have the worlds connect without having the same transforms, you’d need to have the whole scene under a master gameobject ANYWAY even if using multiple scenes. So what’s the point in this if Scenes don’t have their own transforms relative to other Scenes?

  • Reusable Elements

I saw a video where the person had a background as one scene, and the level/platforms on another. How is this any better than simply using a prefab for the “background” and loading that instead of loading the scene?

1 Like

So I guess there is no point to it, other than a different way to organize gameobjects that is slightly worse than what we could already do?

Possibly that it is a base feature to be used in the future when they add in additional features, finally allowing it to be useful?

It’s been two months, but I am still very interested in getting an answer to this.

Does anyone know, or am I correct to assume it’s a pointless/useless feature?

1 Like

Hmmm, I haven’t been in a project that uses the new multi-scene functionality lately, but I have been in a project that had a large detailed urban map (5km x 5km IIRC though it’s been a while, street-levell detail similar to one of the last few GTAs).

It used a plugin to simulate multi-scene functionality using prefabs as you describe.

Here are my notes:

  1. Prefabs don’t nest. 10000 street lamps over multiple sectors? Oh, your level designer wants go adjust the light colors now? He needs to drag a programmer over to write an editor script for him because he can’t update the prefabs or he can go cry in a corner if there’s no one available.

  2. Our scenes run fast once built, but cause computers to unscrew themselves and shuffle off the desk if they’re loaded all at once during edit mode. You’ll need special edit-time code to load and unload prefabs as you don’t want them at all in the hierarchy during author time.

  3. It’s not a solution for really huge worlds where lack of floating point precision is hard to work around and you really need to do manual recentering for everything. It does however cover most large worlds where all you really want is a 100 sq km detailed play area.

Again, I haven’t used the new multi-scene in-depth yet, but this is something we really really really wanted when we started our project and instead had to make do with a plugin that simulated multiple scenes. It’s also something we will likely need once we have another large-world project.

1 Like

It’s so unfortunate we still don’t have nested prefabs (a highly demanded feature that has been asked for since forever), but we get useless features like this instead (announced 1-2 years prior).

The Asset Store has some pretty cheap nested prefab solutions though, and anyone tackling a huge project like an Huge Open World (must be a competent/serious developer) and thus has no excuse to not purchase some necessary assets.

But I guess if you want to mess around with big worlds but don’t want to take it seriously, this is a nifty feature to have.

As some pointed out, the only real benefit of this is Lightmaps. Although I have no experience with those, so I assume they are right even though I’m a bit skeptical there too.

  • Prefabs don’t nest. You’re right about that. Although having to parent all scene objects onto a gameobject kindof defeats the purpose, doesn’t it? At best though, this gives you a very slight way to nest one additional level or make things marginally more convenient (while making it more inconvenient too).
  • You can cut your huge world into chunks and disable/enable them during edit mode and runtime. In fact, this is a necessity during runtime (Things like Animators being enabled consume a ton of CPU power. You’ll want to disable them & only enable them via proximity. Methods like GameObject.Find will destroy your performance when loading big worlds, and although you never want to use that in the first place, loading/unloading scenes does help resolve that by limiting the number of gobs loaded at any one time.)

With major parts disabled (rendering, animators, etc.) huge worlds don’t consume your entire PC life, don’t slow down the editor, etc. In all actuality when you take out those parts (use a player proximity enabler) you can have a tremendous amount of data still active, and that’s all that is important. You can also simply disable in chunks during editor time or work on temporary scenes with individual chunks without the entire world as an alternative, although I don’t think that’s necessary (IMO, I’d want to work on the entire world as is. Enable/Disable chunks that are always available so I can see the entire world at all times when working on sections of it.)

  • It doesn’t resolve the biggest issue people face with large open worlds (floating point precision). This is the biggest problem with the feature and part of why it is pretty much useless. (I don’t really know how others resolve this issue, outside of a very simple Farnsworth method of having the entire universe move around the player (who is always at 0,0,0) and then having Server/Client type of logic to synchronize players & adjust their world accordingly. I have to disagree with the last part. It doesn’t cover large maps within the boundaries of floating point precision anymore than the previous method did (editing one scene & using prefabs). For this to be useful, it has to provide a benefit that doesn’t already exist using prefabs, master gameobjects, etc.

I will have to check into the lightmap thing others have mentioned (just out of curiosity) to see if there is any validity there. That may make a huge difference, giving this feature a valid reason for existing.

I was initially very excited when this feature release, but was quickly disappointed as I realized how useless it is and how inferior it is to how I was already doing things.

But if you say Multi-Scene Editing (or the asset store equivalent, simulating them) really helps you develop your game & collaborate, then I believe you.

I haven’t even used the new multi-scene feature… my impression of 5.3 is just a bug release… by that I mean… a release of bugs. :smile:

Also good to see the unity learn team have also done a great job showing non pro users a quick heads up on how new features can be used and where it makes sense to use it. 5.3 was out like 3months ago now. A quick search on the feature and Unity Blog …comes up… practically a year before it was ever even released… that along with pro users testing it separately before release… it would seem like multiscene feature had most its talk and best usage discussion way before it was ever released. This is like the first discussion i’ve seen regarding it and user experience with it. Kinda sucks what you have summed up about it.

“It’s so unfortunate we still don’t have nested prefabs”

yes now that’s a feature I’d like to see to improve uGui workflow… of course I’m given the impression that Unity’s implementation and follow through with newer features leaves a lot to be desired.

2 Likes

Additional notes (some of this is just coming back to me)

With our world; even with a scene where most of the assets are loaded but start disabled, just the act of enabling and disabling chunks while everything was loaded was horribly slow. Think about it…

A blank scene view with everything loaded but disabled, was unusably slow.

Turns out the prefabs for each sector don’t need to be just disabled, they needed to be deleted from the scene when you’re not working on that particular sector, and added back when you need to align things etc.

The editor helpers we used forcibly expunged them entirely from the hierarchy when we didn’t need them, but kept a blank gameobject with a pointer to which prefab contained the sector so we could load and reload the chunks we needed via a click or so.

The interface in the multi-scene editing matches the workflow that we were using before with the new Load scene and Unload scene commands.

Unrelated note: It doesn’t solve floating point precision problems for large worlds by itself, but I can think of a workflow for that that would be made much easier with the new multi-scene capabilities.

@Player7 I really liked your entire post. It expresses a lot of what I think/feel, especially with me being a long time Unity user. I was around since before Unity even became a thing (popular) and the company’s quality/attitude seems to be the same as it has always been. Ignore highly requested features in exchange for doing things no one ever wanted, in an incredibly slow & buggy way!

At this point it’s not really an impression as much as a consistently founded fact, huh? hehehe.

I honestly don’t recall a time where Unity’s implementations have ever met a quality standard at release, and their follow through with new features is as tremendously horrible as an amateur coder who shares everyone their open source of a MMORPG project abandoned after 1 1/2 months of part-time hobbyist work. (A bunch of spaghetti code, next to no features, and barely even works with the few features it supports.)

Although I do note one exception, IMO: The new GUI. This was a long time coming, but seemed pretty good at release. Pretty great addition. The 2D addition was a great update too, but infinitely too late, completely ignored after-the-fact, and filled with a tremendous amount of bugs. Bugs in things like rendering pixels & impossible-to-achieve smooth movement- the most important aspect of a video game. UNACCEPTABLE!!!

In other words: Their follow through on new features reminds me of what I see with newbie coders who abandon projects after doing nothing with them. It’s that bad, IMO.

I mean just look at the 2D features. That was something that was desperately needed since the beginning of Unity. Endless number of years later, and they FINALLY add 2D support. After 4.2, what have they done? Next to nothing. You could argue they did the GUI, but that’s not a 2D feature. It’s a requirement for 3D, which is their only real focus.

They consistently “Throw us bones” years too late, then run off to chase meat of a completely different species. It blows. Fortunately though, we have the Asset Store. That is the only reason I use such a mediocre product written by such an seemingly-amateur company. That Asset Store brings in quality developers who really know their stuff, doing work for you at pennies per hour, making it one of the best engines around. Not that other engines are amazing anyway, so it’s not hard to be the best in a world full of crap / world built for corporations with lots of money. It’s just that Unity is great to use DESPITE being a pretty awful game engine BECAUSE it saves you time in SOME areas and saves you learning in a field that can easily overwhelm you (burn out your brain from having to learn too many niche technical subjects).

I guess I have to admit that Unity is also great because

  • You can skip learning some technical aspects, which helps prevent burnout when you still have to learn an overwhelming number of skills & bits of knowledge

Although that hurts you in the long run… it can save your game’s life (from being abandoned due to burnout) in the short term. (For example, I don’t have to learn ANY networking code / engineering because I can use Forge Networking. I don’t have to implement my own GUI / Game Tools because Behavior Designer & Dialogue System already do it for me. All for pennies on the dollar for the hours required to make that stuff.)

Why? This sounds like a problem that needs to be resolved using the Profiler.

I don’t have that problem, and I load thousands of gameobjects in my scenes. Once some aspects of them are disabled, even the Editor runs flawlessly. (I don’t disable the gameobjects; no need to. I just disable all rendering related things. I even keep colliders on.) You have to be careful though, a single call to GameObject.Find() in a large scene can decimate performance.

I’m very curious as to why you were having problems. What did the Profiler say? What was the cause & why were you unable to fix it?

Could you share a simplified/vague version of this workflow? What could multi-scene do to resolve the fpp issue that couldn’t be done before just as easily?

This was what I was excited most about with this new feature. I immediately assumed, like any reason person would, that it would resolve the fpp issue. Even Unity’s announcement acted like it did. But it doesn’t. It did nothing of the sort. It’s why I was incredibly excited, and then incredibly disappointed, that it didn’t. If each scene had its own master transform, but when within that scene had its own transform (every scene has its own 0,0,0 position within itself) then you could simply have each scene be smaller than the limit and bam! Problem resolved. But nope! Wasn’t done that way, which makes the feature announcement seem like a very misleading lie. “Look, we added a feature that you’ll think changes EVERYTHING, so applause us. Please clap. Just ignore the fact the feature is meaningless so we can continue on being lazy.”

The problems we hit don’t appear until you hit a certain level of scale and detail.

In our world:
Just one kind of bush
=> can have almost ten thousand instances
=> with each instance likely having more than one gameobject.

The current versions of Unity are better, but older versions of Unity had problems with even just too many objects listed in the hierarchy, enabled or not. The updated version crashes on me at around 1 million empty gameobjects; I imagine it will be much earlier with heavier objects.

We were modeling real world locations which dictated that each building had unique meshes and textures at a decent level of detail. Unity will always load the resources for all scene objects from disk into RAM even if they’re not rendered. It’s not a render issue at this point, it’s just too much data loaded into memory causing thrashing.

For floating world origin, I was just toying of the idea of a parent GameObject at the head of each subscene containing world offsets as doubles. We usually only need the chunks loaded simultaneously when checking alignment of chunks vs each other, so we just need an editor script to fix up the offsets of all live chunks relative to each other. Click the scenes of the chunks you want to check, then click a script to fixup the offsets. Not really much different from prefab based chunks, except you have the multi-scene feature ensuring chunks aren’t loaded into memory when not needed.

TLDR; Even when entirely disabled, GameObjects in the hierarchy will cause resources such as meshes and textures to be loaded into RAM. If you have a lot of meshes and textures, they will fill RAM. If RAM is full, bad things happen.

1 Like

Say no more. Now I completely understand. Unity is Unity…oi vei. Especially that Editor…ugh!

1 Like

I haven’t been in a situation to work with multi-scene editing in Unity yet. The general idea with streaming in portions of a world is to load and unload unity scenes, right? At least that is how I have understood it to be done.

If that is the case, then multi scene editing would be beneficial in that it allows you to open and modify multiple chunks at once. For instance…if you are making an open world game, and you need to edit the border of 2 zones, you can simply load them both and use the other for reference for lining things up.

At least, that is similar to how I have worked on other projects with different tools, but similar workflow.