测试流程改进_生产工作流程的改进

测试流程改进

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.

即将发布的Unity 5.0版本具有众多新功能。 它还包括对工作流程和生产的许多改进，特别是对于团队而言。

场景冲突 (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.

在团队中工作时最大的烦恼之一就是场景文件中的冲突。 当多个人同时处理同一场景文件时，很容易发生这种情况。 通常，这是因为预制实例将在Unity 5.0之前添加到场景文件中的所有对象。 只需打开一个场景并再次保存它而不进行任何修改，就可以将一个预制件的所有对象实例统一写入场景文件，如果其他人也这样做，肯定会产生冲突。

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.

实例对象中的这些类型的冲突通常很难解决，因为它们可能是ID和其他属性，但解决冲突的方式并不总是很明显。

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.

事实是，我们实际上并不需要将所有预制实例的对象都写入场景文件，但是由于历史原因，直到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.   

在Unity 5.0中，不再将所有实例对象写入场景文件，而是仅写入包含实例修改的预制对象和场景中可能引用的对象。 引用的实例对象仅以剥离形式编写，以确保引用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.

如左图所示。 在这里，我已经在Unity 4.6中创建了一个简单的场景，其中包含一个预制体，该预制体具有一个Cube，一个Sphere和一个Capsule GameObject。 在左侧，您将看到所有实例对象如何写入场景，在右侧，只有经过实例修改的预制对象存储在场景文件中。

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.

在Unity 4.6中，光照贴图属性(例如，光照贴图的偏移量和缩放比例)存储在光照贴图中包含的每个渲染器中。 这意味着这些属性存储在场景文件中。 如果两个艺术家都在更改同一场景并进行灯光映射，则所有这些属性可能会发生冲突，从而导致整个场景文件发生许多微小冲突。 即使对gameobject的更改没有冲突。 这些冲突可能很多，您不能只选择使用场景文件的一个更新，因为您可能会丢失在另一个更新中完成的工作，但是您可能必须做出选择并重做一些解决每个冲突可能会花费更多时间。

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.

从Unity 5.0开始，所有与灯光映射相关的生成的属性值(如uv-offset，uv-scaling和lightmap索引)都存储在单独的资产中。 如果两个人修改了一个场景然后烘烤了光照贴图，则光照贴图资源当然会发生冲突，但是场景文件中的更改很可能不会发生冲突，并且如果这样做，则应该更容易解决。 仍然需要重新映射灯光映射，但是与尝试解决冲突或重做场景修改相比，最有可能减少耗时。

场景合并工具 (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.

当然，仍然会有场景文件发生冲突的情况，但是由于消除了预制实例和光照贴图属性，因此这些冲突主要与艺术家的实际更改有关，应该更容易解决。 为了使解决这些冲突更加简单，我们开发了一种场景合并工具，该工具知道场景文件的语义，并且能够基于对象而不是简单的文本比较来合并场景文件。 该工具用作预合并工具，这意味着您可以在启动三向合并工具之前将版本控制系统设置为合并场景，或者如果您在Unity中使用内置的VCS支持，则可以启用通过“编辑器设置”创建场景合并工具。

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.

冲突不仅令人讨厌，而且即使您没有进行任何更改，由于场景肮脏而不断被要求保存场景也很令人讨厌。 当您显然没有在场景中进行任何更改时，诸如更改窗口的停放位置或检查某些资产之类的操作可能会使场景显得肮脏。 对场景的间接更改(例如重新烘焙光照贴图)也会将场景标记为肮脏。 对于Unity 4.6，这实际上是正确的行为，但是由于所有与光照贴图相关的数据都已移至资产，因此Unity将不再需要您再次保存场景。

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.

为了解决将场景错误地标记为脏的问题，我们已将对场景脏状态的跟踪移至撤消系统。 与编辑器中的场景相关的所有操作都是不可撤消的。 将新项目添加到撤消堆栈时，UndoManager将检查该项目，并查看更改是否与场景或资产相关。 如果与场景有关，则UndoManager会增加场景的肮脏程度。 当您随后执行撤消操作时，场景的脏度实际上会减少，因此您可以对场景进行一堆更改，全部撤消它们，场景将不再被标记为脏的。 当然，重做会使场景再次变脏。

但是等等，还有更多 (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. 

层次结构窗口和场景视图选择已进行了重大优化，这使Unity在大型场景中工作时的响应速度更快。

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.

AudioClip现在支持多选编辑，因此您不再需要一一更改所有剪辑上的相同属性。 只需选择您要更改的所有剪辑，然后一次全部获取即可。

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.

首次导入FBX文件时，现在已考虑到文件中的缩放比例设置，因此工作流程不再需要您导入FBX，更改缩放比例然后重新导入。 如果正确设置了文件中的比例设置，则模型应具有首次导入后的预期外观。

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.

最后但并非最不重要的一点是，我将要提到的是，该编辑器正在所有平台上都移至64位，这意味着与以前可能会产生内存不足问题的项目一起工作应该会减少麻烦。

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.

总而言之，上述更改以及可能的更多更改将使您在Unity上的日常工作更加高效和顺畅。

翻译自: https://blogs.unity3d.com/2015/02/17/production-workflow-improvements/

测试流程改进