Deferred RenderingG-Buffer的组织

Posted 2020-09-27 wzzkaifa

先来看一张网上广为流传的《杀戮地带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。但节省带宽且相当灵活，眼下是各大引擎的上上选。