内容引自《Real Time Rendering 3rd》
Forward Rendering（正向渲染）
发生在渲染管线的顶点处理阶段，会计算所有的顶点的光照。全平台支持。
- 规则一：最亮的几个光源会被实现为像素光照
- 规则二：然后最多4个光源会被实现为顶点光照
- 规则三：剩下的光源会被实现为效率较高的球面调谐光照（Spherical Hamanic），这是一种模拟光照
规则一补充说明：
- 最亮的那盏光一定是像素光照
- Light的Render Mode是important的光一定是像素光照
- 如果前面的两条加起来的像素光照小于Quality Setting里的Pixel Light Count（最大像素光照数量），那么从剩下的光源中找出最亮的那几盏光源，实现为像素光照。
- 最后剩下的光源，按照规则2或3。
- 在base pass里执行一盏像素光、所有的顶点光和球面调谐光照，并且进行阴影计算。
- 其余的像素光每盏一个Additional Pass，并且这些pass里没有阴影计算。
- 场景中看到的阴影，全是base pass里计算出最亮那盏像素光的阴影，其他像素光是不计算阴影的。
延迟渲染( Deferred Rendering)
在计算机图形学中，延迟渲染( Deferred Rendering) ，即延迟着色（Deferred Shading），是将着色计算延迟到深度测试之后进行处理的一种渲染方法。延迟着色技术的最大的优势就是将光源的数目和场景中物体的数目在复杂度层面上完全分开，能够在渲染拥有成百上千光源的场景的同时依然保持很高的帧率，给我们渲染拥有大量光源的场景提供了很多可能性。
传统的正向渲染思路是，先进行着色，再进行深度测试。其的主要缺点就是光照计算跟场景复杂度和光源个数有很大关系。假设有n个物体，m个光源，且每个物体受所有光源的影响，那么复杂度就是O(m*n)。
正向渲染简单直接，也很容易实现，但是同时它对程序性能的影响也很大，因为对每一个需要渲染的物体，程序都要对每个光源下每一个需要渲染的片段进行迭代，如果旧的片段完全被一些新的片段覆盖，最终无需显示出来，那么其着色计算花费的时间就完全浪费掉了。
而延迟渲染的提出，就是为了解决上述问题而诞生了（尤其是在场景中存在大量光源的情况下）。
延迟着色给我们优化拥有大量光源的场景提供了很多可能性，因为它能够在渲染拥有成百上千光源的场景的同时还能够保持能让人接受的帧率。
发生在渲染管线的像素处理阶段，会对真正出现在屏幕上的像素进行光照计算。同时，光照计算的复杂度取决于屏幕的大小，而不是场景的复杂度。
延迟渲染主要包含了两个Pass：
- 第一个Pass用于渲染G缓冲，在这个Pass中，不进行光照计算，仅仅计算哪些片元是可见的，如果一个片元是可见的，就把它的相关信息（漫反射颜色、高光反射颜色、法线、自发光和深度等信息）存储到G缓冲区中。对于每一个物体，这个Pass仅会执行一次。
- 第二个Pass用于计算真正的光照模型。该Pass会使用上一个Pass渲染的数据来计算最终的光照颜色，再存储到帧缓冲中。
几何缓冲区 G-buffer
G-Buffer，全称Geometric Buffer ，译作几何缓冲区，它主要用于存储每个像素对应的位置（Position），法线（Normal），漫反射颜色（Diffuse Color）以及其他有用材质参数。根据这些信息，就可以在像空间（二维空间）中对每个像素进行光照处理。
缺点：
- 读写G-buffer的内存带宽用量是性能瓶颈。
- 不支持半透明
- 不支持硬件抗锯齿（anti-aliasing）功能
- 对显卡有一定要求。
需要平台支持
PC（Windows / Mac）需要Shader Model 3.0+支持。
手机（iOS / Android）需要OpenGL ES 3.0，Metal支持
延迟渲染的改进
针对延迟渲染上述提到的缺点，下面简单列举一些降低 Deferred Rendering 存取带宽的改进方案。最简单也是最容易想到的就是将存取的 G-Buffer 数据结构最小化，这也就衍生出了 Light Pre-Pass（即Deferred Lighting） 方法。另一种方式是将多个光照组成一组，然后一起处理，这种方法衍生了 Tile-Based Deferred Rendering。
现在主流的Deferred Rendering的改进是：分块延迟渲染 Tile-BasedDeferred Rendering
分块延迟渲染 Tile-BasedDeferred Rendering
作为传统Defferred Rendering的另一种主要改进，分块延迟渲染（Tile-Based Deferred Rendering，TBDR）旨在合理分摊开销（amortize overhead），自SIGGRAPH 2010上提出以来逐渐为业界所了解。
实验数据表明TBDR在大量光源存在的情况下明显优于上文提到的Light Pre-Pass。
我们知道，延迟渲染的瓶颈在于读写 G-buffer，在大量光源下，具体瓶颈将位于每个光源对 G-buffer的读取及与颜色缓冲区（color buffer）混合。这里的问题是，每个光源，即使它们的影响范围在屏幕空间上有重疉，因为每个光源是在不同的绘制中进行，所以会重复读取G-buffer中相同位置的数据，计算后以相加混合方式写入颜色缓冲。光源越多，内存带宽用量越大。
而分块延迟渲染的主要思想则是把屏幕分拆成一个个小的分块，例如每 32 × 32 像素作为一个分块（tile）。计算每个分块的深度范围（depth range），求得每个 tile 的 包围盒bounding box。然后，计算每个分块的包围盒bounding box会受到哪些光源影响，把那些光源的索引储存在分块的光源列表里。最后，逐个分块进行着色，对每像素读取 G-buffer 和光源列表及相关的光源信息。因此，G-buffer的数据只会被读取1次且仅1次，写入 color buffer也是1次且仅1次，大幅降低内存带宽用量。不过，这种方法需要计算光源会影响哪些分块，这个计算又称为光源剔除（light culling），可以在 CPU 或 GPU（通常以 compute shader 实现）中进行。用GPU计算的好处是，GPU 计算这类工作比 CPU 更快，也减少 CPU／GPU 数据传输。而且，可以计算每个分块的深度范围（depth range），作更有效的剔除。
对比 Deferred Rendering，之前是对每个光源求取其作用区域 light volume，然后决定其作用的的 pixel，也就是说每个光源要求取一次。而使用 TBDR，只要遍历每个 pixel，让其所属 tile 与光线求交，来计算作用其上的 light，并利用 G-Buffer 进行 Shading。一方面这样做减少 了所需考虑的光源个数，另一方面与传统的 Deferred Rendering 相比，减少了存取的带宽。
