原文为了看起来像一个论文，所以写的洋洋洒洒，引经据典，其实在我看来SSAO本身就只是一种tip，没必要那么啰嗦，关键的东西说来就两句话，在每个像素为中心的球体内，发射与屏幕垂直的n条线，计算每条线在这个球体范围内有多少被zbuffer遮挡，再按比例加起来作为AO。

 

放点图，10次sample，但只做了一次2x2的blur，所以质量不太好，但速度确实比以前的方法快，提高blur的kernel可以提高质量，不过又慢了。

 

关：

开：

    这个是名字是我乱起的:)。。。发了上一篇之后突然想到，既然radiance volume可以做能量传递，那或许也可以做为ao的传递，

因为ao信息也是低频的，于是有这个名字。。。

    改一下lpv的过程，不要生成rsm，而是直接将mesh写入volume，生成的时候关掉ztest和zwrite，直接写入到对应的位置。只需

用位置和normal即可，同样把信息投影到sh。propagation 过程一样，只是现在只需要一个target，然后在用到场景上的时候，分别

计算volume空间的+/-x, +/-y, +/-z六个方向的和作为ao的程度。没有深入研究，只是好玩，还是有那么点效果的，也许提高band

数和volume的voxel数之后说不定真能用在游戏。

随便弄下结果如下：

    测试了Light Propagation Volumes，全实时没有任何预处理的GI，而且可以适用任意场景。
  文档很长，不过基本原理还是比较直白的：
     生成reflect shadow map(rsm)。
     将rsm信息用SH系数方式注入一个volumetexture中。
     在volumetexture中进行propagation(大概叫传递或者传播的意思)。
     最后将propagation完的volumetexture应用到场景上(可以用于延迟或者前向，这个比较强)。
   
    总的来说，这个方法并不非常新鲜，如果对辐射度相关的东西有研究，特别是Radiosity和SH比较熟悉的话，看到这种方法

应该并不是很意外，而是一种很自然的发展，像ATI的irradiance volume，已经很接近了。
    文档后面那长长的参考资料，如果都看过和了解，能想出这种方法也应该不难(不过那个量是非常恐怖的，像树一样，资料后面

还有资料。。。，需要日积月累)。
  
    更细的东西可以看原始文档，这里说些文档上没提的细节和需要稍微注意的地方：
  
    * 首先为什么能够这样做，这是因为SH系数有个强悍的特性，可以在球面所有方向进行叠加，适应3维空间上的不同方向，早先

通常用cubemap之类来保存radiance，SH避免了这个麻烦，当然如此少的系数只是近似。使用的时候通过与某个方向上的系数的

点乘计算出该方向上的强度。所以可以用一个点来表示各个方向系数的和。

    * 说下文档中sh系数的来源，某个向量投影到SH基函数的时候，前两个band的系数是1/(2*sqrt(PI), -sqrt(3)/(2*sqrt(PI)*y,

sqrt(3)/(2*sqrt(PI)*z, -sqrt(3)/(2*sqrt(PI)*x。根据[Sloan08]，如果投影到zonal sh基函数，则lobe系数是band0:

sqrt(PI)(cos(a)-1), band1: 0.5*sqrt(3)*sqrt(PI)*sin(a)^sin(a); 分别乘上去就是0.5*(cos(a)-1),0.75*sin(a)^sin(a),

-0.75*sin(a)^sin(a),0.75*sin(a)^sin(a)，也就是文档中的那个ZH系数。
  
    * 文档中的SHRotate函数有个副作用是对向量做normalize，如果向量已经是normalized的，则不需要再搞一次了，band1的

系数直接等于(vZHCoeffs.y * vcDir.y, -vZHCoeffs.y * vcDir.z, vZHCoeffs.y * vcDir.x)即可。
  
    * 跟上面差不多，shader用到SHProject的地方多数都是用90度，所以可以直接先计算ZH系数，不用傻傻去做cos，sin。
  
    * 注入和propagation两个阶段的texture，都应该用point方式读取，应用到场景上的时候用trilinear读取。
  
    * 在dx9下由于没有render to volumetexture，可以用2d texture来模拟作为radiance volume，比如用1024x32来模拟

32x32x32，不过这样在pack到这个图的时候就比较痛苦一些，有不少小问题，要正确计算像素和uv的位置，而且在dx9下，像

素被认为是无大小，所以要小心的做偏移，另外就是trilinear也要自己做了，一个是完全用point方式sample，然后自己一堆lerp，

另一个是相邻两层用硬件bilinear，然后做一次lerp，后面这个要容易些，不过在边缘要做额外处理，比如在边缘塞进一个空白的像素，

坏处是图变大了，另一个方式是裁剪掉在边缘半个像素之内位置，这样不用改什么东西，只是调整了一下裁剪的大小。
   
    * 关于像素snap，如果不snap则完全不稳定，闪烁厉害，基本没法使用。rsm snap的时候类似shadowmap，基数是一个rsm

texel的投影后的尺寸。而radiance volume snap的基数是volume的texel在world空间上的大小，两者不一样。
  
    * 原始文档没有具体说用多大的rsm和volume的size，我自己试的话rsm在512x512比较好些，太多的话性能就下降厉害，

太少的话光源动的时候闪烁比较明显。
   
    * 如何注入(injection)。使用一堆point primitive，画到radiance volume texture里（或pack后的2D radiance texture），

点的坐标是rsm空间的屏幕坐标，在vs里转到radiance volume的clip空间，在ps中投影到sh。
  
    * 关于性能，没有具体测过，与场景有一定关系，不过我用cry的那个sponza场景，用上面说的设置，原来30fps，开启一个

cascade之后大概只有17，没有任何优化，并且为了方便，我用16bit浮点图存系数，很大的影响了速度，另一个是由于用dx9，

mrt消耗比较大(显卡是很垃圾的9400，有其它HDR等效果)。总的来说，实时是可以保证的，不过要稍好一些的显卡。
   
    * propagation过程能量在cube的每个face间传递，但是最终的结果是前面所有步骤的叠加，不过可以对propagation

过程的中间结果加一个参数，用来控制衰减的快慢，较大的衰减可以减少propagation次数。
   
    * 文档中并没有说一个volume实际覆盖多大的区域，这个跟场景有关系，我自己用32X32X32覆盖到32X32X32，觉得还

可以。但看cry的图似乎还要再大些，可能是64X64X64。这个数值如果更改那么注入的偏移也要跟着改。
  
    * 如何应用到场景上。本质上很容易，就是场景的点的normal投影到sh，用trilinear采样radiance volume的点，做dot得到

亮度即可(所谓的cos lobe)，场景的position可以根据需要向normal方向做一定偏移，这可以大大改善漏光和背面自照明的问题，

原文不推荐这种方法，不过我觉得在场景没有太多靠在一起的东西的时候效果还不错，反正一切还是以场景表现为主。
   
    * RGB三个分量要分别用一个radiance volume表示，就是说injection和propagation阶段都是mrt，这在dx9上比较慢。
     
    * 对于实际使用来说，虽然文档说适应任意场景，但不同场景有些参数可能需要不同，比如injection的偏移，衰减系数，

propagation次数之类，甚至grid cell的大小等等，可能都需要根据不同场景来调节达到最好效果。

 

 

贴些图(上边开，下边关)：

 

 ============================================================================

============================================================================

 

 ============================================================================

  

 

============================================================================

============================================================================

============================================================================

============================================================================

  现在很多延迟光照算法，都有保存normal的pass，为了节约资源，很多有把normal三个分量pack为两个分量的算法，以d3d的左手坐标为例，normal在camera空间。
  最开始有:
    pack:xy = norm.xy;
    unpack:norm.xy = xy;
               norm.z = -sqrt(1 - x^2 - y^2);
  这个方法开始用的很广泛，但它是错的，因为由于透视投影的关系，有些面并不朝向眼睛方向，但仍然能被渲染进buffer里，所以z的符号不能确定。
  stalker对它做了一个非常直接的改进:
      pack:xy = norm.xy * 0.5 + 0.5;
              x *= norm.z>0?1:-1;
      unpack:norm.xy = abs(xy) * 2.0 - 1.0;
                 norm.z = (x > 0?1:-1) * sqrt(1 - x^2 - y^2);
  简而言之就是把z的符号存到pack后的x里，因为pack后x一定是正数，从算法上来讲这是正确的，但在实际使用中，通常用来保存normal的texture每个分量不会超过16 bit，则在x和y接近1的时候，会有比较大的误差，这个时候z接近0，如果是一个大的平面，x的符号会在1和-1之间抖动，表现在图像上主要是灰白相间的条纹。
  cryengine3的present的也有一个pack的方法:
      pack:xy = normalize(norm.xy) * sqrt(norm.z * 0.5 + 0.5);
      unpack:norm.z = length(xy)^2 * 2 - 1;
                 norm.xy = normalize(xy) * sqrt(1 - norm.z * norm.z);
  意思是将z的值作为xy向量的长度。unpack的时候先由长度得到z，然后由于xy比例一致，解norm.xy/sqrt(1-norm.z*norm.z)=norm.xy/sqrt(norm.x*norm.x+norm.y*norm.y)=xy/sqrt(x*x+y*y)即可得到xy，光从算法上看这也是正确的，但实际上用起来也是有的问题的，一个是除0的问题，因为有normalize操作，在z接近1或-1的时候，unpack xy会得一个误差比较大的结果，光照效果会有跳跃，不过并不明显。另外一个是这个算法计算量比较多，导致本身的误差积累比较大，同一个平面，相机在不同角度会有不同亮度，这个有些情况下很明显。

  后面的两个方法，实际上在没有比较大的平面的情况下，问题有时候不太明显，而且在增加bit数之后问题会有改善，但既然增加了bit数，不如干脆存三个分量来的直接，而且不需要pack/unpack指令。到现在为止我仍然没有找到一个算法有非常满意的结果，仍然直接存三个分量是最满意的。

 

  嗯，刚发完，托小Q的福，看了http://developer.nvidia.com/object/real-time-normal-map-dxt-compression.html这个文章，压缩dxt5和3dc normalmap的方法，不过也同样适用在这里:

    pack:pX = X / ( 1 + Z )
            pY = Y / ( 1 + Z )

    unpack:denom = 2 / ( 1 + pX * pX + pY * pY )
               X = pX * denom
               Y = pY * denom
               Z = denom - 1

  目前看来这是个比较不错的办法，虽然稍微慢些，但没有边界值和数值精度的问题。比较稳定。

 到今天为止，我已经实现了一个比较完整的延迟着色(ds)渲染器，包括各种各样的类型的处理和融合opaque，translucent，mirror reflect，cube reflect, terrain，sky，particle，primitive，ui，postprocess（hdr，dof，lightshaft, ssao）等。国内很少有人做基于ds的渲染，导致我找不到人讨论，一直都只好到国外翻。
因此除了总结一下之外，后面有人想做可以留个参考。ds本身实现是很容易的，不过集成一个完整的渲染器却也不是那么容易，之所以有前面那篇nvperfhud分析crysis的文章，最初就是因为我想参考它里面的透明物体的shadow receive做法。

 场景方面就不说了，也太琐碎。只说渲染部分。
 渲染器基于层(layer)来渲染。每个层cache resource之后都会进行以下几个pass：
 
 1，首先是在输出gbuffer之前对于反射之类的rtt的东西的处理。
 2，gbuffer建立。能够写入gbuffer的东西只有terrain(这使得地面也可以接受大量的灯光照射)和opaque物体。对于gbuffer之前我是使用两个pass输出gbuffer，一个输出depth，做earlyz，然后才是真正的gbuffer。
后来合并为一个pass，不再做earlyz，物体不多的时候速度上感觉相差不明显，不过受制的因素较多，不好说哪样一定好。绘制的时候可以标记stencil为后面的光照做优化。
 关于gbuffer的格式我试过两种方式。
 一种是rgba8，rgba8，r16g16f，r32f，分别放diffuse(alpha speculargloss)，emissive(alpha specularpower)，normalxy，depth。可以看出存放的相当猥琐，并且无法用specularcolor，而且存取时normal和depth都需要encode decode。好处是比较少的显存，和勉强能够在低端机器运行(事实上用了ds基本就告别低端了，硬要做的话只能让大家都痛苦，机器痛苦，人也痛苦)。
 另一种是rgba16f*4，分别放normal(alpha depth)，diffuse(alpha diffusewrap)，specularcolor(alpha power)，emissive。一般情况下f16存放depth精度是足够的。使用这种方法好处是只有depth需要encode decode，并且资源充足，可以存放比较多的材质参数。缺点是显存消耗变成两倍。并且肯定无法在低端卡运行了，不过与其它效果组合之后，这种格式对显存的消耗也不一定比前面一种格式多，比如用hdr的情况下，其实可以跟emissive共用一个buffer，而如果透明物体也要跟opaque物体一样接收shadow和光照，那大多数情况下需要第二个buffer，这时候可以跟diffuse共用。
 3，作为优化，这里将translucent物体用alpha test将不透明部分的深度写入gbuffer的depth。这使得某些象素不需要被计算，而且对某些东西有特殊作用，比如头发等交叉透明的东西。
 4，对gbuffer进行着色，对于castshadow的light，使用depth绘制shadowmask，着色的时候加上。每个灯光一个pass，可以通过设置scissor rect和绘制light的boundingvolume来做优化。并且进行fog等统一类型的判断，使用不同的shader。对于是否有shadow等，可以先构造shader cache。shadow现在用pssm+jitter，相对其它vsm，esm，pcss，psm，tsm之类，这个方法还是比较稳定的，能够适应大多数情况，pssm切分的slice数量和长度可以自由设置，一般情况下4个slice可以比较清晰的覆盖200米以上的范围，这可以满足大多数游戏了。
 5，ao和opaque fog，mirror reflect和cubemap也作为emissive加进去，按理这两个应该属于specular，可是由于统一渲染模型的问题，我将其放在这里。
 6，sky，gbuffer在写入的过程中用stencil做标记，所以sky可以放在这里绘制。
 7，translucent物体。用传统方式，但不处理阴影。由于使用pssm，透明物体的接收shadow变成一个真正的nightmare，不仅只能用foreword，而且要决定用的是哪个slice的shadowmap，而且还不一定完全属于哪个slice，虽然分析了crysis的pass，不过我还不是很确定它怎么做，似乎是用了松散的slice的办法，保证物体总能完全落在某个shadowmap内，因此只用一个shadowmap来计算。在这里获得一个逻辑上基本正确的阴影确实是非常麻烦的事，我仍然在寻找更好的方法。
 8，particle，传统方式渲染，不过利用depth做soft particle。
 9，lightshaft等颜色相关的postprocess。
 10，hdr，我试过好多种公式，包括：

1)Reinhard。d3dhdrlighting和nv的一些sample，缺点是太暗，而且灰度低。

2)Reinhard modify。ue3和一些游戏用，比较难控制，很难适应任意亮度。

3)exp。crysis用，比较平滑，不过仍然无法适应任意亮度。

4)pow。nv的某个openglsample，能够适应大多数亮度，不过不太符合人的颜色感觉。

5)log。这是我参照crysis的exp自己凑的公式，目前也用这一个。
 11，颜色无关的postprocess，比如dof。多说两句，dof看似简单，其实要处理的比较正确还是很麻烦的。我参考过很多文章，包括gpugems3的cod的方法，ati advance dof，starscraft2，nv sample，u3，crysis(u3和crysis用的是ati的方法)等等。。。。其中只有cod的方法能够比较正确的处理。其它方法都是有问题的，我现在的做法是结合cod和ati的方法。
 12，ui。
 
 上面几步看似简单，实际上我试验了不少时间。其中的细节还有很多麻烦事，耗费时间不计其数。
 层数量可以自由控制和叠加，渲染到某个target上。
 
 ds的好处网上很多地方都说了，最主要的是能够处理大量光源，并且不需要耗费cpu去寻找每个物体的影响光源。
感觉上ds某些思想跟光线追踪类似，也许它的出现预示着光线追踪的普及应该不太远了。。。

 虽然感受到ds的好处，但同时也被它的不足折磨的够呛。下面说说不足方面，我没有看过shaderx的那篇ds drawbacks的文章。有些东西需要彻底实现过后才能有深刻的印象，下面这些都是我自己碰到的。
 1，首先是透明物体，很多文章说ds最大的问题是透明物体的处理，单独从渲染上来说这实际也不是太大的问题，毕竟只是切换到传统方式来渲染。只是相对ds的方式来说不太和谐。。。主要是破坏了ds的好处，仍然需要去寻找影响光源，而且跟pssm结合之后，这几乎成了我最大的问题。
 2，统一渲染方式。这几个字眼在别的地方也许是一件好事，但在当前硬件下面却不见得。我感觉这才是ds最大的问题。一旦写入gbuffer，那么所有的象素就只能用一个方式来着色。这造成了很多东西需要额外处理，比如sky，某些terrain，水面，镜子（我写入emissive，但我认为并不完美）等等。。。好多东西要额外处理，某些情况下导致能够写入gbuffer的东西变的很少了，ds的好处被压缩了。

 3，室内处理。ds对室内处理薄弱，在不做特殊处理的情况下，很容易发生一个灯从一个房间穿过墙壁照到另一个房间，如果用传统方式，我们可以直接对房间忽略这个灯光。gpugems里面那个韩国游戏用了一种boxlight来处理，我也实现了一个，但效果不太好，因为gbuffer和其它translucent物体都需要进行处理，提高了复杂度。
 4，怪异的材质系统，由于使用了统一渲染模型，因此对于ds来说颜色输出部分已经不需要编辑了，也不可能拿来编辑。我们要做的是渲染公式的输入部分，即输入到gbuffer的材质参数。比如使用phong模型的话，diffuse，specular color，power，emissive，等等。而且由于2的原因，额外处理的东西很多，材质系统变得很难写，也很难编辑，时刻要想到同时满足不同的shader，我到现在也才设计了一种脚本，没有做成编辑器。
 5，显存问题。这个东西也许以后不是问题，但现在还是问题。gbuffer加上其它hdr，ssao，dof，shadow等所用图，显存很容易就超过100m，特别是分辨率大了之后。
 6，Multisample Antialiasing的问题就不说了。
 
 其实还有其它暂时想不起的问题，那些问题都很细小，但让你在做下去的时候感觉就是不太舒服，甚至有些时候想用回传统方式的渲染。
 
 后来我看到了一个称为light pre pass的渲染方式，作者写的模模糊糊，我也看的迷迷糊糊，感觉上逻辑好像不通，或者作者故意掩盖了一些东西没有表达。其做法是类似ds，但反过来，只输出depth和normal，然后就计算灯光，写入一个buffer里。最后再将物体渲染一遍结合灯光的输出结果，也不是很明白。

    其实对熟悉反汇编的人来说并不难，本来用hook也可以，不过crysis是通过CryRenderD3D9.dll显式加载d3d9.dll，IAT表中没有相关地址，hook比较麻烦。所以我还是修改反汇编来做。

    首先我们需要确定d3d9.dll中Direct3DCreate9的地址，d3d9是系统模块，地址固定，很多工具可以查，没有工具也可以，LoadLibrary即可得到d3d9.dll的地址，然后GetProcAddress即可得到Direct3DCreate9的地址。可知地址是：0x4B66AED0。

    然后找一个反汇编调试工具，我用ollyice，是ollydbg的修改版，用oll启动crysis之后，先直接运行，直到d3d9.dll出现在memory map中：

然后我们转到d3d9.dll模块中，定位到4B66AED0这个地址，设置一个断点:

然后重新运行调试Crysis，一直运行到刚才设置的这个断点，返回堆栈，我们发现Direct3DCreate9这个函数是在CrySystem.dll中调用的，而不是CryRenderD3D9.dll中(实际上后面CryRenderD3D9.dll中还会再调一次，不过我们已经不需要了):

执行到函数返回，IDirect3D9指针就存在eax内存中，从eax内存可以看到IDirect3D9指针指针地址是0x4B641A98:

实际上这也是一个固定地址。转到d3d9.dll模块的这个地址我们看到以下这个表：

这就是IDirect3D9类的函数表，而CreateDevice的偏移是0x40，也就是最后一个函数，可以看到地址是0x4B6C1660，转到这个地址，也就是CreateDevice函数的起始位置，设置一个断点:

然后继续运行，直到断点断下来，可以返回堆栈看看:

其实这里的CreateDevice通过CryRenderD3D9.dll调入,并不是真的创建设备，可能只是做一下检测之类，从返回的代码上看，它创建之后马上就删掉了，我们继续运行，CreateDevice函数又断了下来，这次是真正的创建Device操作，返回调用的函数:

可以看到，其中call ecx就是调用CreateDevice函数，上面7个push是传入参数(最后一个是direct3D指针本身)，倒数第二个和第三个就是adapter和devicetype，也就是我们要修改的参数，nvperfhud的要求是这两个参数一个用nv的adapter，通常是1，跟显卡和显示器数量有关，另一个用ref(数值2)，如果不修改，调试到这里会发现adapter是0，devicetype是1，如何修改呢，直接改为push 2和push 1是不行的，因为我们看到这两个数来自，dword ptr [esi+8]和dword ptr [esi+4]，不管这是哪里的内存，直接push的话会跟它不对应，导致在后面游戏直接死掉，可能后面的代码有其它的匹配判断，所以我们需要连同这两个内存一个修改，容易想到的是在
3816A5FA    8B46 08         mov     eax, dword ptr [esi+8]
和
3816A5FE    8B46 04         mov     eax, dword ptr [esi+4]
之前分别增加两条指令
mov     dword ptr [esi+8], 2
mov     dword ptr [esi+4], 1
但这样一来
指令长度就超过地址范围了，导致后面的指令被覆盖。不过还好我们看到call后面的两条指令
cmp eax, 88760868
jnz short 3816A658
这两条指令的意思是判断createdevice的返回值，如果为0(创建成功)，就跳转到下面的地址，既然到了这一步，我们就假设createdevice永远为成功，不要检测了，所以我们直接覆盖掉这些指令，但要在call之后，加一条jmp跳到那个成功的地址，否则将不正确，如下图：

大功告成，先把原来的CryRenderD3D9.dll备份一下，把修改后的模块存为CryRenderD3D9.dll。将crysis拖入nvperfhud，就能看到有分析了。

试了gpugems3中的方法。

方法很简单，将一张遮挡后的明暗图做一些sample，再调整一下，add到原先的target上。有意思的是
其实我在2004年的时候就在一个项目中看到一个老外用了这种方法，当时也没放在心上，没想到现在会
出现在gpugem3上。不过这种方法其实只是近似的做了一些处理，使挡住光源的物体造成lightshaft的
效果，没有利用到深度的信息，还不是真正的“volumelight”。现在一些游戏中的效果比这个方法要高
明一些。我改进了一下，让物体不需要挡住光源也可以出现效果。

     摘要: 半年以上没有更新了，修修改改，Graphenix渲染过程。 首先是深度pass，这个pass可以只做depth write，虽然也可以通过其它方式在lighting阶段重建某个空间中的position来计算，不过我在这里直接输出了eyespace的position，因为后面可以省下很多力气重算位置，而且如果拆成两个pass，速度甚至会下降。眼空间position:Gbuffer pass，全部在e...  阅读全文

     摘要: 最近没有做到什么实质上的东西，在研究d3d10的接口，准备对自己的简单引擎重新构架渲染库。相比起来，d10对资源的组织比d9清晰了不少，IA，VS，GS，SO，RS，PS，OM各种资源现在都围绕流水线各步骤组织和命名，并且模块化，以前用d9中我们需要花不少力气在自己的引擎中组织这些东西，相信以后的引擎对于渲染资源的组织会省下一些工夫。另外资源的重新组织也带来了一些好处，比如Texture和Samp...  阅读全文