Deferred Rendering（二）G-Buffer的组织

先来看一张网上广为流传的《杀戮地带2》典型的Deferred Shading的G-Buffer组织：

这里补充解释下几个点：

• 不存Position，而由depth和屏幕像素坐标反推出来。参考：http://www.derschmale.com/2014/01/26/reconstructing-positions-from-the-depth-buffer/
• Normal可以只存两个分量，算法多种多样，float16 精度足矣。参考：http://aras-p.info/texts/CompactNormalStorage.html
• depth其实无需占用RT保存，dx9下的解决方法是depth texture：depth buffer重定向到纹理输入。

G-Buffer还是太臃肿了：

• MRT技术是有，但不代表其优。无论是AMD，还是NVida的优化文档上都说了要尽量避免MRT这回事
• 复杂的渲染方案必须需要对应着一大堆参数要塞进MRT中
• 如果引擎中的物件渲染风格不一样（比如RGame），必定需要额外的空间来存储类似MaterialID这样的东西，灵活性不够

因此Deferred Lighting的思想被提了出来:

• 对比deferred shading ： deferred shading 是将所有的shading都移到deferred 阶段进行
• deferred lighting的本质：deferred lighting的deferred阶段只进行lighting计算，从而和材质无关。
• 最大好处：节省带宽。
• 现在的G-Buffer：normal--保存两个float16分量；position--由深度重建而深度保存在depth texture所以这里不占用G-Buffer；specular factor。只需要一张RT足矣。
• lighting pass的输出： 累积的diffuse + 累计的specular 亮度（只能牺牲掉specular的颜色了）
• 遗憾：最终的着色还是需要额外的pass，前一篇提到的“屏幕空间的、与几何体复杂度无关的O( m + n) 的计算优势”只能运用到lighting计算上。

总结：

• Deferred shading ： 伴随着MRT有巨大的带宽消耗，灵活性也不佳，发展前途不大；
• Deferred lighting ： 虽然只有光照计算是屏幕空间的，且相对Deferred shading每个物体多了1个pass；但节省带宽且相当灵活，目前是各大引擎的上上选。