Search Unity

Production workflow improvements

The upcoming release of Unity 5.0 has a myriad of new features coming but also a number of improvements to workflows and production especially when working in a team will the improvements be beneficial.

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 prefab instances. Simply opening a scene and saving it again without modifying anything would make unity write all the prefab instances to the scene file which would certainly create conflicts if someone else was doing the same.

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

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

In Unity 5.0 prefab instances are no longer written to the scene file.

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 instances are written to the scene, on the right only the reference to the prefab and the prefab 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 which 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 will have probably have to make that choice and redo some of the work because resolving each and every conflict could be even more time consuming.

Lightmap setting and all the properties related to lightmapping like the uv-offset, uv-scaling and the lightmap indexes are as of Unity 5.0 stored in a separate asset. In case 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 conflict 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 premerger which means you can set up your version control system to do 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.

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 it 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 dirtyness of the scene. When you then perform an undo the dirtyness 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.

32 评论

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.

“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’.

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.

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”

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.

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.

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.

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.