3D渲染引擎着色方式的演化史



Forward rendering

最初始的渲染方式，原理是以mesh为单位进行渲染，在光栅化后，对每个PS进行计算时，根据光照进行着色计算，所以这种方式称为前向着色。弊端：1、如果像素被其他像素遮蔽了，就浪费了宝贵的处理结果；2、光源多起来后管理很麻烦，Shader也不好写。这样，Deferred rendering就应运而生了。

Deferred rendering

这种渲染方式就是在渲染mesh时，并不进行光照计算，而是将深度、法线、Diffuse、Specular等材质属性分别输出到GBuffer里（其实就是几张RT）；然后GBuffer里的深度和法线信息，累加所有光照的强度到一张光照强度RT上；根据GBuffer里的Diffuse和Specular信息，以及光照强度RT，进行着色计算。这种渲染方式的弊端：1、由于硬件限制或者性能限制，GBuffer里保存的材质信息有限，对于特殊材质来说，例如人的皮肤、翡翠等，渲染结果很不好；2、延迟计算光照会大幅增加纹理带宽和帧缓冲区带宽的开销；3、当光源数量很多时，光源会不断对光照强度RT进行累加，也会大幅增加帧缓冲区带宽开销；4、由于硬件限制或者性能限制，不能使用硬件支持的MSAA，只能使用类似后期处理的FXAA或者Temporal AA。为了解决这些问题，很多新的思路就出现了。

Tile-based deferred rendering

        这个方案是对“Deferredrendering”渲染方式里的第三个弊端进行优化的。原理就是，先将整个光照强度RT分成很多个正方形区域，计算每个区域受哪些光源影响，并保存起来；然后以每个区域为单位，在一个批次里累加所有的光照。这样就能减少对光照强度RT上某个像素频繁读写的次数。

Deferred lighting

        这个技术是CryTek这个团队原创的，用于解决“Deferredrendering”渲染方式里的第一个弊端。原理跟“Deferred rendering”差不多，只是有几处不同：1、GBuffer中只有深度和法线数据；2、着色过程不是“Deferred rendering”中类似于后处理的方式，而是渲染mesh。其实也有弊端：1、由于不透明物体在主视口中被渲染了两次，会大幅增加渲染批次，不过好在CE对状态切换管理的非常好，所以渲染批次的承载力很高；2、由于某些特殊材质需要对光照进行特殊处理，比如说树叶的背光面也会有一定的光照，所以这种方式也不太完美（印象里貌似CE对主光，例如太阳光，不累加进光照强度RT，而是着色时单独处理，这样的话效果会提升不少，至少室外场景是完全能够解决问题的；而对于点光源比较多的室内场景，主光着色好看了就会效果很好了，毕竟其他光照的影响占比比较小）。

Hybrid deferred lighting

        为了解决“Deferredlighting”里面的第一个弊端，从CE3的某个版本开始，换成了这种方式。理由是，对于大多数物体来说，“Deferred rendering”的方式就很好了；而对于特殊材质，则使用“Deferred lighting”的方式。这样，既能保持很好的渲染效果，又能避免渲染批次激增。我们团队开发的“盘古引擎”就是借鉴了这种方式。

Forward+

        有时候，你转了很大一个圈以后，发现又回到了原点。好，那这就到了终极方式了——前向着色的改进版。这个方案是ATI发明的，已经应用于Ogre 2.1。UE4正在针对VR研发前向着色，不知道是不是也是这个。原理也很简单，就是先用“Tile-based deferred rendering”里的方式计算好每个区域受哪些光照影响，然后像传统的前向着色一样渲染每个mesh——当然，要去光照列表里查找影响当前区域的所有光照，并着色。这种方式只有上述提到的一个缺点，那就是可能和“Deferred lighting”一样需要渲染两遍场景，不过以后应该会有优化的方案。优点：1、渲染效果好；2、带宽开销低，尤其适用于VR这种每帧需要渲染两遍场景的应用；3、可以使用硬件支持的MSAA，质量最高。