Deferred Shading，看过《Gems2》 的应该都了解了。无论是Unreal3、Crysis还是星际2，都已经支持或者准备支持这个技术。
不过因为国内这种环境，真正在项目中能用到的可能并不多，不知道这次星际2出来后，情况会不会有所变化。^_^
本文是对Gems2这篇文章的一个补充，小生在做此次外包的时候，由于需要，翻译了这篇文章，不敢独享，遂贴于此，望能抛砖引玉，愿众位前辈不吝赐教。 ^_^
Tabula Rasa中的延迟着色技术
作者:Rusty Koonce （NCSoft）
翻译:noslopforever（天堂里的死神）
本翻译仅用于学术目的。
这篇文章是对GEMS2里《Deferred Shading in S.T.A.L.K.E.R.》（中文译名《S.T.A.L.K.E.R.中的延期着色》，原作者Oles Shishkovtsov）的一个补充。它是在我们耗时两年时间、为游戏Tabula Rasa（Richard Garriott担纲的MMORPG）完成的渲染引擎的基础上形成的。GEMS2的这篇文章覆盖了实现一个Deferred Shading引擎的基本原理，而我们将重点放在了基于Deferred Shading引擎的工作中时可能遇到的更高层面的问题、技术和解决方案上。
1 Introduction
在计算机图形学的词典里，Shading表示“对受光物体的渲染”，这个渲染过程包括下面几步：
1， 计算几何多边形（也就是Mesh）。
2， 决定表面材质特性，例如法线、双向反射分布函数（bidirectional reflectance distribution function，BRDF）等等。
3， 计算入射光照。
4， 计算光照对表面的影响，并最终显示。
一般渲染引擎，渲染场景中的物体的时候，是将这四步一次执行完的。延迟着色则将前两步和后两步分开到渲染管道相互独立的两个部分来执行。
我们希望读者在阅读本文前，能先了解一下延迟着色的基本原理。以下的文章都不错，可以读读：Shishkovtsov 2005，Policarpo and Fonseca 2005，Hargreaves and Harris 2004。
在本文中：Forward Shading（前向渲染）是指4个步骤一齐处理的传统着色方法。Effect就是Direct3D的D3DX Effect，而Technique，Annotation和Pass，与它们在D3DX中的概念一样。
材质着色（Material Shader）是指用来渲染几何图元的Effect（也就是前两步），光着色则是指用来渲染可见光源的Effect。几何体（Body）用来指代那些需要渲染的物体。
在这里我们忽略了显卡相关的优化或实现，所有的解决方案都是普遍适应于SM2和SM3硬件的。我们希望能强调这个技术，而非实现。
2 Some Background
在Tabula Rasa中，我们一开始的渲染引擎是基于最初的DX9而完成的传统前向渲染技术的，使用了HLSL和D3DX Effect。我们的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了，这样就节省了Draw Call和状态切换的数量。
3， 在增加新的光源类型和光照模型时，材质的Shader不需要做出任何改变。
4， 材质Shader不产生光照，这样就节省了计算额外的几何体的指令数。
延期着色需要显卡提供MRT的支持，且利用了不断增加的存储器的带宽——这也就意味着我们可能得对玩家所使用的硬件提出更高的要求。因此我们既实现了前向着色，也实现了延期着色。我们优化了前向着色管道，并在此基础上完成了延期着色管道。
有了一个完全基于前向着色的系统作为后盾，我们就可以以更高的硬件标准来完成延期渲染系统了。我们使用了SM2的显卡作为前向着色系统的最低配置，而延期着色系统，则需要支持SM3的显卡。这样就更易于开发一个延期渲染管道，因为我们不必要再顾虑指令数的限制，且能使用动态分支语句。
3前向着色支持
即便是工作在延期着色引擎下，对于半透明物体的渲染依旧需要前向渲染管道的支撑（详见本文第8节）。我们的引擎里保留了对整个前向着色管道的支持，这个管道用来处理半透明物体，以及用于在低端显卡上替代延期着色引擎。
本节讲述了我们是通过什么方法来同时支持前向和延期渲染的。
3.1 受限的特性
我们限制了前向渲染管道的特性，只让它实现延期渲染管道所有特性的一个很小的子集。有些特性因为技术上的原因无法支持，有些是因为工期太紧，但更多的，是为了开发起来方便而被我们丢弃掉了。
我们的前向渲染管道支持球状光源（hemispheric），方向光源和点光源，其中点光源是可选的，其他的所有类型光源都不支持（包括Spot Light，Box Light，它们只由延期着色管道来支持）。在延期渲染管道里构建的阴影和其他特性，在前向渲染管道中都不支持。
最后，前向渲染中的Shader是可以做逐顶点光照和逐像素光照的。在延期渲染管道中，所有的光都是逐像素的。
3.2 一个Effect，多个Technique
我们使用了在Effect中使用了不同的Technique来完成前向着色、延迟着色和Shadow Map，以及更多的东西。我们对每个Technique指定了Annotation来标明这个Technique使用了什么样的渲染方式。这就允许我们将所有的Shader代码放到一个统一的Effect文件里，来实现渲染引擎所需的所有Shader（见表19-1）。这包括前向着色中的静态和骨骼模型，延期着色使用到的“材质着色”（Material Shading）的静态和骨骼模型，以及Shadow Map。
把Effect所能用道德所有的Shader放到一个地方，我们就可以尽可能多地共享一些可以跨越不同渲染技术的代码。当然，我们不会去做一个超长的文件来储存这些代码，而是将这些Shader建立了一个由多个文件组成的Shader库，包含了各个Effect都能用到的共享的顶点和像素代码，以及常用的函数。这减少了Shader代码的复制，使得维护变得容易，减少了Bug，以及增强了各个Shader之间的稳定性（consistency）。
表19-1：材质示例
|
Code View: // These are defined in a common header, or definitions
// can be passed in to the effect compiler.
#define RM_FORWARD 1
#define RM_DEFERRED 2
#define TM_STATIC 1
#define TM_SKINNED 2
// Various techniques are defined, each using annotations to describe
// the render mode and the transform mode supported by the technique.
technique ExampleForwardStatic
<
int render_mode = RM_FORWARD;
int transform_mode = TM_STATIC;
>
{ . . . }
technique ExampleForwardSkinned
<
int render_mode = RM_FORWARD;
int transform_mode = TM_SKINNED;
>
{ . . . }
technique ExampleDeferredStatic
<
int render_mode = RM_DEFERRED;
int transform_mode = TM_STATIC;
>
{ . . . }
technique ExampleDeferredSkinned
<
int render_mode = RM_DEFERRED;
int transform_mode = TM_SKINNED;
>
|