Unity 绘图性能优化 - Draw Call Batching

Unity 绘图性能优化 - Draw Call Batching

 

Unity官方连接：http://docs.unity3d.com/Manual/DrawCallBatching.html

转载请注明本文连接：http://www.cnblogs.com/fly-100/p/5422734.html

Draw Call Batching

在屏幕上绘制一个物体，U3D引擎必须向绘图API（openGL或者D3D）发起一次DrawCall。这些DrawCall每每是昂贵的，当绘图API为每一个DrawCall作一些重要的事情，引发GPU的性能消耗较高。
这些消耗大部分是由于DrawCall结束的状态切换引发的（好比，从一个材质切换到另外一个材质），由于这会引起昂贵显卡驱动的验证和变换步骤。

Unity使用多种技术来解决这个问题：

• 静态Batching：把静态的物体合并成一个大meshes，而后用更快的方法渲染他们。
• 动态Batching：对于足够小的meshesh，变换他们的顶点在CPU上，将一些类似的组合到一块儿，在一个go中绘制。

内建的Baching相对于手动合并物体到一块儿有几个好处（值得注意的是，这些对象仍能够被单独销毁）。
可是他也有它的缺点（静态Batching会致使内存和存储的开销，动态Batching会致使CPU开销）。

 

Material Setup For Batching

只有共享同一个材质的物体才能被Batched在一块儿。若是，你想达到一个好的batching，你须要竟可能多的在不一样物体中共享材质。

若是你有两个一样的材质可是他们的textures不一样，你能够合并这些textures到一个大texture - 这个过程常常被叫作texture atlasing。一旦textures在同一个图集中，你就可使用一个材质来代替了。 

若是你须要在脚本中访问共享了的材质，有一个很重的点须要注意：修改Renderer.material属性会建立一个当前材质的副本。因此，做为替换方案，你应该使用Rednerer.sharedMaterial以保证材质被共享。

当渲染阴影投射的时候，即便他们的材质是不一样的，也常常被batched到一块儿。只要材质中的数值在shadow pass是相同的，即便阴影投射有不一样的材质，他们也可使用动态batching。举个例子，许多箱可使用具备不一样的texture的材质，但对于阴影投射渲染 texture是不相关 - 在这种状况下，他们能够被batched到在一块儿。

 

Dynamic Batching

Unity能够自动batch移动物体到相同的draw call，若是它们具备相同的材质和知足其它标准。动态Batching是自动完成的，不须要你作额外的事情。

• Batching 动态的物体每一个顶点会有某些开销，因此batching只适用于定点数小于900的meshes。
  • 若是你得shader使用了顶点位置，法线和单独的UV，那么你能够batch 300 个顶点;若是你得shader使用了顶点位置，法线，UV0，UV1，和正切，只能batch 180个顶点。
  • 这个限制的数量未来有可能会变化。
• 若是物体包含镜像变换，他们将不会被batched，例如，object A 的scale 为 +1 object B 的scale 为-1，就不能batched到一块儿。
• 使用不一样材质的实例，即便他们实质上是相同的，也会致使两个物体不能被batched到一块儿。阴影投射除外。
• 具备光照贴图的对象有额外的渲染参数：光照索引和 偏移/放缩 的光照。因此通常动态lightmapped对象应指向彻底相同的光照贴图位置而后再进行batch。
• 多通道的shader将不会被batching
  • 几乎全部的Unity shader都支持前置渲染几个灯光，有效的为他们作更多的通道。“额外的逐像素的灯光”的draw call 将不会被batched。
  • 传统的延迟渲（逐通道光照）染通道禁用了动态batching，由于它必须绘制两次。

因为它的工做原理是变换全部的物体的顶点到CPU的世界坐标中，因此它仅仅在它的工做（变换到cpu的世界坐标）比作一次“draw call”小的时候才能起到好的做用。究竟一个DrawCall有多昂贵取决于诸多因素，主要是所用的绘图API。例如，在控制台或当前流 
行的APIs 例如Apple Metal DrawCall的开销通常比较低，因此通常动态batching不会达到好的效果。

 

Static Batching

静态batching容许引擎减小draw call适用于任何大小的几何（假设没有移动和共享材质）。大部分状况下他比动态batching更高效 ，可是它会占用更多的内存。

为了使静态batching更好的获益，你须要明确的指定游戏中某些物体是静态的并且不会移动，旋转或者缩放。这样作，你能够在Inspector界面中的“Static”选项（chekbox）标记物体为static：

 

使用静态batching将须要额外的内存来存储合并后的几何信息。若是几个物体在静态batching以前共享同一个几何图元，那么这个几何图元将会为每一个物体复制一份，不管在Editor中仍是runtime中都是如此。这不是一个好方法 - 有时候为了保持更小的内存占用量，你必须牺牲渲染性能为了不一些物体的静态batching。例如，在一个稠密的森林中，标记树木为static会产生严重的内存影响。

在内部，静态batching的原理是变换这些静态物体到世界控件而后为他们创建一个很大顶点+索引 缓冲区。而后全部显示的物体都放到一个batch，一系列“便宜的”draw call就完成了，这期间几乎没有状态切换（state change）。因此 从技术上来说 这并无节省“3D API draw call”，可是他节省了他们之间的状态切换（状态切换才是罪魁祸首）。

 

Other Batching Related Tips

目前，只有网格渲染才被batched。像 skinned meshes，cloth，拖尾渲染器（Trail Renderer）和其余类型的渲染组件是不被batched的。半透明shader为了作透明度的工做，常常须要物体以从后到前的顺序进行渲染。Unity首先会对物体进行排序，而后试着batch他们 - 由于这个顺序是严格限制的，这就意味着 相对于不透明物体来讲，会有不多的batching产生。相对调用draw call来讲，手动合并比较近的物体多是一个很是不错的选择。例如，许多抽屉的静态柜子合并成一个mesh常常是有道理的，不管是在3D建模软件中仍是使用Mesh.CombineMeshaes.