延迟渲染及材质ID.doc

延迟渲染及材质ID
技术背景
最近太懒了,打LOL,RM这一块都荒废了下来,关于延迟渲染的RM工程其实个把月前写好的,杂务所扰,一直没有静下心来整理,现在正值年关,终于可以继续了,努力在接下来的几周把接下来的Monkey计划完成。
关于延迟渲染技术,在现阶段的游戏程序中正被越来越推广使用,从PS3,Xbox360的次时代,到暴雪的星际2,及最近效果完全征服我的战地3,无一例外的使用了延迟渲染DeferredShadin(以下简称DS,DeferredLighting,DL技术暂不在这里讨论)。
那么传说中的强大延迟渲染技术到底有何强大之处呢?!
其实,理论早在几十年前就已经提出,实现也不难,真正的优势,要从传统的前向渲染(ForwardShading,FS)说起,下面引用一段介绍:
“
在TabulaRasa中,我们一开始的渲染引擎是基于最初的DX9而完成的传统前向渲染技术(FS)的,使用了HLSL和D3DXEffect。我们的Effect使用了Pass里的Annotation来描述这个Pass所支持的光照。而在CPU这边,引擎可以算出来每个几何体被那些光源所影响——这个信息连同那些在Pass的Annotation里的信息一起,用于设置光源的参数、以及确定每个Pass该调用多少次。
这种前向着色有多种问题:
1,计算每个几何体受那些光影响耗费了CPU的时间,更坏的是,这是个O(n*m)的操作。
2,Shader经常需要超过一次以上的Pass来渲染光照,渲染n个灯光,对于复杂的Shader,可能需要O(n)次运算。
3,增加新的光照模型和新的光源类型,可能需要改变所有Effect的源文件。
4,Shader很快就将达到或者超出SM2的指令限制。
在MMO里,我们对游戏环境很少会有过于苛求的要求。我们无法控制同屏可见的玩家数量、无法控制同屏会有多少特效和光源。由于传统前向渲染缺乏对环境的控制,且对于光源的复杂度难于估量,因此我们选择了延期着色。这可以让我们的画面更接近于当今顶尖的游戏引擎,并且让光照所耗费的资源独立于场景的几何复杂度。
延期着色提供了下面的好处:
1,光照所耗费的资源独立于场景复杂度,这样就不用再费尽心机去想着处理那些光源影响几何体了。
2,不必要再为几何体的受光提供附加的Pass了,这样就节省了DrawCall和状态切换的数量。
3,在增加新的光源类型和光照模型时,材质的Shader不需要做出任何改变。
4,材质Shader不产生光照,这样就节省了计算额外的几何体的指令数。
”
         简单的说,DS最大优势便是在如今渲染模块中PixelShader变得越来越复杂的情况下,能最大限度地节约硬件效能。
实现原理
延迟渲染管线可分为俩个阶段:Geometry,Lighting,当然如将GeometryBuffer中的丰富的信息仅仅用于光照点亮过程显而易见不是俺们程序猿“雁过拔毛”的性格,所以通常各种Post-processing也会被被我们加入管线之中,这里且不做深入。
鄙人很懒,相比码字,更喜欢用代码说话,所以这里就杂糅一些别人的著说,后面再一一提名感谢,嘿嘿~~~
Geometry阶段:将本帧所有的几何信息(位置,法线,贴图)光栅化到G-buffer
Lighting阶段:以G-buffer作为输入(位置,法线)进行逐像素的光照计算,得到渲染结果。
DS整体渲染过程并不复杂,但问题往往出在细节,下面先一一列举各个步骤。
G-buffer
Geometry阶段将几何信息渲染到MultiRenderTarget上(MRT),当前最多支持4个MRT。并且驱动要求4个MRT必须相同的bit宽度。RT对显存占用过大会增加带宽,降低cache命中。而简单格式的RT又会影响画质。因此决定使用32bit的RT(如A8R8G8B8,R16G16F)或64bit宽度的RT(如A16R16G16B16F)。需要在画质和性能间做出折衷。(开发时尽可能可以方便的配置)。中有一些性能比较。
光照计算
使用延迟渲染技术最大的好处就是可以渲染光照极为复杂的场景。这里场景中的光照可以分为两类。
影响整个场景的scenelight。如directionallight。渲染一个screenquad,逐像素光照计算,没什么好说的。
另一类是只影响一部分区域的locallight。如点光源,聚光灯,以及特效等等。这些locallight只影响到屏幕上的某些像素,当然不需要逐像素的进行光照计算。最简单的方法是绘制这些光源的包围体(点光源的包围体是球,聚光灯的包围体是圆锥),包围体的大小要大于等于光源的衰减范围。这些包围体经过变换投影到屏幕上的对应区域,随后在pixelshader中计