先来看一张网上广为流传的《杀戮地带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。但节省带宽且相当灵活,眼下是各大引擎的上上选。
时间: 2024-10-14 08:57:35