Forward Rendering vs. Deferred Rendering

原文：http://gamedevelopment.tutsplus.com/articles/forward-rendering-vs-deferred-rendering--gamedev-12342

如果你的3D游戏开发人员，应该面临过一个选择：采用正向渲染还是延迟。通常情况下得二选一进行使用。那什么叫正想渲染以及延迟渲染？以及他们的差别？你应该怎么选择呢？

现代图形管线

开始前，我们得理解一下有关现代的，或者说可编程管线的一些知识。

以前，我们受限于固定管线，除了可以发送不同的纹理，我们不能改变每个像素的绘制方式，当顶点被送进显卡之后，也不能再进行改变了。但现在的可编程管线，我们可以将代码发送给显卡，从而我们自行决定每个像素的绘制方式。如使用法线贴图，以及根据需求去做不同的事。

而代码就是通过几何，顶点，以及片段着色器的形式传给显卡，显卡按照这些代码去渲染你的物体。

正向渲染

正向渲染是大多数主流引擎采用的技术。你提供想要几何形状，引擎将其拆分成顶点，然后顶点被变换以及裁剪，装进片元，或者像素进行处理，最后渲染至屏幕。这是一个非常线性的过程，每个几何体，挨个的被管线处理，生成最后的图像。

延迟渲染

顾名思义，渲染延迟到所有的几何体都被传递到管线，然后着色，产生最终图像。

为什么这么做呢？

光照效率

光照是最主要的原因。在正向渲染管线中，必须要对可视范围内的所有顶点和片段，进行每个光源的计算。

如果你的场景中有100个几何体，每个几何体有1000个顶点，那就会产生大约100000个多边形。显卡可以很容易的接收他们，但当这些多边形被送进片断着色器，进行复杂的光照计算，那可能就会让你的程序变慢了。

开发者就试图尽可能的将光照计算放入顶点着色器，从而减少片段着色器的工作。复杂的光照计算必须在每个可视的片元中进行，无论这个片元是否重合或者被其他多边形的片段所遮住。如果你的屏幕分辨率是1024*768，就奖金由800000个像素需要着色，每一帧轻易的就能达到百万计的片元处理。但是，这其中的很多片段在经过光照计算后却因为在深度测试没有通过被移除掉，白算了。

正向渲染的时间复杂度可以表示为O（几何体片元数量 * 光源数量），显然几何体的数量和光源的数量决定了这个时间复杂度。

没有被深度测试剔除掉的片断就成了潜在的可能被渲染到屏幕上的像素。

现在一些引擎会针对这个问题进行优化，比如剔除过远的灯光，合并灯光，或者使用光照贴图（特别广泛的静态光照解决方案）。但是，如果你需要动态的，大量的灯光系统，就需要一个更好的解决方案。

延迟渲染带来的提升

延迟渲染是一个很有趣的方法，减少了对象数量，特别是总的片段数量。用屏幕分辨率大小去替代总的片段数量。

延迟渲染的计算复杂度可以表示为;O（屏幕分辨率 * 灯源数量)

于是光照计算就与有多少物体就无关了，效率只与你用了多少灯有关。于是就可以开心的增加我们灯的数量（注意，并不是说可以无节制的增加物体，因为他们仍然要被渲染到缓冲区中以便进行后续的计算）

让我们看一下光照渲染是如何工作的：

每个几何体都要被渲染，但并不进行光照着色。通过设置多个渲染目标，渲染至不同的屏幕空间缓存中。具体的，深度，法线，颜色会被分开写入到缓存中。然后这些缓冲期进行组合，为每个光提供足够的信息，去照亮像素。

通这些缓存信息，我们就能将这个像素在某个光照下的颜色计算出来。

选择哪种渲染方式呢？

简单回答就是，如果有很多动态光源，那就选延时渲染。但是，也有一些问题：

*这个方案需要显卡支持多个渲染目标，老的显卡不支持。

*需要很大的带宽。因为要传送庞大的缓存信息，老的显卡可能会不支持。

*不支持透明物体（除非结合使用正向渲染用来专门处理那些透明物体）

*没有抗锯齿。有些引擎会通过别的方案解决这个问题：比如边缘检测，FXAA