Search Unity

The upcoming release of Unity 5.0 has a myriad of new features coming. It also includes a number of improvements to workflows and production, especially for teams.

Scene Conflicts

One of biggest annoyances when working in a team is conflicts in the scene files. This can easily happen when multiple people are working on the same scene file at the same time. Most often this is because of all the objects that a prefab instances would add to the scene file prior to Unity 5.0. Simply opening a scene and saving it again without modifying anything would make unity write all the object instances of a prefab to the scene file which would certainly create conflicts if someone else was doing the same.

These types of conflicts in instance objects were often hard to solve because they might be IDs and other properties where it was not always apparent how to resolve the conflicts.

The fact is that we don’t really need to write all the objects a prefab instances to the scene files, but for historical reason we have been doing that up until Unity 5.0.

In Unity 5.0 all the instance objects are no longer written to the scene file, only the prefab object containing the instance modifications and objects which might be referenced in the scene are written. Instance objects that are referenced are written in a stripped form only to ensure consistent reference ID.   


Click to see full image.

This is illustrated in the picture on the left. Here I have created a simple scene in Unity 4.6 containing a prefab which has a Cube, a Sphere and a Capsule GameObject. On the left you see how all the instance objects are written to the scene, on the right only the prefab object with instance modifications are stored in the scene file.

The only conflicts related to prefabs will now be in the prefab modifications which means two people modified the instance of a prefab in a scene and that should be a lot simpler to resolve.

A second cause for conflicts that is hard to solve and has been a problem for people working in a team is lightmapping.

In Unity 4.6 lightmapping properties like lightmap offset and scaling is stored in each Renderer that is included in the lightmap. That means these properties are stored in the scene file. If two artist were both changing the same scene and doing lightmapping, all these properties would probably conflict, resulting in a lot of tiny conflicts all over the scene file. Even if the changes to gameobject did not conflict. There can be a lot of these conflicts and you can’t just chose to use one of the updates to the scene file because you might lose work that was done in the other update, but you will probably have to make that choice and redo some of the work because resolving each and every conflict could be even more time consuming.

All the generated property values related to lightmapping, like the uv-offset, uv-scaling and the lightmap indexes, are as of Unity 5.0 stored in a separate asset. If two people modify a scene and then bake the lightmapping, the lightmapping asset will of course conflict, but chances are that the changes in the scene file will not conflict and if they do it should be much easier to solve. The lightmapping would still need to be rebaked, but that will most likely be less time consuming than trying to resolve the conflict or redo a modifications in the scene.

Scene Merging Tool

Of course there will still be situations where scene files will conflict, but having eliminated prefab instances and lightmapping properties, these conflict will mostly be related to actual changes made by an artist and should be much simpler to resolve. To make it even simpler to resolve these conflicts we have developed a scene merging tool which knows the semantics of a scene file and is able to merge scene files based on objects and not simple text comparison. The tool works as a pre-merger, which means you can set up your version control system to do the merging of a scene before launching a three-way merge tool, or if you are using the builtin VCS support in Unity, you can enable the scene merging tool through Editor Settings.

Of course all of the above only applies when you are using text serialisation. If you keep scenes and other serialized files in binary format, conflict cannot be resolved and scenes cannot be merged.

Tracking scene dirty state

Not only are the conflicts annoying, but constantly being asked to save the scene because it is dirty even though you did not make any changes is also annoying. Things like changing the docking position of a window or inspecting certain assets could make the scene appear dirty when obviously you did not change anything in the scene. Indirect changes to the scene like rebaking the lightmapping would also mark the scene dirty. For Unity 4.6 this was actually correct behaviour, but since all lightmapping related data was moved to an asset, Unity will no longer require you to save the scene again.

In order to fix the issue of falsely marking the scene as dirty we have moved the tracking of the scene dirty state to the undo system. Everything you do related to scenes in the editor is undoable. When a new item is added to the undo stack the UndoManager will inspect the item and see if the change is related to the scene or to an asset. If it is related to the scene, the UndoManager will increase the dirtiness of the scene. When you then perform an undo the dirtiness of the scene will actually decrease, so you can make a bunch of changes to your scene, undo them all and the scene will no longer be marked as dirty. Of course redoing will then make the scene dirty again.

But wait, there is more

The hierarchy window and scene view selection have been heavily optimized, which makes Unity feel more responsive when working in large scenes. 

AudioClip now supports multi-selection editing, so you no longer have to change the same property on all clips one by one. Just select all the clips you want to change and get it over with all at once.

On first import of FBX files, the scaling settings in the file are now taken in to account, so the work flow no longer requires you to import an FBX, change the scaling and then reimport it. If the scale settings in the file are setup correctly, the model should look the way you intended it to look after the first import.

The last, but not least, thing I will mention is that the editor is moving to 64bit on all platforms, which means working with projects that would previously produce out-of-memory issues should become less frustrating.

In conclusion, the changes mentioned above, and probably many more, should make your day to day life working with Unity even more productive and smooth.

32 コメント



  1. I am using the latest patch release of the Unity 5.0.0 P2 but I can’t find the scene merging tool in the Editor settings?

  2. This is awesome. Scene conflicts was the single biggest issue our team was facing.

    However, there is still another pain point. When I animate a material, it changes the actual material in disk, but only in the editor. This means that every time I hit play, it modifies the material, which causes superfluous vcs commits and conflicts. It causes the game to behave different in the editor and other players. Also it is not consistent, because objects in the scene don’t have this issue.

    I did file a bug with this, but it got closed as “by design”. To me a design that modifies source code every time you run it is a terrible design.

  3. “On first import of FBX files, the scaling settings in the file are now taken in to account, so the work flow no longer requires you to import an FBX, change the scaling and then reimport it. If the scale settings in the file are setup correctly, the model should look the way you intended it to look after the first import.”

    Wooow, finally.
    It took only how many, 8-10 years to ‘implement’? Let’s make a calculation, saying that one Unity user spends 1 hour in a year with applying scale parameters and reimport an asset in every year (depending on the projects it could be far-far more).

    Unity has 600.000 active (and millions of temporarely active) users.

    It means that 600.000 hours per year, 4.800.000 hours overall (for 8 years).
    One year = 8760 hours.
    4.800.000 hours = 547 years the users spent with tweaking a badly implemented feature.
    Then calculate the cost of this and think, how happy we should be with this extra care we got here as a “workflow enhancement” on FBX import.

    Sorry for being sarcastic, but I think I’m right. I hope some other enhancements will arrive, but with a more reasonable ‘development time’, like it happened in the ‘old Unity times’.

  4. Henry Tirthyfour

    2月 20, 2015 6:21 pm


    I see there is a bug report for this, but I wanted to know if the Unity team is working on fixing the bug on Lightmap generation for Intel HD graphic cards on Mac. I would like to experiment with some scenes in Unity 5, but the Lightmapping generation is broken as it creates surfaces shimmering with multi-colored noise. This happens also with a basic unwrapped cube in an empty scene.

    1. Aras Pranckevičius

      2月 22, 2015 2:40 pm

      That is fixed in RC3 as far as I know.

  5. Awesome!

  6. thienhaflash

    2月 19, 2015 6:56 am

    Sounds cool ! Looking forward to the scene merger

  7. Hi, can anybody tell me is UNET ready and how to use it :) ??

    1. Jashan Chittesh

      2月 19, 2015 8:15 am

      I guess that would be more appropriate to ask in the forums … but … I don’t think the Unity Networking will come with Unity 5.0 because it’s not even in the beta / release candidates, yet. I think the announcements were all “in 5.x”

      1. Jashan Chittesh

        2月 19, 2015 8:16 am

        Ohhh … gives us editing powers please ;-) … not “I don’t think the Unity Networking will come” of course, but “I don’t think *that* Unity Networking will come” … [hides]

  8. Jashan Chittesh

    2月 18, 2015 7:29 pm

    I love workflow improvements like these!

    I still do have one related bug open, though: Case 664751 – Scene isn’t dirtied when making a prefab …

    And I’m filing another bug report right now with a scene that always gets dirtied … so that’s (Case 673337) Scene AStartmenu is always dirtied

  9. Any news on multi-scene editing?

  10. Russ Painter

    2月 17, 2015 11:43 pm

    The scene conflicts are a huge problem for teams. Really glad this is being tackled in the next version.

  11. ercila fernandez

    2月 17, 2015 11:25 pm

    descargar dino unter

  12. This is why I love Unity.

  13. We also suffer from having scene conflicts all the time, which is quite frustrating. Good to hear you fixed it!

  14. Like where U5 is headed. Just wanted to know if the Editor will be 64bit only in unity5 or will you support a 32bit verions as well? Keep up the good work.

    1. Aras Pranckevičius

      2月 17, 2015 7:03 pm

      Both 64 and 32 bit on Windows; 64 bit only on Mac (based on our data, there are virtually no 32 bit Macs left in use).

  15. Will nested prefabs be part of this workflow, if not now, maybe in the near future? Being able to nest prefabs would be a way for some team members to work on prefabs rather than scenes and avoid modifying the scene in the first place. e.g., artists changing the visual aspects of prefabs, designers tweaking parameters.

  16. Bryan Livingston

    2月 17, 2015 5:13 pm

    Thank you! These are the exact kind of pain points that have been driving me crazy!

    Please make an option to have the scene save on play. I’ve lost a days work before by having Unity fully crash due to a simple infinite loop in a behavior before.

  17. I would REALLY like a way to “undirty” a scene. For instance, there’s many plug-ins that make changes to a scene which are computational only and not reflected in the saved state. I need a way to get these changes done without the editor thinking it needs to resave the scene. Case in point: Angry Bots demo does this constantly. My plug-in (Advanced Additive Scenes — an implementation of your upcoming Multi-Scene Editing feature) needs to flip the HideFlags a few times during the save process, which really shouldn’t dirty the scene.

    1. Joachim Ante

      2月 17, 2015 5:24 pm

      This is already solved in 5.0 with above changes.

      Scenes are only dirtied if you register an undo command.
      If you don’t support undo then it will not be dirtied at all. Our goal is to apply this technique to all changes, like assets / materials etc in 5.x.

      In case registering an undo operation is not possible you can use:

  18. will any of these changes on how lightmapping assets are handled be rolled down into a 4.6.x release?

  19. This is awesome news, congrats on the improvements!

  20. Nikolay Dimitrov

    2月 17, 2015 2:06 pm

    Unity 5 is looking to be an awesome update :D

  21. I know I’m asking a question that can’t be answered, but, when is unity 5 supposed to come out? Within a month or two, or the end of the year? Or next year?

    1. Aras Pranckevičius

      2月 17, 2015 2:37 pm

      Since we’re in “release candidate 2” right now… that would mean it’s not very far away.

      1. Awesome, thanks! These blog posts are getting me more and more excited about using it. So, thanks for the info :)

  22. Marc-André

    2月 17, 2015 1:19 pm

    “AudioClip now supports multi selection and editing”

    Awesome! Why wasn’t that a thing from the start?

    1. Aras Pranckevičius

      2月 17, 2015 1:49 pm

      Short answer: because features don’t implement themselves :)

      Longer answer: because old audio code was causing a lot of data to be read into memory when an audio asset was selected. Selecting multiple of them + 32 bit editor would have meant “out of memory” in pretty much all cases. Or something like that.

      1. Every day we can delete a workaround editor script from our projects is a good day :D

  23. Much appreciated changes, how wonderful life is – when you just make your game and engine improvements show up like birds in the window while you eat your breakfest :)