[转] Draw Call未被批处理？告诉你在Unity 5.6中如何查找原因 [复制链接]

Posted 2020-09-20 decode126

Unity在5.6之前的版本中并未提供很直接的方式来查找Draw Call未被批处理的原因，但Unity 5.6在Frame Debugger中新增了一项功能，帮助开发者查找相关信息。今天这篇文章就为大家分享，在Unity 5.6中如何查看Draw Call未被批处理的原因。

相信大家都知道，Unity内置的动态与静态批处理有助于减少游戏中的Draw Call数量。在Stats窗口中，当“Saved by batching“值大于零时就表示批处理已经生效。但不幸的是，要想知道批处理为何不生效却比较困难，虽然Unity手册提供了一些可能的原因，但这些信息需要用户已经了解相关的基础知识。

<ignore_js_op>

好消息是，Unity 5.6的Frame Debugger中加入了一个新的功能，用于告知我们Unity发起新的批处理的原因。

Frame Debugger是Unity 5.x推出的新功能，依次点击菜单项Window > Frame Debugger可以打开Frame Debugger窗口。该窗口显示游戏中所有的批处理，以及这些批处理所有的细节信息，包括着色器、纹理及批处理所用的大量设置信息等。

在详细介绍Unity何时发起新的批处理之前，先来了解批处理的概念及其作用。

<ignore_js_op>

Unity 5.6中的Frame Debugger现解释了Unity发起新批处理的原因。

何为批处理（Batch）

Unity为了在屏幕上绘制游戏对象，它需要向图形API发起一次“绘制”命令。该过程其实就是一次“Draw Call”。但在发起命令之前，Unity还需要为绘制的对象设置所需的GPU状态：网格、着色器、纹理、混合设置以及一些其他的着色器属性。而状态改变命令再加上一个或多个绘制命令就称为一次批处理。

批处理过程（Batching）

导致批处理缓慢的原因就是改变GPU状态的命令，而绘制命令实际上仅占用很少的资源。所以Unity总是试图利用同一个GPU状态同时渲染多个对象。这一过程被称为批处理。

Unity提供三种类型的批处理：静态批处理，动态批处理以及GPU Instancing。

• 静态批处理会在构建时将多个静态网格对象合并为一个或多个大的网格对象，然后在运行时一次批处理渲染一个大网格中的多个对象。
• 动态批处理在每帧中获取多个小型网格对象，在CPU中对其进行顶点变换，将相似的顶点组合到一起，然后一次性绘制它们。
• GPU Instancing（Unity 5.4中引入）可以利用少量Draw Call绘制多个具有不同的位置、旋转以及其他着色器属性的相同对象。

导致批处理失败的原因

有时在编辑器中可以清楚地看到，一些本应被批处理的对象出于某些原因没有被批处理。首先，请检查Player Settings中是否启用批处理功能。这个步骤看似多余，但我们遇到太多的失败案例都是因为忘记开启该功能。

我们专门为此提供了示例工程，用来演示Unity在什么情况下必须发起新的批处理请求。首先下载该工程并导入Unity项目。请注意，您需要使用Unity 5.6才能看到Frame Debugger中关于批处理状态的说明。

以下是示例工程（Unity 5.6）中导致无法进行批处理的原因。每个原因对应一次单独的批处理。

• Additional Vertex Streams — 对象使用MeshRenderer.additionalVertexStreams设置了额外的顶点信息流。
• Deferred Objects on Different Lighting Layers — 该对象位于另一不同的光照层中。
• Deferred Objects Split by Shadow Distance — 两个物体中有一个在阴影距离范围内而另一个不是。
• Different Combined Meshes — 该对象属于另一个已合并的静态网格。
• Different Custom Properties — 该对象设置了不同的MaterialProperyBlock。
• Different Lights — 该对象受不同的前向光照（Forward Light）影响。
• Different Materials — 该对象使用不同的材质。
• Different Reflection Probes — 该对象受不同的反射探头（Reflection Probe）影响。
• Different Shadow Caster Hash — 该对象使用其他的阴影投射着色器，或是设置了不同的着色器参数/关键字，而这些参数/关键字会影响阴影投射Pass的输出。
• Different Shadow Receiving Settings — 该对象设置了不同的“Receive Shadows”参数，或是一些对象在阴影距离内，而另一些在距离之外。
• Different Static Batching Flags — 该对象使用不同的静态批处理设置。
• Dynamic Batching Disabled to Avoid Z-Fighting — Player Settings中关闭了动态批处理，或在当前环境中为避免深度冲突而被临时关闭。
• Instancing Different Geometries — 使用GPU Instancing渲染不同的网格或子网格。
• Lightmapped Objects — 对象使用了不同的光照贴图，或在相同的光照贴图中有不同的光照贴图UV转换关系。
• Lightprobe Affected Objects — 对象受其他光照探头（Light Probe）影响。
• Mixed Sided Mode Shadow Casters — 对象的“Cast Shadows”设置不同。
• Multipass — 对象使用了带多个Pass的着色器。
• Multiple Forward Lights — 该对象受多个前向光渲染影响。
• Non-instanceable Property Set — 为instanced着色器设置来non-instanced属性。
• Odd Negative Scaling — 该对象的缩放存在某个奇数为负值，例如(1,-1,1)。
• Shader Disables Batching — 着色器使用“DisableBatching”标签显式关闭了批处理。
• Too Many Indices in Dynamic Batch — 动态批处理索引过多（超过32k）。
• Too Many Indices in Static Batch — 静态批处理中的组合网格索引过多。对于OpenGL ES来说是48k，OSX是32k，其他平台是64k。
• Too Many Vertex Attributes for Dynamic Batching — 欲进行动态批处理的子网格拥有超过900个顶点属性。
• Too Many Vertices for Dynamic Batching — 欲进行动态批处理的子网格顶点数量超过300个。

结论
现在可以开始使用Frame Debugger新功能来检查工程了，帮助您找到可以进行批处理的内容。随着引擎的不断更新，将来可能会添加更多导致批处理失败的原因，请关注我们在Github上的项目。