Production workflow improvements
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.
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.
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.