Deferred 框架下的AA
前面说过Deferred 框架下无法使用硬件AA。这句话不严谨：
- Deferred Shading在G-Buffer之后，物体几何信息全被抛弃了，导致兴许每一个像素都独立计算，所以不能使用硬件AA；
- 可是：Deferred Lighting，在Shading Pass阶段。物体会被再次渲染一遍，此时打开硬件MSAA，肯定是能用的（虽然光照部分取自lighting Pass阶段得到的texture，没能享受到AA。但对终于结果影响非常小）。
所以。总结来看，Deferred Lighting能用硬件AA，而Deferred Shading不能使用！
即便如此，因为硬件AA处理的是primitive的边界，而非真正的“物体边缘”。所以对时间和空间的冲击那是相当巨大。
这一问题在deferred框架下尤其明显。所以各种基于post process的AA方法应声而出！
眼下基本的各类Post process AA:
-
GPU Gems2 “Deferred Shading in S.T.A.L.K.E.R.” 一章介绍了 Edge
AA
- 对每像素做边缘检測，得到一权重值，终于依据权重值和阀值做比較，提取出“物体边缘”
- 对“物体边缘”。依据其权重值，与周围像素融合，得到AA效果
- 缺点：“阀值”和分辨率相关
-
GPU Gems3 “Deferred Shading in Tabula Rasa” 一章介绍了由NCSoft改进的Edge
AA
- 改进边缘提取算法，使其“阀值”和分辨率无关
- AMD 的 Directionally Adaptive Edge AA
- MLAA
- DLAA
- Humus 的GPAA
- NVidia的FXAA
当中。FXAA效果不错，时空效能也不错。自面世以来一直比較受宠。可重点关注一下！
处理半透明物体
-
RGame如今在用的，也是最常见的做法：
- 在defferred Rendering之后专门再开一条forward Rendering 管线专门来绘制半透明物体
- 尽管不利于扩展维护，可是简单、粗暴、有效；
- 值得注意的是。万一场景中半透明物体非常多，且须要接受光照影响，那不能通过Deferred Rendering处理的物体就多了。此时这样的方法不可取。
-
KlayGE 4.0开源引擎中提出的方法：
- 首先得到不透明物体的G-Buffer。正常流程经过Lighting Pass 和 Shading Pass绘制不透明物体
- cull mode设置为front(依据坐标系的不同为CW或CCW)，得到半透明物体的背面的G-Buffer（中间需clip掉比不透明物体更远的pixel）。然后经过Lighting Pass + Shading Pass + Alpha Blend得到终于结果
- cull mode设置为back，与上面过程一样。绘制半透明物体的正面并Alpha Blend得到终于结果 -- 缺点也非常明显：3倍的内存、带宽消耗。眼下使用价值不大
-
对光照计算结果的正确性做妥协。
- G-Buffer的引入实际上是仅仅保留了屏幕上同一块区域的一个片元的几何信息；
- 对于多个片元重合的情况，假设都是不透明物体。那没问题；假设有半透物体， 那么仅仅有在透明度达到一定阀值时。才写入G-Buffer
- Deferred Lighting的优势凸显：毕竟要在shading pass阶段再渲染一遍物体，那么渲染半透明物体时，关闭Z-Test。依照正常流程去Shading， 之后做alpha blend融合就好。不对的仅仅是光照结果部分。
- 据说，QQ飞车就是这样做得，透明度阀值取75%，不细致看发觉不出问题
- 当然。这样的方法不适用于Deferred Shading
- 补充：注意大前提“半透明物体须要受光照影响”；否则不如直接进入foward Rendering管道