Unity的合批处理_unity动态合批的开销

一、Player Setting里的功能选项

• Static Batching：静态合批
• Dynamic Batching:动态合批

二、静态合批：

将标明为Static的静态物件，如果在使用相同材质球的条件下，Unity会自动帮你把两个物件合并成一个Batch，送往GPU来处理。这功能对效能上非常有帮助，所以需要付费才能使用

三、动态合批：

1、定义

是物件小于300面的条件下（不论物件是否为静态或动态），在使用相同材质球下，Unity就会自动帮你合并成一个Batch送往GPU处理。
（移动的游戏对象共享相同的材质并满足其他条件，则unity可自动在同一绘制调用中批处理这些游戏对象。动态批处理是自动完成的，无需进行任何额外工作）

2、条件

• 批处理动态游戏对象在每个顶点都有一定的开销，因此批处理仅会应用与总共包含上虞900个顶点属性的网格。
• 如果着色使用顶点位置、法线和单个UV，最多可以批处理300个顶点，而如果着色器使用顶点位置、法线、UV0、UV1和切线，则只能批处理180个顶点。（将来可能会更改属性数量限制）
• 如果游戏对象在变换中包含镜像，则不会对这些对象进行批处理（例如，具有+1缩放的游戏对象a和具有-1缩放的游戏对象b无法一起接受批处理）
• 即使游戏对象基本相同，使用不同的材质实例也会导致对象不能一起接受批处理。例外情况是阴影投射物渲染。
• 带有光照贴图的游戏对象具有其他渲染参数：光照贴图索引和光照贴图偏移、缩放。通常，动态光照贴图的游戏对象应指向要批处理的完全相同的光照贴图位置。
• 多pass着色会中断批处理
• 几乎所有的Unity着色都支持前向渲染中的多个光照，有效地为它们执行额外的pass，“其他每像素光照”的绘制调用不进行批处理
• 旧版延迟（光照pre-pass）渲染路径会禁用动态批处理，因为它必须绘制两次游戏对象
• 因为动态批处理的工作原理是将所有游戏对象顶点转换到CPU上的世界空间，所以仅在该工作小于进行绘制调用的情况下，才有优势。绘制调用的资源需求取决于许多因素，主要是使用的图形API。例如，对于游戏主机或注入Apple Metal 之类的现代api，绘制调用的开销通常会低很多，通常动态批处理根本没有优势。