Unity_Shader高级篇_16_Unity Shader入门精要_减少需要处理的片元数目

16.6 减少需要处理的片元数目
另一个造成GPU瓶颈的是需要处理过多的片元。这部分优化的重点在于减少overdraw。简单来说，overdraw指的就是同一个像素被绘制了多次。
Unity还提供了查看overdraw的视图，我们可以在Scene视图左上方的下拉菜单中选中Overdraw即可。实际上，这里的视图只是提供了查看物体相互遮挡的层数，并不是真正的最终屏幕绘制的overdraw。也就是说，可以理解为它显示的是，如果没有使用任何深度测试和其他优化策略时的overdraw。这种视图是通过把所有对象都渲染成一个透明的轮廓，通过查看透明颜色的累计程度，来判断物体之间的遮挡。当然，我们可以使用一些措施来防止这种最坏情况的出现。

16.6.1 控制绘制顺序
为了最大限度地避免overdraw，一个重要的优化策略就是控制绘制顺序。由于深度测试的存在，如果我们可以保证物体都是从前往后绘制的，那么就可以很大程度上减少overdraw。这是因为，在后面绘制的物体由于无法通过深度测试，因此，就不会再进行后面的渲染处理。
在Unity中，那些渲染队列数目小于2500（如“Background”“Geometry”和“AlphaTest”）的对象都被认为是不透明（opaque）的物体，这些物体总体上是从前往后绘制的，而使用其他的队列（如“Transparent”“Overlay”等）的物体，则是从后往前绘制的。这意味着，我们可以尽可能地把物体的队列设置为不透明物体的渲染队列，而尽量避免使用半透明队列。
而且，我们还可以充分利用Unity的渲染队列来控制绘制顺序。例如，在第一人称射击游戏中，对于游戏中的主要人物角色来说，他们使用的shader往往比较复杂，但是，由于它们通常会挡住屏幕的很大一部分区域，因此我们可以先绘制它们（使用更小的渲染队列）。而对于一些敌方角色，它们通常会出现在各种掩体后面，因此，我们可以在所有常规的不透明物体后面渲染它们（使用更大的渲染队列）。而对于天空盒子来说，它几乎覆盖了所以的像素，而且我们知道它永远会出现在所有物体的后面，因此，它的队列可以设置为“Geometry+1”。这样，就可以保证不会因为它而造成overdraw。
这些排序的思想往往可以节省很多渲染时间。
16.6.2 时刻警惕透明物体
对于半透明对象来说，由于它们没有开启深度写入，因此，如果要得到正确的渲染效果，就必须从后往前渲染。这意味着，半透明物体几乎一定会造成ovedraw。如果我们不注意一点，在一些机器上可能会造成严重的性能下降。例如；对于GUI对象来说，它们大多被设置成了半透明，如果屏幕中GUI占据的比例太多，而主摄像机又没有进行调整而是投影整个屏幕，那么GUI就会造成大量overdraw。
因此，如果场景中包含了大面积的半透明，或者有很多层相互覆盖的半透明对象（即便他们每个的面积可能都不大），或者是透明的粒子效果，在移动设备上也会造成大量的overdraw。这是应该尽量避免的。
对于上述GUI的这种情况，我们可以尽量减少窗口中GUI所占的面积。如果实在无能为力，我们可以把GUI的绘制和三维场景的绘制交给不同的摄像机，而其中负责负责三维场景的摄像机的视角范围尽量不要和GUI的相互重叠。当然，这样会对游戏的美观度产生一定迎影响，因此，我们可以在代码中对机器的性能进行判断，例如，首先关闭一些硬耗费性能的功能，如果发现这个机器表现非常良好，再尝试开启一些特效功能。
在移动平台上，透明图测试也会影响游戏性能。虽然透明度测试没有关闭深度测试，但由于它的实现使用了discard或clip操作，而这些操作会导致一些硬件的优化策略失效。例如，我们之间讲过PowerVR使用的基于瓦片的延迟渲染技术，为了减少overdraw它会在调用片元着色器前就判断哪些瓦片被真正渲染的。但是，由于透明度测试在片元着色器中使用了discard函数改变了片元是否会被渲染的结果，因此，GPU就无法使用上述的优化策略了。也就是说，只要在执行了所有的片元着色器或，GPU才知道那些片元会被真正渲染到屏幕上，这样，原先那些可以减少overdraw的优化就都无效了。这种时候，使用透明度混合的性能往往比使用透明度测试更好。
16.6.3 减少实时光照和阴影
实时光照对于移动平台是一种非常昂贵的操作。如果场景中包含了过多的点光源，并且使用了多个Pass的Shader，那么很有可能会造成性能下降。例如，一个场景里如果包含了三个逐像素的点光源，而且使用了逐像素的Shader，那么很有可能将draw call数目（CPU的瓶颈）提高三倍，同时也会增加overdraw（GPU的瓶颈）。这是因为，对于逐像素的光源来说，被这些光源照亮的物体需要被再渲染一次。跟糟糕的是，无论是静态批处理还是动态批处理，对于这种额外的处理逐像素光源的Pass都无法进行批处理，也就是说，他们会中断批处理。
当然，游戏场景还是需要光照才能的到出色的画面效果。我们看到很多成功的移动平台的游戏，他们的画面效果看起来好像包含了很多光源，但其实都是骗人的。这些游戏往往使用了烘焙技术，把光照提前烘焙到一张光照纹理（lightmap）中，然后在运行时刻只需要根据纹理采样得到光照结果即可。另一个模拟光源的方法师使用God Ray。场景中很多小型光源的效果都是靠这种方法模拟的。它们一般并不是真的光源，很多情况是通过透明纹理得到的。在移动平台上，一个物体使用的逐像素光源数目应该小于1（不包括平行光）。如果一定要使用更多的实时光，可以选择用逐顶点光照来代替。
在游戏《ShadowGun》中，游戏角色看起来使用了非常复杂高级的光照计算，但这实际上是优化后的结果。开发者们把复杂的光照计算存储到一张查找纹理（lookup texture ，也被称为查找表，lookup table， LUT）中。然后在运行时刻，我们只需要使用光源方向、视角方向、法线方向等参数，对LUT采样得到光照结果即可。使用这样的查找纹理。不仅可以让我们使用更出色的光照模型，例如，更加复杂的BRDF模型，还可以利用查找纹理的大小来进一步优化性能，例如，主角角色可以使用更大分辨率的LUT，而一些NPC就使用较小的LUT。
实时阴影同样是一个非常耗性能的效果。不仅是CPU需要提交更多的draw call，GPU也需要进行更多的处理。因此，我们应该尽量减少实时阴影，例如，使用烘焙把静态物体的阴影信息存储到光照纹理中，而只对场景中的动态物体使用的实时阴影。