动态合批

引自：关于静态批处理/动态批处理/GPU Instancing /SRP Batcher的详细剖析 - 知乎 (zhihu.com)

原理：在进行场景绘制之前将所有共享同一材质的模型（正在视野中）顶点信息变换到世界空间中，然后通过一次drawcall绘制多个模型，达到合批的目的（感觉就像是实时的静态合批），但由于模型顶点变换的操作是由cpu完成的，所以这会带来一些CPU的性能消耗。并且计算的模型顶点数量不宜太多，否则CPU串行计算耗费的时间太长会造成场景渲染卡顿，所以Dynamic batching只能处理一些小模型。

优化点：Dynamic batching在降低Draw call的同时会导致额外的CPU性能消耗，所以仅仅在合批操作的性能消耗小于不合批，Dynamic batching才会有意义。而且它不只一帧中的计算量，而是在摄像机移动过程中每帧都会进行合并网格的消耗算力，这使得CPU算力消耗太大，相比减少的Drawcall数量，得不偿失。而新一代图形API（ Metal、Vulkan）在批次间的消耗降低了很多，所以在这种情况下使用Dynamic batching很可能不能获得性能提升。

个人觉得如果使用的场景是统一刷新且刷新频率很低（类似地图），完全可以手动调用StaticBatchingUtility.Combine，用一定的内存换取更宽泛的使用条件，还减少了实时运算。

条件：

1.模型顶点数在900以下，如果使用顶点坐标、法线、UV，就只能最多300个顶点，如果使用UV0,UV1和切线，最多150个顶点。

2.模型之间的缩放必须一致。

3.合并网格的材质球驶离必须相同，不能更改材质球参数。

4.如果有lightmap，必须是相同的部分才可以合批。

5.多pass的shader材质不能合批

6.延迟渲染不能合批。

批处理被打断的情况：

1.位置不相邻且中间夹杂着不同材质的其他物体，不会进行批处理，这种情况比较特殊，涉及到批处理的顺序。

2.优先级： 静态批处理 > GPUInstancing > 动态批处理。满足前两项动态批处理会被打断

3.拥有lightmap的物体含有额外（隐藏）的材质属性，比如：lightmap的偏移和缩放系数等。所以，拥有lightmap的物体将不会进行批处理（除非他们指向lightmap的同一部分）。

4.我们知道能够进行合批的前提是多个GameObject共享同一材质，但是对于Shadow casters的渲染是个例外。仅管Shadow casters使用不同的材质，但是只要它们的材质中给Shadow Caster Pass使用的参数是相同的，他们也能够进行Dynamic batching。

5.Unity的Forward Rendering Path中如果一个GameObject接受多个光照会为每一个per-pixel light产生多余的模型提交和绘制，从而附加了多个Pass导致无法合批，我们可以在Quality Settings中将的per-pixel light数量限制为1.