在Unity3D中的渲染优化-减少需要处理的片元数目

1.控制渲染的顺序

overdraw 指的是同一像素被绘制了多次。为了最大限度地避免overdraw,一个重要的优化策略就是控制渲染的顺序。由于Z-深度测试的存在,如果我们可以保证物体都是从前往后渲染的,那么就可以很大程度上减少overdraw。这时因为,在后面绘制的物体由于无法通过深度测试,因此就不会进行后面的渲染处理。

在Unity中,渲染队列数目小于2500的对象都被认为是不透明的物体(如“Background”,“Geometry”,“AlphaTest”),这些物体是从前往后绘制的,而使用其他的队列(如“Transparent”,“Overlay”)的物体则是从后往前绘制的。这意味着,我们可以尽可能地把物体的队列设置为不透明物体的渲染队列,而尽量避免使用半透明队列。

2.注意GUI中的透明对象

对于半透对象来说,由于它们没有开启深度写入,因此,如果要得到正确的渲染效果,就必须从后往前渲染。这意味着,半透明物体几乎一定会造成overdraw。对于GUI对象来说,它们大多数被设置成了半透明的,如果屏幕中GUI占据的比例太多,而主摄像机又没有进行调整而投影整个屏幕,那么GUI就会造成大量overdraw。

对于GUI的这种情况,我们可以尽量减少窗口中GUI所占的面积。如果实在无能为力,我们可以把GUI的绘制和三维场景中的绘制交给不同的摄像机,而其中负责三维场景的摄像机的视角范围不要和GUI的相互重叠。

在移动平台上,透明度测试也会影响游戏性能。虽然透明度测试没有关闭深度写入,但由于它的实现使用了discard或clip操作,而这些操作会导致一些硬件的优化策略失效。这时使用透明度混合要比使用透明度测试要好。

3.减少实时光照和阴影

对于移动平台来说,实时光照是一个非常消耗性能的效果。如果场景中包含了过多的点光源,并且使用了多个Pass的Shader,那么很有可能会造成性能下降。例如,一个场景里如果包含了三个逐像素的点光源,而且使用了逐像素的Shader,那么很有可能将draw call(CPU)的数目提高3倍,同时会增加overdraw(GPU)。这是因为,对于逐像素的光源来说,被这些光源照亮的物体需要再被渲染一次。更糟糕的是,无论是静态批处理还是动态批处理,对于这种额外的处理逐像素光源的Pass都无法进行批处理,换句话说,它们会中断批处理。

很多成功的手游,它们的画面看起来包含了很多光源,但其实这些游戏往往使用了光照烘焙技术,把光照提前烘焙到一张光照贴图纹理(lightmap)中,然后在运行时只需要根据纹理采样得到光照结果即可。

实时阴影同样是一个非常消耗性能的效果。不仅CPU需要提交更多的draw call,GPU也需要进行更多的处理。因此,我们应该尽量减少实时阴影的使用。例如,可以是使用光照烘焙技术把静态物体的阴影信息存储到光照贴图纹理中,而只对场景中的动态物体使用适当的实时阴影。

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注