Unity 2017 Game Optimization 读书笔记 The Benefits of Batching

batching（合批）和大量的描述一个3D物体的数据有关系，比如meshes，verices，edges，UV coordinates 以及其他不同类型的数据。在Unity中谈论batching，指的是用于合批mesh数据的两个东西：Dynamic Batching（动态合批）和 Static Batching（静态合批）。渲染管线特别喜欢处理合在一起提交的mesh数据而不是单独的一个个的mesh数据。

Draw Calls

在讨论Dynamic Batching（动态合批）和 Static Batching（静态合批）之前，先理解下Dynamic Batching（动态合批）和 Static Batching（静态合批）要解决渲染管线的问题：降低用于绘制当前视图所有物体的Draw calls。

Draw call是从CPU发送到GPU的一个请求，用于物体的绘制。在Draw call请求之前，需要完成一系列的准备工作。

首先，mesh和textrue数据必须从CPU 的内存（RAM）推送到GPU内存（VRAM），对于已经存在于场景里的，这通常发生在场景初始化的时候。对于预先没有在场景内的，只能在它们被instantiate的时候进行该操作。其次，cpu必须为gpu准备渲染所需要的设置和数据。cpu和gpu之间的通信是通过不同平台的图形API来完成的，有可能是DirectX，OpenGL，Vulkan等等。

API通过驱动程序调用，大量繁杂的渲染管线渲染物体所需的设置信息通常被叫做Render State。在Render State改变之前，GPU都将会一直使用这个Render State来渲染物体。对Render State做改变是一个开销非常大的过程，比如我们设置Render State使用一张蓝色texture去渲染mesh，这会将整个mesh渲染成蓝色，我们可以再渲染9个完全不同的mesh，它们都会被渲染成蓝色，因为我们没有改变使用的texture。但是如果我们想渲染10个mesh哟个10张不同的贴图，就会十分耗时，因为需要渲染每个mesh时都去准备新的贴图信息发送draw call。越少更改Render State，图形api处理我们的请求就会越快。

能触发Render State同步的操作包括但不限于：添加实时的texture到GPU，修改Shader，修改灯光信息，修改阴影和透明度等等有关渲染的设置。

CPU和GPU之前通过Command Buffer保持通信，这个队列存储了CPU创建好的用于渲染的操作指令，GPU在每次完成渲染指令后再从这个队列中获取。

一个新的Draw Call并不意味着必须有一个新的Render State。合批能够提供渲染性能的原因是如果俩个物体使用同样的RenderState信息来渲染，GPU就可以立刻渲染下一个物体，这消除了Render State的同步时间，合批同样可以减少渲染的指令数量，减少CPU和GPU的负荷。

Materials and Shaders

Unity中通过Materials来把Render State暴露给我们。Materials是一个Shader的容器，shader本身并不感知实际的Render State，shader所需的diffuse textures，normal maps等实际就是隐式的Render State变量。

每一个shader都需要一个Material，一个Material也必须有一个Shader。因此如果我们想减少Render State的变化，我们可以通过减少场景中Materials的数量。CPU每帧会消耗更少的时间来生成和传输渲染指令，GPU也不需要频繁停下来重新同步Render State的变化。

做个实验，四个cube，四个sphere，各自不同的material，关掉shadow，关掉dynamic batching 和 static batching：

结果为9个batches（还有一个是背景，比如天空盒）

像之前介绍的那样，我们可以减少material数量来提高效率，如果都用同样的material会是什么效果：依然还是9个，这是因为我们没开启Dynamic Batching，渲染管线并不能够意识到需要重复使用Render State。

The Frame Debugger

Unity中调试渲染非常有用的工具，可以查看每一帧的渲染过程，对于跟踪场景中DrawCall来源，优化游戏非常有用。这一小节就不详细介绍了

Dynamic Batching

三个特性：

1. 运行中实时动态合批

2. 根据主摄像机视野中可见的物体，每一帧合批的内容都可以不同

3. 运动的物体也可以进行合批

上一小节的例子，开启动态合批后结果为：6个batches，这是因为4个Sphere因为不满足动态合批条件而没有进行合批。

动态合批的条件具体参考Unity的文档，这玩意随着Unity版本的变化不断在变化。

https://docs.unity3d.com/Manual/DrawCallBatching.html

动态合批需要满足的条件：

使用相同的材质引用
只有ParticleSystem和MeshRender可以合批，SkinnedMeshRender等其他Component无法合批.Currently, only Mesh Renderers, Trail Renderers, Line Renderers, Particle Systems and Sprite Renderers are batched. This means that skinned Meshes, Cloth, and other types of rendering components are not batched.
每个mesh最多300个顶点索引。
最多900个顶点属性。
mesh的Scale要么都统一，要么都别统一（这句没看懂，令人费解）
材质的shader不能使用多passes
mesh不能接收实时阴影
合批后mesh总共的索引数不能超过各自平台的上限，一般是32k-64k个。

Vertex attributes

顶点属性是每个顶点的一系列信息，比如位置，法线，UV等。如果每个顶点3个属性，则如果想合批，可以最多支持的顶点数是900/3 = 300。如果每个顶点5个属性，则最多可以持的顶点数是900/5 = 180。要注意的是即使顶点属性少于3个，合批最多也只能支持300个顶点（另外一条规则）

Mesh scaling

奇数个负数Scale不能合批，比如（1,-1,1）,偶数个可以（1，-1，-1）

Dynamic Batching summary

适用于场景中含有大量简单的物体，比如大片有石头和树木的森林等。
如果只是单纯的texture不同，可以考虑使用图集的方式，这样就可以合批。
如果场景中有很多个比较简单的物体，但是只有少数可以合批的话，还不如不开启合批，因为遍历场景判断合批的操作可能更费。
动态合批的条件非常苛刻，经常会出现打破了合批规则而自己不知道，所以要多注意，要经常不定期的去调试check来保持Draw call的合理值，当然，常常的状况是我们直到Draw Call真的成为性能瓶颈影响表现时，并不需要去考虑Draw call。
最后一条建议，多尝试，看看哪些不能合批哪些能合批来保证Draw call

Static Batching

Unity 提供了第二种合批方式，那就是Static Batching。Static Batching的条件：

物体必须被标记为Static
需要额外的内存
合批后mesh总共的索引数不能超过各自平台的上限，一般是32k-64k个。
mesh可以不同，但是必须使用相同的材质引用

The Static flag

要小心如果只是把物体标记为Batching Static，运行时可能会产生奇怪的现象：mesh由于Static Batching没有移动，但是Rigidbody什么的可能会动。

Memory requirements

额外的内存开销是Static Batching的一个缺点，Static Batching copy 需要合批的mesh的数据到一个单独的大mesh buffer中，并将其传入渲染管线中通过一个Draw Call进行渲染，完全忽略掉原始的mesh。如果需要合批的mesh都是不同的，那是否使用静态合批内存的开销是一样的。然而如果渲染的是相同的object，则内存开销会翻倍，平常渲染一个，10个或者100万个同样object的clone花费的内存开销是一样的，因为他们引用的是相同的mesh 数据，对于每个Object唯一不同的只是transform。然而Static Batching 需要copy mesh 数据到大的buffer中，这种引用关系就没有了，每个物体都会将原始的mesh数据copy到buffer中。因此使用Static Batching 渲染1000个tree的内存开销是不使用Static Batching的1000倍，所以在使用Static Batching时要慎重，要判断使用的是否合适。