2007年3月26日
#
对于通用场景来说我以前介绍的区间扫描线Z缓冲器算法可以剔除大部分的不可见物
体，但是在基于heightmap的大规模地形场景下会发现作用不是太大，区间扫描线Z
缓冲器算法需要在场景中手工指定occluder，occluder必须为规则物体，而在地形
场景中这种occluder非常少，也就是场景中的建筑物之类的物体。实际上地形场景
中最适合作为occluder的是连绵起伏的丘陵、山脉，它遮挡住了场景中的大部分物
体，但是区间扫描线Z缓冲器算法对这种情况下的OC就无能为力了，需要使用其它算
法进行OC计算，现在网上完全公开的适用于地形场景的OC技术主要有以下几种：
Voxel column culling、Hierarchical visibility、incremental horizon。这些
算法都需要进行一些预处理，其中最流行是incremental horizon（增量地平线）技
术，这种技术要求在渲染前对每一个地形块计算一个潜在轮廓线，在渲染时将这些
潜在轮廓线合并为地平线进行OC处理。由于这种算法需要进行预处理因此也不太适
用游戏开发，此后我自己又开发了一个realtime计算的incremental horizon算法，
但是发现开销太大，根本无法用于realtime rendering（和Pascal Junod在论文
《Implementation of a O(na(n)log(n)) Point
Visibility Algorithm on Digital Terrain Models》中使用的算法相同，这篇论
文我也是后来才发现的，有兴趣的可以翻看一下我以前在gameres发表的文章）。
下面列出的是网上相关的论文，有兴趣可以自己看一下。
Lloyd B, Egbert P. Horizon occlusion culling for real-time rendering of
hierarchical terrains. In: Gross M, Joy KI, Moorhead RJ, eds. Proc. of
the IEEE Visualization. Boston: IEEE Computer Society Press, 2002. 403-
410.
Stewart J. Hierarchical visibility in terrains. In: Dorsey J, Slusallek
P, eds. Eurographics Workshop on Rendering. Vienna: Springer-Verlag,
1997. 217-228.
Zaugg B, Egbert P. Voxel column culling: Occlusion culling for large
terrain models. In: Ebert D, Favre JM, Peikert R, eds. Proc. of the Joint
Eurographics-IEEE TCVG Symp. on Visualization. Vienna: Springer-Verlag,
2001. 85-93.
Stewart J. Fast horizon computation at all points of a terrain with
visibility and shading application. IEEE Trans. on Visualization and
Computer Graphics, 1998,4(1):82-93.
Daniel Archambault. All the Distant Horizon Edges of a Terrain. B.Sc.
(Hons.) in Computing Science, Queen’s University (Kingston), 2001
Pascal Junod. Implementation of a O(na(n)log(n)) Point
Visibility Algorithm on Digital Terrain Models. October 1999
后来我仔细观察farcry的editor sandbox，经过差不多两个多月的试验终于开发出
一个可以realtime运行的用于地形环境的OC算法，这个算法的开销非常小，经过我
在OGRE平台上的试验，此算法可以做到非常精确的剔除，FPS提升明显。由于这个算
法的核心是线段求交，因此我暂时称其为线段求交OC算法。
在介绍这个算法前先明确一下坐标系，一张heightmap的行为X，列为Y，高度方向为
Z。
先考虑单点OC的情况，如下图所示：
P
|
|C
A-------------------B
|
|
O
假设plane AB为一个occluder，O为camera位置，如果要判断点P是否被AB遮挡，只
需要简单的判断线段OP是否和occluder AB相交即可，如果存在相交点C则点P即被遮
挡，问题被简化为线段和平面的求交。下面继续考虑在地形环境下如何简化这个问
题，在地形环境下heightmap的每一行和列都可以看作一个occluder，这里假设AB为
行或列相临两个顶点组成的线段，如果要判断点P是否被AB遮挡，可以通过比较交点
C在线段OP和线段AB上的z值来确定：
Zc_op > Zc_ab 点P没有被线段AB遮挡
Zc_op <= Zc_ab 点P被线段AB遮挡
现在检查点P是否被遮挡在地形环境下简化为一个简单的2D线段求交问题，这也是本
算法之所以高效的原因。
下面继续来看一下如何将算法由一个点推广到整个地形。在基于heightmap的地形系
统中通常将地形分成一块块小的tile，根据LOD算法的不同tile大小可以为17*17或
者33*33不等，这里假设使用17*17的tile。
首先来看如何剔除场景中被遮挡的tile。对于tile来说如果所有的顶点都位于其前
方行和列的下方，那么它一定被遮挡。换句更精确的定义，对于tile的每一个顶点
，如果与camera所在位置所形成的线段，全部与位于tile和camera之间的行或列中
任意一条线段相交，那么可以确认tile被完全遮挡。
按照上面的定义，一个tile如果被检查到完全遮挡需要检查17*17=289次，虽然2D线
段求交运算开销非常小，但是一个tile就需要进行289次运算仍然是不可接受的，需
要更简化的算法。考虑一下区间扫描线Z缓冲器算法，occludee使用都是物体的AABB
，是否可以使用tile的AABB进行运算呢？由于地形环境的性质可以不用考虑AABB最
下面的四个顶点，但是直接使用AABB最上面的四个顶点进行运算绝对不行，如图所
示：
四个顶点虽然被完全遮挡，但是occludee并没有被完全遮挡，如果解决这个问题需
要将AABB的up表面分割成16*16的格子，这样的话运算次数并没有发生变化。
这里可以使用一个取巧的方法，如下图所示：
将AABB投影到camera空间，直接获得线段AB，将AB线段16等分，获得17个新的顶点
，注意这些顶点z值全部相等，现在ocludee是否可见只需要检查17次就可以了。
下面看一下算法复杂度，对于一个完全遮挡的tile只需要进行17个顶点的计算，完全未遮挡的tile只需要计算一个顶点，部分遮挡的tile大约是2-16个顶点左右，由于tile在进行OC运算之前首先要做frustum culling，剔除被frustum culling的tile，然后剔除那些没有被遮挡的tile，实际上的运算量非常少。
注意这里的每个顶点的计算不是指简单的17次线段求教运算,根据tile距离camera位置的远近每一个顶点求交的数量是不一样的,例如下图所示:
图中线段OA需要检查三条行和列,一共是六个交点,需要进行六次线段求交运算.
对于场景中的模型进行OC运算时，也需要按照上面的方法将模型的AABB变换到camera空间，获取一条occludee线段，然后根据地形相临顶点之间的距离确定顶点数。
使用这个算法和区间扫描线Z缓冲器算法相配合可以获得在室外场景中最大限度的剔除被遮挡物体，先用线段相交OC算法剔除被地表遮挡的tile和模型，然后用区间扫描线Z缓冲器算法剔除被建筑物遮挡的tile和模型，完美的室外场景OC解决方案，very nice！！！！
原创文章,转载请注明出处!!!!!!!
线段相交OC算法演示程序下载（使用OGRE平台，运行前先看readme文件）:
/Files/dreams/ogrenew.part01.rar
/Files/dreams/ogrenew.part02.rar
/Files/dreams/ogrenew.part03.rar
/Files/dreams/ogrenew.part04.rar
/Files/dreams/ogrenew.part05.rar
/Files/dreams/ogrenew.part06.rar
由于cnblog上传文件大小限制,因此文件被分割成1M大小上传,抱歉!!!!
2007年3月25日
#
隐藏面剔除算法的出现是基于以下的现实，在游戏场景中你不必每帧都将所有的物体渲染到屏幕上，它的作用主要有两个：一个是减少GPU的屏幕填充率，另一个是减少CPU和GPU的传输带宽。根据当前的硬件现状GPU的填充率已经不存在任何问题，而现在唯一的限制位于AGP上，它那可怜的一点带宽已经成为图形渲染的瓶颈，因此当前HSR算法大部分都放在CPU端来做以尽量减少每帧需要传输的数据量，这里你不需要对CPU的负担感到担忧，因为现在的CPU完全可以适应这样的要求。当你将场景采用适当的场景分割算法如BSP、OC tree算法组织起来后，就需要在每帧渲染时使用适当的HSR算法对其中无用的信息进行剔除，现在的HSR算法基本上可以分为四种：backface culling、frustum culling、portal culling、occlusion culling。它们的作用分别如下：backface culling用于剔除mesh背面的triangle，frustum culling用于剔除屏幕之外的物体，portal culling用于剔除不能通过portal看到的物体，而occlusion culling用于剔除场景中被自己前面的物体所遮挡的物体。其中前两种算是最常用的算法了，对于backface culling来说它已经在GPU的硬件上实现，不过为了减少传输带宽，在适当的地方你也可以将其使用到CPU部分，主要是指地形这样的大规模MESH上，如何使用这需要看你是如何组织地形数据的，当你使用triangle strip渲染地形时，尽量按块来对地形进行culling，而当你使用triangle list来渲染地形时，你就可以尝试使用逐triangle来对其进行culling，关于实际使用应该使用哪种方法，需要你自己试验一下。frustum culling由于太普遍这里不再解释，而portal culling如果详细介绍的话那就是另外一篇文章了，这里只是简单的介绍一下，通常的portal culling实际分为两种，一个是用于bsp的PVS算法，这种方法的优点是通过预计算获得可见性信息，速度非常快，而且场景中的portal可以通过程序获得，不需要手工进行指定，但是缺点也非常明显，基本上它只能用于室内场景，而且由于PVS是一个可能的可见集合因此不能对不可见场景作到完全的剔除。另一个可以被称为实时的portal culling，这种方法的优点很明显，如果场景安排合理的话它可以作到完全的剔除，而且它可以用于任意的场景中，indoor、city、terrain它都可以使用，缺点也非常明显，portal必须手工进行指定，而且由于portal culling每帧都需要计算因此每帧出现在屏幕上的portal必须进行限制，还有最重要一点通常由于场景的限制尤其是在outdoor场景中它也不能完全作到完全剔除，下面我举一个简单的例子来看看它为什么不能作到完全的剔除：
（感谢Siney提供插图）
上面可以看作是一个房子，B为房间的门，也就是一个portal，A是场景中的一个物体如果我们做portal culling计算时，如果一个npc位于D点那么可见的，但是当位于C点时，由于前面存在物体A，应当是不可见的，但是portal culling并没有将其剔除因此npc还是会被传送到GPU进行渲染。
这个时候就需要可以使用occlusion culling技术来弥补这个缺憾了，因此在一个portal引擎中必然需要OC技术来配合使用，这里再举一个outdoor的例子，在室外存在一个building，我们可以使用building的门和窗户作为portal来对building内部进行culling，将building作为一个occluder对整个场景进行OC操作。根据相关文献提供的资料，当场景使用OC技术后会比不使用OC的场景提高30%到70%不等的FPS，因此如果有可能的话应尽量将OC技术加入到你的引擎中，而且OC技术并不是只能使用到portal引擎中，它可以被使用到任意技术构建的引擎中。
现在的OC算法非常多，比较优秀的如HZB、HOM算法虽然比较强悍，但是放在CPU进行计算的话，效率还是非常低的，达不到实时的要求，而当前的GPU还没有对其实现硬件的支持，因此不是本文介绍的重点，这里介绍的OC算法称为区间扫描线Z缓冲器算法，这是一种可以进行完全剔除并且效率非常高的一种OC算法。在进行介绍前我们必须明确几个概念，在OC中遮挡物被称为occluder，被遮挡物称为occludee，OC算法就是检查occludee是否被occluder所遮挡。场景中那些比较大的物体可以作为occluder，如房屋，城堡等，occluder上位于同一plane上的polygen称为surface，surface上由edge首尾相连构成一个闭合的空间。
进行OC计算之前我们首先需要获得场景中的所有occluder，这是非常重要的一个步骤，这一步通常在场景的预处理时进行，根据场景来产生一个occluder列表并保存到文件中。
下面我们讨论一下如何获得occluder，场景中的occluder通常需要手工进行指定，这是因为开发一个自动获得occluder的算法非常复杂，同时由于OC运算效率问题同一帧中出现的occluder数量必须进行限制。下面我们分情况来考虑一下：对于一个标准的BSP引擎来说，整个场景都由brush构成，因此获得occluder相对简单一些，在对场景建模时手工指定哪些brush作为occluder，然后在进行BSP分割时对这部分brush单独进行处理，按照和场景获得可见面一样方法获得这些brush的可见面来作为occluder。而对于其他技术构建的引擎获得occluder也相对简单，例如现在MMO比较流行的基于terrain的引擎，场景中可以作为occluder的物体其实都是一个个单独的model，因此求occluder实际上就变成获得model的convex hull，这类算法也比较多如qhull算法，但是如果使用程序获得hull的话对model的外形存在一定的限制，一个替代的方法是在美工对物体进行建模时同时为其指定一个hull并保存到文件中，这样的话就不会限制model的形状了，因此对于第二种情况概括起来说就是在编辑场景时指定适当的物体作为occluder，然后将物体的convex hull保存到occluder list中。
当我们获得场景中的occluder就可以进行OC运算了，先来看看区间扫描线Z缓冲器算法是依照什么样的原理来实现OC的。
|
（感谢Siney提供插图）
在上图中物体N为occluder，A、B、C为occludee，我们假定它们投影到屏幕上都为一个矩形，我们这里称N的上下两条edge a、b为扫描线，从上图中可以看出如果物体A位于N的后面那么A一定被N所遮挡，这可以通过比较N和A所在surface的z值来进行比较，这也就是本算法中Z缓冲器的来历，现在我们假设物体A、B、C都位于N的后面，可以看出A被完全遮挡，B是部分遮挡，C没有被遮挡，如何判断呢，先看A的情况，N和A存在四条扫描线按照y从小到大顺序分别是b，d，c，a，在扫描线b和d构成的区间中由于不存在A的edge因此跳过，检查扫描线d和c构成的区间，我们称位于两条扫描线之间的edge为活化边，它们保存在活化边列表active edge list中，每一条活化边保存了两个surface指针，分别是左surface和右surface，例如对于N的左edge而言，它的左surface不存在因此指向屏幕的background，也就是z值为最大的surface，而右surface为N所在的surface，其他类似。现在我们检查扫描线d和c之间的活化边列表，首先获得A的x值最小的火花边为A的左edge，接着获得N的活化边列表中x大于A的左edge的活化边，为N的右edge，比较两条edge的左surface，A的左edge的左surface的z大于N的右edge的左surface的z，因此A的左edge被N所遮挡，接着同样的方法检查A的右edge还是被遮挡，这样我们就可以判断A完全被N所遮挡。使用同样的方法检查B，在扫描线f和b构成的区间中，由于N不存在活化边列表可以判断B没有被N完全遮挡。再检查C，在扫描线h和g之间N的活化边列表中所有的edge的x都小于C的左edge，可以判断C没有被N遮挡。对于其它复杂的情况例如存在多个occluder的情况你自己可以验证，这种算法在任何情况下都可以对物体是否被完全遮挡进行精确的判断。
通过上面的介绍相信你已经完全理解区间扫描线Z缓冲器算法的基本原理，下面看一下具体如何来实现这个算法，步骤如下：
1、获得场景中所有的occluder，剔除occluder上所有背对camera的surface。
2、使用near clip plane对所有的surface进行clip操作，剔除位于near clip plane之外的surface，如果surface和near clip plane相交计算交点，这样也就剔除了那些位于nearclip plane之外的edge。
3、将所有的顶点变换到投影空间，这里需要注意投影空间的性质，投影变换实际上就是将frustum变换为一个BOX，对于openGL来说就是一个立方体，最小拐点为(-1,-1,-1)，最大拐点为(1,1,1)，对于DX来说是一个长方体，最小拐点为(-1,-1,0),最大拐点为(1,1,1)。在投影空间所有物体投影到屏幕上形状不会发生改变，这也是为什么要变换到投影空间的原因。计算每一个surface在屏幕上的投影面积，剔除那些面积过小的surface，剔除位于frustum之外的surface，但是并不对surface求交，这是为了防止因为计算精度的原因出现错误。将surface所在的plane也变换到投影空间，这样做是为了方便计算指定顶点的z值。
4、将变换到投影空间中的所有顶点保存到edge list中，注意edge保存方式，edge起点的y值应当小于终点的y值，并且我们称起点处的y值为edge的y值。在edge list中按照edge的y对所有的edge按照从小到大的顺序进行排序，如果y相同比较x值，如果x也相同比较edge的斜率。因为edge list完全按照y进行排序，因此我们也可以称其为Y桶。需要注意的是如果edge和X轴平行的话，并不需要将其加入到edge list中。
5、查找扫描线并计算扫描线之间的活化边列表。从上面的原理介绍中我们也能大致了解如何获得扫描线，扫描线必然位于edge的端点上，而且如果edge存在相交的话，那么交点也需要做为扫描线，那么我们需要对Y桶进行遍历来查找位于扫描线Y=-1和Y=1之间所有的扫描线，当获得所有的扫描线后接着需要计算扫描线区间的活化边列表，注意活化边列表中的edge需要使用edge与扫描线之间的交点作为端点，并且活化边列表是按照x进行排序，因此也可以称为X桶。
6、对场景需要检查是否被遮挡的物体传入它的AABB作为occludee，首先检查occludee在屏幕上的投影面积是否足够大，如果太小不需要对其进行OC，接着将AABB转换为一个BOX，计算BOX的surface和edge，将其变换到投影空间并按照上面的方法查找扫描线并获得活化边列表。从occluder和occludee中y最小的扫描线出发，逐区间对活化边列表进行比较检查occludee是否被完全遮挡。
在这种算法中，几乎每帧都需要对活化边列表进行更新，因此计算量最大的部分也在这里，不过一旦活化边列表建立以后对occludee进行遮挡计算非常方便快捷，适合对大量的动态物体进行OC运算，尤其是那些渲染代价非常大的角色模型。
HL2的地形系统是一个另类的地形系统，它没有使用当前流行的heightmap技术，而是完全使用displacement map技术来进行处理，使用displacement map技术的初衷是为了在框架中和BSP技术保持一致，这是因为在BSP中最小的渲染图元是surface，surface的限制是所有的顶点必须位于同一个平面上，实际上从理论上来说在HL2这样的引擎中也可以使用heightmap来构造地形，那就是将heightmap数据也分块保存，但是当前流行的地形技术使用的都是一个整张heightmap，而且大量的LOD算法都是基于这个基础上的。使用displacement map的另外一个好处是可以构造更加复杂的地形，这是因为它存在法线的缘故。同时使用displacement map还有一个好处是在将来，因为当前MS已经对displacement map技术进行了支持，现在的问题是GPU在硬件上还不支持，如果一旦硬件支持的话，就有可能将整个地形由GPU来处理，那么对地形渲染的速度和精度会有非常大的提高。
1、what’s Displacement Map
displacemtn map技术是最近几年才出现的一个技术，它出现的初衷是为了解决内存和GPU之间的带宽问题，它开始主要用于高poly角色模型的渲染，由于模型的高数据量会使内存和GPU之间的传输成为瓶颈，因此将其转换为低poly模型和一张displacement传送到GPU中，在GPU中转换为高poly模型进行渲染，可以大大减轻传送的数据量。
但是当前这项技术已经获得非常大的发展，它使用的范围非常大，从室外地形、水面、海洋到室内场景的渲染，它为提高场景的真实度提供了一个有力的工具。一个displacement map通常包含两部分：一张normal map用来保存法线，另一张height map用来保存顶点的偏移。当需要从低poly模型转换为高poly模型时很简单，首先从模型的一个face上获得一个插值点P1，然后从displacement map中获得相应位置的normal和distance，那么新的顶点P2为：
P2 = P1 + normal*distance
关于displacement map的参考文章请看shaderX2中的Displacement Mapping。
2、HL2 Displacement Map Rule
在HL2中displacement map信息被保存在BSP文件中，它有以下几个数据块：
LUMP_DISP_VERTS 保存displacement真实顶点信息
LUMP_DISP_TRIS 保存displacement三角形标识符信息（walkable or buildable）
LUMP_DISPINF 保存displacement 的连接信息
它们保持的信息结构如下：
LUMP_DISP_VERTS：
class CDispVert
{
public:
Vector m_vVector;// Vector field defining displacement volume.
float m_flDist; // Displacement distances.
float m_flAlpha;// "per vertex" alpha values.
};
LUMP_DISP_TRIS：
class CDispTri
{
public:
unsigned short m_uiTags; // Displacement triangle tags.
};
LUMP_DISPINF：
class ddispinfo_t
{
public:
int NumVerts() const{ return NUM_DISP_POWER_VERTS(power); }
intNumTris() const{ return NUM_DISP_POWER_TRIS(power); }
public:
Vector startPosition;// start position used for //orientation -- (added BSPVERSION 6)
int m_iDispVertStart;// Index into LUMP_DISP_VERTS.
int m_iDispTriStart;// Index into LUMP_DISP_TRIS.
int power; // power - indicates size of map //(2^power + 1)
int minTess; // minimum tesselation allowed
float smoothingAngle; // lighting smoothing angle
int contents; // surface contents
unsigned short m_iMapFace; // Which map face this
//displacement comes from.
int m_iLightmapAlphaStart;// Index into ddisplightmapalpha.
int m_iLightmapSamplePositionStart;// Index into.
// LUMP_DISP_LIGHTMAP_SAMPLE_POSITIONS
CDispNeighbor m_EdgeNeighbors[4];// Indexed by NEIGHBOREDGE_ defines.
CDispCornerNeighbors m_CornerNeighbors[4]; // Indexed by CORNER_ defines.
enum { ALLOWEDVERTS_SIZE = PAD_NUMBER( MAX_DISPVERTS, 32 ) / 32 };
unsigned long m_AllowedVerts[ALLOWEDVERTS_SIZE]; //
// This is built based on the layout and
//sizes of our neighbors
// and tells us which
//vertices are allowed to be active.
};
在HL2中规定一个displacement最大由17*17个顶点组成，每一个displacement都将左下角看作是自身坐标系的原点，并按照顺时针方向进行记数。如下：
在ddispinfo_t类中我们可以看到为了记录displacement的邻接关系，它使用了两个数组，m_EdgeNeighbors记录四条边的邻接关系，而m_CornerNeighbors记录了四个角的邻接关系。必须注意的是在HL2中邻接的displacement并不一定都是一样大的，也就是说邻接的displacement不一定是一个，也可以是两个，如果邻接的为两个的话那么邻接的displacement的大小必须小一倍。如下：
在displacement和surface中都有一个变量来指定它们相互之间的对应关系，你可以这样认为，如果一个surface是一个displacement surface的话，那么在surface所保存的顶点信息就是displacement所在的基准面信息，实际上就是记录基准面的四角坐标，当产生实际顶点时过程如下：通过这四角的坐标和displacement的power信息可以插值获得每一个真实顶点的基准点坐标，然后通过CdispVert所保存的信息获得真实的顶点坐标。
3、如何处理地形系统
在HL2中为了高效的渲染地形定义了大量的类，其中最重要的为CdispInfo，它几乎包含了地形的大部分处理，还有一个类CpowerInfo，这是一个予计算的模版类，它预先计算了每一种大小displacement的信息，这样做是为了加速地形的渲染，而类CcoreDispInfo只用来载入数据时使用，它的功能就是将BSP文件中的信息转换为程序可以处理数据。其实在HL2中比较难懂的是它的LOD算法，下面是它具体的算法：
首先是它的更新策略，在正常情况下（LOD的控制台变量为默认值）对displacement的更新有两种情况，它规定了一个更新半径（由控制台变量r_DispFullRadius指定）凡是位于此半径内的displacement的LOD等级都为最大。另外在每次更新时每一个displacement内部都记录了更新时camera的位置，如果当前camera的位置减去上一次更新时camera位置的大小大于一个规定值（由控制台变量r_DispRadius指定），对其进行更新，必须注意的是此时更新的是位于更新半径外的displacement。
下面是它的LOD算法，还是要提醒此时是对更新半径外的displacement进行处理。通常现在LOD算法都是基于距离进行计算的，但是HL2中没有采用这种方法，而是使用一种称为屏幕误差的方法进行。具体方法如下：
首先假设将要更新的displacement位于屏幕的中心，然后求出此时的camera变换矩阵，遍历displacement中的所有顶点（不包含当前displacement的中心点和四个角上的点），对于每一个顶点，用它的坐标和它所在error edge的算术中点坐标相减，然后用这个值和当前displacement的AABB中心点相加，结果通过camera矩阵进行变换然后将X，Y部分分别除以Z值得到的就是这个顶点在屏幕上的视觉误差了。这是一个非常不容易理解的部分，尤其是除以Z值的部分，其实这样做是为了将其投影到Z为1.0的平面上，省略了进行投影变换的过程，提高了效率。当这个误差大于预定义值就将这个顶点渲染出来。
通过上面的介绍可以看出在HL2中并没有象其它LOD算法一样对每一个displacement硬性的规定一个LOD级别，而是通过每一个顶点的屏幕误差来确定它是否可以被渲染，这样做在渲染非常大的地形时效率不会太好，但是在处理HL2这样的小场景时效率确实非常不错。同时也要注意这种地形方法的优点，它非常适合处理落差非常大的室外场景，如地牢围攻这样比较夸张的地形，不过此时就需要对它的LOD算法进行一下改进，另外在HL2中地形一般都比较小，如果地图设计良好的话基本上很少会渲染hidden surface，因此上不需要做地形tile的HSR，而将这种地形系统扩展到无限地形系统时，必然需要使用一定OC算法来做HSR的工作，这可能是将其扩展到无限地形系统的一个非常具有挑战性的工作了。
你是否正在考虑构建一个游戏引擎呢？你对如何构建一个游戏引擎是否已经有了一个明确的
计划呢？你是否已经对如何组织游戏引擎各个模块之间的关系有了一个通盘的考虑？如果没有，
那么本文将对你建立一个良好的游戏架构提出一些有益的方案，如果你已经对上面的问题有了一
个明确的答案，那么本文不是你需要阅读的内容。本文的目的是给那些没有任何建立完整游戏引
擎经验的人提供一些入门性的知识，使他们初步了解一下如何来构建一个游戏引擎，构建游戏引
擎应该注意哪些方面的问题，并提供了一些成熟的设计模版并指出这些设计模版使用的范围，我
希望这些内容对那些中级编程人员也有一个良好的参考作用。本文的内容来源于一些流行的编程
书籍，具体书目请见本文最后的部分，由于本文是介绍性质的文章，因此如果你对哪方面的内容
非常感兴趣请参考相应的书籍，本文或许有很多错误的地方，如果你有什么看法的话可以通
过Email和我进行讨论，我的地址为dreams_wu@sina.com。
这里必须再次提醒你，本文介绍的是一些通用的游戏编程技巧，虽然是通用但是可能并不是
非常全面，可能存在这样或那样的缺陷，因此如果你希望它发挥最大的效用必须恰当的使用它，
而不是不分场合的滥用。切记切记，一个初学者最容易犯的错误就是任意使用一些设计模版而不
顾它的使用范围。
在开始构建一个游戏引擎时你需要先考虑哪些方面的问题呢？这是你必须认真考虑的问题，
我的答案是首先必须考虑代码的可读性，尤其是在多人进行开发时更必须高度重视，如果你写的
代码其他人需要花费非常大的精力进行阅读，那么根本谈不上提高工作效率，下面是提高代码可
读性的一些良好建议：
1、建立一份简单明了的命名规则。一份良好的命名规则可以大幅提高代码的可读性，规则必须
简单明了，通常只需要两三分钟的阅读应该可以让其他人掌握，例如在代码中直接使用匈牙利
命名法这种大家熟知的规则，使用字母I作为接口类的首字母，使用C开头作为实现类的首字母，
使用g_开头的变量名作为全局变量，s_开头作为静态变量名，m_开头作为内部变量名，使用_开
头作为类内部使用的函数名等等，通过名字就可以使你大概了解对象的使用范围和基本功能。
2、不要讨厌写注释。一个编程者易犯的错误就是不写注释，认为它会增加自己的工作量，但是
他没有考虑到相应的工作量已经转移到代码阅读者的身上，可能看代码的人会花费比写注释时间
两倍或者三倍的时间来阅读代码，这是一种非常不负责任的行为，通过一段简短的注释可以使阅
读者迅速的了解代码的功能，从而把时间更多的用到功能的扩展上。下面是一些良好的建议：尽
量对每一个变量标明它的功能。对每一个函数声明的地方标明它的功能，对于复杂的函数还应当
写清参数和返回值的作用，注意是在声明函数的头文件中。在关键的代码处写清它的作用，尤其
是在进行复杂的运算时更应如此。在每一个类声明的地方简要的介绍它的功能。
3、减少类的继承层次。通常对于游戏编程来说每一个类的继承层次最好不要超过4层，因为过多
的继承不仅会减少代码的可读性，同时使类表指针变长，代码体积增大，减低类的执行效率。还
要注意要减少多重继承，因为不小心它会形成编程者非常讨厌的“钻石”形状。同时还要注意如
果能使用类的组合的话那么就尽量减少使用类的继承，当然这是设计技巧的问题。
4、减少每行代码的长度。尽量不要在一行代码中完成一个复杂的运算，这样做会增加阅读难度，
同时不符合现代CPU的执行，由于CPU现在都使用了超长流水线的设计，它非常适合执行那些每行
代码非常短而行数非常多的代码，例如对一个复杂的数学运算，写成一行不如每一步骤写一行。
以上建议是我的一些粗略看法，如果你还有什么好的看法可以给我指出来，同时上面的建议
并不是绝对的，例如类的继承并不是绝对不能超过4层，如果你需要的话可以使用更多的继承，前
提是这样带来的好处大于代码执行效率的损失。
接着看看要考虑什么，在Game Programming Gems3的《一个基于对象组合的游戏架构》一文
指出了几个值得考虑的问题，首先是平台相关性与独立性和游戏相关性与独立性的问题，也就是
说应当作到引擎的架构与平台和游戏都无关。为什么要做到与平台无关性呢？这是因为你必须在
开始架构引擎考虑它的可移植性，如果在开始你没有注意到这个问题，那么一旦在游戏完成后需
要移植到其他的游戏平台上，你会发现麻烦大了，你需要修改的地方实在是太多了，所有与平台
相关的API调用都需要修改，所有使用了平台特定功能的模块也需要修改，这是一个非常耗费精力
的事情，可能需要花费和开发一个游戏一样的时间，而如果你在开始的时候就考虑到这个问题，
那么非常简单，只需要写一个相应平台的模块替换掉原来的模块即可，这样精力就可以放在如何
充分的利用特定平台的能力来提高游戏的表现力上，而不是代码修改上。下面简单的谈一下如何
使引擎作到与平台无关。
1、注意操作系统的差异。现在主流的操作系统主要是Windows和Linux两种，当然还有Unix和Mac
，在编程时你必须注意这一点，当你需要包含Windows的头文件时，你必须将它包含在宏_WIN32
中，下面是一个简单的例子：
#ifdef _WIN32
#include "windows.h"
#endif
而你使用Windows平台特定的API时也应当如此，这样在其他平台上编译时可以保证Windows平台
相应的代码不会被编译进去。对于其他平台也应当如此。
2、注意编译器的差异。现在通用的编译器主要有VC，BC和gcc几种，在进行Windows平台编程时，
你通常会使用VC或BC，而对Linux平台编程时通常使用gcc，使用VC编译器你不可能编译出用于Linux
平台的代码，因此在编程时也需要注意，你可以使用上面的方法通过特定的宏来将不同的编译器
分离开。举一个简单的例子：
#ifdef _WIN32
#ifdef _MSC_VER
typedef signed __int64 int64;
#endif
#elif defined _LINUX
typedef long long int64;
#endif
在不同的编译器中对64位变量的命名是不同的，因为它并不是C++标准的一部分，而是编译器的扩
展部分。另外一个例子是编译器使用的内联汇编代码，在VC中你可以使用_asm来指明，而对于
Linux平台的编译器你需要使用它的专用关键字了。
3、注意CPU的差异。对于不同平台来说它通常会使用不同的CPU，不过幸好Windows和Linux都支持
X86的CPU，这也是PC游戏的主流CPU平台，而XBOX使用的也是X86的CPU，除非你需要移植到PS2平台
，否则这将大大减轻你的编程负担，在X86平台上提供了一个cpuid的指令可以非常方便的检查CPU
的特性，如是否支持MMX，SSE，SSE2，3DNow!技术等，通过它你可以使用特定的CPU特性来加速你
的代码执行速度。
4、注意图形API的差异。现在图形API主要存在两种主流的平台DirectX和OpenGL，DirectX只能用于
Windows平台，而OpenGL几乎被所有的平台所支持。因此你需要为不同的图形API进行封装，将它做
成不同的模块，在需要的时候进行切换。完成这个工作最好的方法是使用后面介绍的类厂模式。
5、注意显卡的差异。现在显卡有两大主流ATI和NV，虽然显卡可以被主流的操作系统所支持，但是
必须注意在不同的游戏平台上还是使用不同的GPU，而在GPU之间也相应有自己的功能扩展，因此在
使用特定的扩展功能时必须检查一下是否被显卡所支持。
6、注意shader语言的差异。可编程图形语言的出现是最重要的一项发明，现在几乎每一个游戏都
在使用这项技术，而正由于它的重要性现在出现了多个标准，HLSL只能用于DX中，而OpenGL由于
标准的开放性更加混乱，每一个显卡厂商都根据自己的产品推出相应的扩展指令来实现shader，
而NV更推出了GC可以同时适用于DirectX和OpenGL，这是一个非常好的想法，不过由于这不是一个
开放的标准因此没有得到其他厂商的支持，在ATI显卡上运行GC代码你会发现比在NV显卡慢了几个
数量级，由于上面的情况你需要根据不同的平台相应进行封装，方法和第4条一样。下面的建议值得
你去考虑，当你使用DirectX平台时应当使用HLSL，而对于OpenGL可以封装为两个模块，根据显卡
的不同进行切换，也可以使用GC特别为NV的显卡封装一个模块来对它进行优化。
这里需要补充一点，如果可以的话尽量和OGRE一样为不同的操作系统进行封装，这样方便在
不同的系统之间进行切换。
接着看看如何实现游戏无关性，通常游戏引擎如果要实现游戏的无关性是非常困难的，这也就
是说要求你的引擎适合所有的游戏类型，这太难了，考虑一下一个RPG游戏引擎如果用来做一个RTS
游戏那简直是不可能，类似的你不可能拿Q3引擎来做RTS游戏，但是如果引擎设计的非常良好的话
还是可以实现部分的游戏无关性。也就是说你可以将引擎的一部分模块设计成通用的模块，这样在
开发其他类型的游戏时可以重用这部分的代码，这部分代码包括底层显示，声音，网络，输入等
部分，在设计它们时你必须保证它们具有良好的通用性。
在这些问题之后你应当考虑程序的国际化问题。这也是非常重要的方面，因为你的游戏可能在
其它国家发行，这主要是注意语言方面的问题，尤其是字符串的处理，在C++的标准库中提供了一个
String容器，它提供了对国际化的良好支持，因此在引擎中你需要从头到尾的使用它。
接下来我们看看本文最重要的内容，如何组织一个引擎的架构。这是引擎最重要的部分，为什么
重要呢？如果我们把引擎看作一间房子的话，那么架构可以看作是房子的框架，当你完成这个框架
后就可以向框架内添砖加瓦盖房子了。下面让我们来看看如何构建这个框架，通常一个大型的软件
工程是按照模块化的方式来构建的，编程之前要进行必要的需求分析，将软件工程根据不同的功能
划分为几个较大的功能模块，对比较复杂的模块你可能还需要将它分为几个子模块，并需要给出各
个模块之间的逻辑关系。当你编写一个引擎时也需要进行相应的功能分析，让我们看看如何来划分
引擎的功能模块，如果按照上面的游戏无关性和相关性进行分析的话我们可以发现它可以分为游戏
相关层和无关层两层，游戏相关层由于包含了游戏的逻辑性代码也被称为逻辑层。逻辑层应该位于
引擎的最顶层，如果你在开发一个局域网或在线游戏的话，按照网络程序的C/S开发模式，这一层
应该分为两个模块，服务器和客户端模块,它包含了和特定游戏相关的所有功能，如AI，游戏角色，
游戏事件管理，网络管理等等。在它下面就是游戏无关层了，包括了引擎核心模块，GUI模块，文件
系统管理模块等等，其中引擎的核心模块是最重要的部分，逻辑层主要通过它来和底层的模块打交
道，它应该包含场景管理，特效管理，控制台管理，图形处理等等内容。在向下就是一些底层模块
了，如图形渲染模块，输入设备模块，声音模块，网络模块，物理模块，角色模型模块等等，所有
的这些底层模块必须通过核心模块来和逻辑层进行交互，因此核心模块是整个引擎的枢纽，所有的
模块都通过它来进行交互。
下面看看应该如何来进行模块的设计，这里有一些通用的规则是你应当遵守的：
1、减少模块之间的关系复杂度。我们知道通常每一个模块内部都存在大量的对象需要在各个模块
之间进行相互的调用，如果我们假设每一个模块内部对象的数量为N的话，那么每两个模块之间的
关系复杂度为N*N，这样的复杂度是不可接受的，为什么呢？首先是它非常不利于管理，由于各个
模块都存在大量的全局对象，并存在相互依存的关系，并且各自建立的时间各不相同，这就存在
初始化顺序的矛盾，考虑这种情况，一个模块中存在一个对象需要另外一个模块中的对象才能进行
初始化，当这个对象进行初始化时而另外的对象在之前并没有初始化就会引发程序的崩溃。其次，
不利于多人进行同时的开发，由于各个模块存在相互依存的关系，当复杂度非常高时就会出现模块
与模块的高度依存，也就是说一个模块没有完成下一个模块就无法完成，因此就需要一个模块一个
模块按照它的依存关系进行编程，而无法同步进行。因此在设计模块时的第一件事情
是减少模块之间的复杂度，为此你在设计模块时必须为模块设计一个交互接口，并约定所有模块之
间的交互必须通过这个接口来进行，这样模块之间的关系复杂度就降低为1*1了，非常方便管理，同
时这非常利于多人之间进行开发，假如每个人负责一个模块的开发的话，那么你只需要先完成这个
接口类，其他人就可以利用这个接口进行其他模块的开发，而不必等到你完成所有的类再进行，这
样所有的模块都是同步进行，可以节省大量宝贵的开发时间。
2、对类的抽象接口而不是类的实现编程。这是《Design Patten》一书作者对所有软件编程者的建议
，它也对游戏编程有很大的指导意义。对模块中所有被其它模块使用的类都要建立一个抽象接口，
其它模块要使用这个抽象接口进行编程，这样其它模块就可以在不需要知道类是如何实现的情况下
进行编程。这样做的好处是在接口不改变的情况下任意对类的实现进行改变而不必通知其它人，这
对多人开发非常有用。
3、根据调用对象的不同对类进行分层。实际上本条还是对第2条的补充，分层还是为了更好隐藏底
层的实现。通常一个类不仅被其它模块使用还要被自身模块所调用，而且它们需要的功能也不同，
因此我们可以让一个类对外部显现一个接口而对内部也显现一个接口，这样做的好处和上面一样，
因为一个复杂的模块也是多人在进行编程的。
4、通过让一个类对外显现多个接口来减少类的数量。减少关系复杂度的一个方法是减少类的数量，
因此我们可以把完成不同功能的类合并成一个类，并让它对外表现为多个接口，也就是一个类的
实现可以继承多个接口。
上面的建议只是起到参考作用，具体实现时你应该根据情况灵活使用，而不是任意乱用。
下面的内容涉及到具体的编程技巧，
对于引擎中的全局对象你可以使用Singleton，如果你不了解它是什么可以阅读《Design Patten
》，里面有对它的详细介绍，具体的使用可以通过OGRE引擎获得。
调用模块内的对象可以通过类厂来实现。COM可以看作是一种典型的类厂，DX就是使用它来进行
设计的，而著名的开源引擎Crystle Space也是通过建立一个类似的COM物体来实现的，但是我并不
对它很认可，首先构建一个类似COM的类厂非常复杂，开销有点大，其次COM的一个优点是可以对程
序实现向下兼容，这也是DX使用它的重要原因，而一个游戏引擎并不需要。OGRE中也实现了一个类厂
结构，这是一个比较通用的类厂，但是使用起来还是需要写一段代码。我比较欣赏VALVE的做法，它
通过使用一个宏就解决了这个问题，非常高效，使用起来也非常方便。这个做法很简单，它把每个
模块中需要对外暴露的接口都连接到一个内部维护的链表上，每一个接口都和一个接口名相连，这
样外部模块可以通过传入一个接口名给CreateInterface函数就可以获得这个接口的指针了，非常简
单。下面看看它的具体实现。它内部保存的链表结构如下：
class InterfaceReg
{
public:
InterfaceReg( InstantiateInterfaceFn fn , const char *pName );
public:
InstantiateInterfaceFn m_CreateFn;
const char *m_pName;
InterfaceReg *m_pNext;
static InterfaceReg *s_pInterfaceRegs;
};
并定义了两个函数指针和一个函数
#define CREATEINTERFACE_PROCNAME "CreateInterface"
typedef void *(CreateInterfaceFn)( const char *pName , int *pReturnCode );
typedef void *(InstantiateInterfaceFn)( void );
DLL_EXPORT void *CreateInterface( const char *pName , int *pReturnCode );
下面看看它如何通过宏来建立链表
#define EXPOSE_INTERFACE( className , interfaceName , versionName ) \
static void *__Create##className##_Interface() { return (interfaceName*) new className; } \
static InterfaceReg __g_Create##interfaceName##_Reg( __Create_##className##_Interface , versionName );
如果你有一个类CPlayer它想对外暴露接口IPlayer，那么很简单，可以这么做
#define PLAYER_VERSION_NAME "IPlayer001"
EXPOSE_INTERFACE( CPlayer , IPlayer , PALYER_VERSION_NAME );
如果在其他模块内你需要获得这个接口，可以这么做
CreateInterfaceFn factory = reinterpret_cast<CreateInterfaceFn> (GetProcAddress( hDLL , CREATEINTERFACE_PROCNAME ));
IPlayer player = factory( PLAYER_VERSION_NAME , 0 );
其中hDLL为模块的句柄。这里函数指针factory实际指向模块内部的CreateInterface函数，这个
函数通过比较传入的接口名从链表找到指定类指针。
解决了类厂问题，下面让我们看看如何建立模块对外的接口，在Game Programming Gems3的
《一个基于对象组合的游戏架构》一文提出了一种架构，Half Life2引擎中对这种架构进行了有效
的扩展，你可以让所有的对外暴露的接口都使用这个架构，前提是模块只有一个接口对外暴露。
class IAppSystem
{
public:
// Here's where the app systems get to learn about each other
virtual bool Connect( CreateInterfaceFn factory ) = 0;
virtual void Disconnect() = 0;
// Here's where systems can access other interfaces implemented by this object
// Returns NULL if it doesn't implement the requested interface
virtual void *QueryInterface( const char *pInterfaceName ) = 0;
// Init, shutdown
virtual InitReturnVal_t Init() = 0;
virtual void Shutdown() = 0;
};
通过Connect方法你可以将两个模块建立一个连接关系，通过QueryInterface方法你可以检索到其他
需要暴露接口，这种方法很好的为所有的模块建立一个标准的对外接口，极大的减轻了编程的复杂
性，遗憾的是在HL2引擎中只有部分模块使用了这个方法，可能是这个接口引入时间太晚的缘故。
（待续）
对于现代的游戏引擎来说，为了提高性能和有效的管理内存，需要使用各种各样
的内存分配模型，内存池作为一种有效的分配模型被大量的使用，它通过一次分配
足够的内存来减少对new delelte使用以提高引擎的性能，并且由于每一个内存块
都有相同的大小因此非常易于管理，并可以防止内存的泄露。它通常被用于需要
分配大量相同对象的场合，如粒子系统这样的地方。
对于在运行时可以明确知道分配数量的物体，可以通过一个静态数组来实现它，
但对于不知道分配数量的地方，设计就变的有些复杂，通常需要使用一个链表来
进行实现，如STL的list容器，不过使用它有一个很大的缺点，链表对表中的对象
进行查询操作时速度不是很理想，会极大影响它的性能。因此需要寻找一个比较
好的方法对其进行改进。
通常设计内存池有两个问题必须考虑，一个是内存分配的策略，由于你不是明确
知道待分配物体的数量，因此每次分配多大数量的内存是一个值得注意的问题。
另一个是如何对内存池进行管理，使用什么样的数据结构才能在常数时间内来获得
指定的内存。对于第一个问题解决的方案很多，你可以每次都分配一个指定数量
的内存块，也可以在每次分配时都分配比上一次多一倍的内存，哪种方案更好，需要
你自己在实际使用中体会。第二个问题是本文的核心，一般的做法是将已经分配的
内存块分成两个部分，已使用和未使用两个链表，但是这样做的性能并不理想，下面
看看如何对其进行改进：
我们先建立一个结构用于保存每次分配的一整块内存：
sturct MemChunk
{
MemChunk* m_pPre;
MemChunk* m_pNext;
unsigned int m_nSize;
char m_Data[1];
}
在这个结构中m_pPre，m_pNext用于建立一个双向链表将每一次分配的内存连接起来，
m_nSize表示当前内存块的大小，m_Data是所分配的内存指针，必须注意这是一个BYTE
指针。我们现在假设当前的内存池用于对CObject物体分配内存，每次分配都一次分配
64个CObject物体的内存，因此m_nSize的大小为64*sizeof(CObject)。下面看看如何
保存未使用的内存块，我们需要一个指针来指向当前未使用的内存块。
void* s_pCurrent;
然后令它指向当前还未使用的内存块。
s_pCurrent = pMemChunk->mData;
下面是本文最关键的部分，为了提高性能我们令每一个未使用的内存块的头部都保存
一个指针，让它指向下一个未使用的内存块，这样就为未使用的内存块形成了一个单
向链表。当你需要一个物体的内存时可以这么做：
void* returnPtr = s_pCurrent;
s_pCurrent = *((void **)s_pCurrent);
return returnPtr;
这样returnPtr就是你要获得的内存指针，而s_pCurrent通过一个简单的指针转换巧妙
的又指向了下一个内存块，如果上一句看不懂，请你重新复习一下C++教材中关于指针
的解释。
当你需要释放一个物体的内存时，方法和此类似。
*((void**)pMem = s_pCurrent;
s_pCurrent = pMem;
这样就可以将内存块重新连接到未使用的内存块链表中。通常对指针进行转换的时间
非常短，比一般的链表的插入、删除操作速度快的多，因此这个技巧是非常值得借鉴
的做法。
在我翻译的《BSP技术详解》一文中对radiosity技术介绍的非常简单，而且很多地方都没有解释清楚，下面我将
结合自己研究的结果对如何在BSP场景中进行radiosity做一下介绍，这里只介绍关键的步骤，至于详细的实现细
节请自己参考相关的代码。
通常如果需要在一个构建好的BSP场景中进行radiosity计算大概需要下面的几个步骤：
1、将场景中每一个face分解为patch；
2、对每一个patch构建一个sample数组；
3、获得每一个patch的基本光照值；
4、对patch进行supersample操作；
5、通过pvs数据获得patch之间的可见性关系，为每一个patch建立一个可见patch列表；
6、在所有的patch之间模拟能量传递的过程，进行radiosity运算。
下面我对每一个步骤分别进行介绍。
第一步，在进行radiosity运算时能量传递是在patch之间进行的，因此需要将每一个face分解为patch，为了建立
patch需要确定patch最大size，它由引擎定义的lightmap最大size来决定，在ID系列引擎这个值定义为64，因此
patch在任意轴上的size不能超过64，知道这个值就可以建立patch了，为了方便管理，首先为每一个face建立一个
初始的patch，然后检查每个face在轴向上的size，如果大于64就沿最长轴对patch分割，获得两个子patch，接着
对子patch重复上面的过程直到face上所有的子patch在任意轴上的size都不超过64为止。当获得patch后需要计算
每一个patch的normal，注意face上的所有patch不能都使用face的normal，应该使用一种phong normal的算法来
获得，为了使用这种算法，应该从face上最顶层的root patch开始进行计算，对于root使用face的normal，接下来
计算两个子patch，计算子patch的normal时就需要使用phong normal了，方法很简单，通过比较子patch中心点
坐标和parent patch中心点的坐标获得一个权值，然后用这个权值在patent patch的normal和子patch上的所有
顶点的normal进行插值获得patch的phong normal。
第二步，在lightmap中每一个pixel被称为luxel，计算lightmap实际上也就是获得每个luxel的颜色值，因此首先
需要为每一个patch建立一张lightmap，然后为lightmap中的每一个luxel建立sample结构。这个过程并不太复杂
，在ID的引擎中每一个顶点并不存在纹理坐标这样的东西，它为每一个face都建立纹理坐标系和lightmap坐标系，
如果需要获得顶点对应的纹理坐标和lightmap坐标，只需要将顶点坐标通过矩阵变换到纹理空间就可以获得了，
现在为了获得patch的sample结构，首先应该获得每个patch的lightmap坐标系，注意这样作的原因是因为每个
patch的normal是phong normal，而不等于face的normal。获得patch的lightmap坐标系后获得patch上的每个顶点
的lightmap坐标，好了获得lightmap坐标之后就可以知道patch上到底存在多少个luxel了，然后沿着lightmap的
坐标轴对patch进行分割，建立和luxel同等数量的sample结构。
第三步，当上面的结构都建立起来后需要获得每个patch获得直接光照的lightmap，首先需要获得场景中所有的
灯光，然后对每一盏灯光做以下处理：
1、获得灯光D所在的cluster A索引；
2、通过pvs获得A所有可见的cluster；
3、遍历所有可见cluster中的每一个face上的每一个sample，检查其是否可以被灯光照亮，如果可以使用标准
的光照公式获得luxel的颜色值。
第四步、为了使patch上的lightmap看起来更加自然，剔除lightmap上的光斑和硬边需要对其进行supersample
操作，首先对每一个sample的颜色和相临8个sample的颜色进行比较，如果大于一个阀值，说明它需要进行
supersample操作，否则不需要。对于需要进行supersample操作的sample,首先将其颜色清空，然后根据其所
受到的光照类型分别处理，对于受到的环境光源按照正常方式进行计算，因为环境光源不需要进行supersample
处理，对于其他非环境光源需要进行supersample处理，通常在进行光源计算时我们使用的是sample的中心点
坐标，但是在做supersample时不能这样做，我们需要使用组成sample的顶点坐标进行计算，在前面进行分割
时我们将patch分割为一个一个sample，sample其实就是一个非常小的矩形patch，它由四个顶点构成，现在
为了做supersample需要计算出四个顶点的normal，然后计算每个顶点受到光照的颜色值，使用它们的算术平均
值作为sample的颜色值。
第五步、好了现在需要进行radiosity前的最后一步，因为radiosity的过程是在场景中所有patch之间进行不断
的能量传递的过程，直到在所有patch上的能量获得平衡为止，由于patch的能量只能从其可见的patch中获得，
因此需要获得每一个patch的所有可见patch列表，通过使用pvs数据可以快速的获得可见patch列表，并通过列表
获得其形状因子。
第六步、现在可以对场景进行radiosity运算了，首先将场景中的所有灯光剔除，接着将每一个patch所获得的
初始光照值做为每个patch需要发射的能量，换句话说就是将每一个patch都看作是场景中的灯光，而patch的
初始光照值作为灯光的光照值，好了，对于每一个patch来说都需要进行以下的步骤：
1、遍历可见patch列表，使用标准的光照公式计算从可见patch上获得的光照值并保存起来。
2、第一步完成后，接着使用从可见patch上获得的光照值作为每个patch的需要发射的能量，重新进行第一步。
3、当有patch需要发射的能量小于一个预定义的阀值将这个patch推出radiosity运算。
从上面的介绍可以看出整个radiosity运算最耗费时间的是在最后一步，因此为了提高运算速度可以使用多线程
技术（注意超线程技术对它并没有帮助）和分布式运算技术来进行优化，同时也可以使用逐步求精的算法来对
运算进行加速。
在.bsp文件中用于可见性检测的信息被保存在一串串的字节中，而字节中每一位表示一个cluster，这是因为在BSP树中进行可见性检测的PVS信息数量非常大，而使用这个方法可以做到快速进行存取并使保存的信息量变的很小。下面是这个结构的一个实例，你可以通过两个方法来计算需要读入的字节数：用numOfClusters* bytesPerCluster；或用这个结构的长度减去两个整型字节。结构中的pBitsets是动态进行分配的并保存了所计算的字节数。这个结构或许是.bsp文件格式中最不容易理解的部分了，下面我将结合一些代码进行详细的介绍。
struct tBSPVisData
{
int numOfClusters; // clusters的数量
int bytesPerCluster; // Bytes (8 bits) in the cluster’s bitset
byte *pBitsets; // Array of bytes holding the cluster vis.
};
为了演示cluster是什么和怎么来使用它，我们来举一个简单的例子，当我们进行渲染时，首先我们需要知道自己处于哪一个叶节点中，在BSP树的叶节点中保存了一系列关于面、brush和它所位于的cluster的信息，一旦它通过用摄象机的位置与分割面进行比较被检测出来，我们需要遍历所有的叶节点来检查哪些cluster对于我们所处的cluster是可见的，检测完成后，用cluster的包围盒与摄象机的可视平截体进行检测，对在摄象机可视范围内的cluster进行渲染。
假如现在有cluster A、B、C，每一个cluster作为位集合中的一位保存在位集合中，一个位集合是一个巨大的二进制数列表，每一个cluster都保存了一个位列表，每一位上的1或0表示在列表上所代表的cluster是可见（1）还是不可见（0）。由于大部分情况下一个地图上有超过32个的cluster，因此不能使用一个32位的整型数来进行表示，这也是为什么在cluster使用多个bytes数来进行表示。接着让我们看一下它是如何工作的。
对于cluster A、B、C，下面显示了在一个位集合中如何对它们进行表示：
l ABC
l 000
上面每一个0表示了一个cluster的位置，现在让我们假设
1. clusterA可以看见B但不能看见C；
2. clusterB可以看见B和C；
3. clusterC可以看见B但不能看见A。
下面是每一个cluster所保存的位集合：
l A 110
l B 111
l C 011
这是什么意思呢，对于cluster A来说，第一位为1这表示它自己是可见的，而第二位为1表示cluster B对于它来说也是可见的，但是第三位为0则表示cluster C由于墙壁或其它物体的阻挡导致它对于cluster A是不可见的。采用这个方法可以获得非常好的速度。
去检测一个cluster相对于其它cluster是否可见，可以通过进行移位和简单的位运算来获得，基本的法则如下：
int visible = pBitsets[currentCluster*bytesPerCluster + ( testCluster/8 )] & (1 << (testCluster & 7))
如果返回的结果不为0，则表示testCluster对于currentCluster来说是可见的。公式中我们除以8是因为我们使用的是8位的字节来保存PVS数据的。在上式中的第一部分是通过索引cluster数组来获得正确的位集合，接着使用一个二进制与操作来获得正确的结果。下面是进行具体检测的代码：
inline int IsClusterVisible(tBSPVisData *pPVS, int current, int test)
{
if(!pPVS->pBitsets || current < 0) return 1;
byte visSet = pPVS->pBitsets[(current*pPVS->bytesPerCluster) + (test/8)];
int result = visSet & (1 << (test & 7));
return ( result );
}
当前对于流行的第一人称游戏来说，将室内场景渲染和室外场景渲染进行融合是主流的趋势，本文试图从
场景架构入手对当前流行的两个游戏引擎Far Cry和Half Life2进行一些非常浅显的介绍、分析、比较，
由于本人学识浅薄，本文中可能存在一些错误之处，请大家予以谅解，并请高手给予指正。
在过去由于硬件发展的限制因此第一人称游戏只能在室内场景进行，随着硬件技术的发展它逐渐由室内向
室外场景进行过渡，发展到现在已经有大量的游戏可以同时对室内和室外场景进行渲染，当前这类游戏的
代表就是Far Cry和Half Life2，它们完全使用了两种不同的方法来实现室内外场景的融合。
Far Cry：
Far Cry将场景分为室内和室外两部分，对于室内场景它使用了流行的BSP方法来对场景进行组织，BSP方法
在网上有大量的资源可以进行参考，这里我不在进行详细的阐述，在Half Life2部分我再进行一些简单的
介绍，这里我将重点介绍一下它室外场景部分所使用的技术。通常对于室外场景部分最重要的是地形部分
的渲染，当前对地形的渲染存在着大量的算法，其中比较主流的有ROAM、GeoMipmap、Chunk LOD等等，
Far Cry并没有使用上述的算法，为什么呢？对于ROAM来说它确实是一种非常良好的地形渲染解决方案，
但是它存在一个非常大的弊端就是它的灵敏度非常高，因为它是一种连续的基于三角形分割的LOD算法，
因此只要Camera的位置发生很小的位移，整个场景的LOD都需要发生变化，这非常不适应于当前的硬件架构
。而对于GeoMipmap这种利用当前显卡高渲染速度通过增加填充率来加速地形渲染的方法其实也不符合
当前游戏引擎的发展方向，正是由于这些方法的限制Far Cry使用了一种比较折中的地形渲染方法，这种
方法非常类似与Game Programming Gems2中Greg Snook提出的Interlocking Tiles方法，但是还存在着
一些相差别的地方，在Far Cry的关卡编辑器SandBox中我们可以看到通常它使用的是1025*1025大小的
HeightMap，每一个Tile的大小为(32+1)*(32+1)，存在4级的LOD，因此一个Tile最简化时的大小为(4+1)
*(4+1),对于不同LOD级别Tile的连接使用了和Interlocking Tiles一样的方法，使用固定的连接模版进行
连接，这里两者差异最大的地方是对Tile内部三角形的生成方式，对于Interlocking Tiles方法它使用
的类似于以前CLOD的方法，分割后的形状象是一个“米”字的形状，而Far Cry的分割方式是对角分割线
的方向都是一致的，这样做的好处是非常容易生成Trigle Strip。好了现在我们看看使用这种方法有那些
优点。其一，由于每一个Tile只存在4级LOD因此避免了ROAM那种灵敏度过高的弊端。其二，由于地形是由
一个个Tile构成，因此非常适合使用Quad Tree这样的结构来进行管理。其三，由于每一级LOD的Tile顶点
顺序都是固定的，因此可以对地形顶点数据进行预先的优化，如提前就可以确定生成Trigle Strip的索引
缓冲区。其四、可以使用预先计算好的LOD查找表的方法来获得每一个Tile的LOD级别，而不需要通过实时
计算来获得。这种方法还有许多其他的优点需要实际使用时认真的体会我就不再一一列举了，Far Cry在
对地形进行渲染时还使用一种OC方法来对地形中被遮挡住的Tile进行剔除，相关的论文请参考A.James
Stewart发表于Eurographics Rendering Workshop的论文Hierarchical Visibility in Terrains,june
1997，我不再进行介绍。当Far Cry需要同时对室内外场景进行渲染时，它使用portal来对场景进行渲染，
如果从整体上来说的话，Far Cry的做法是对室内外场景的渲染分别进行处理，它们完全是两个部分，当
这两个部分需要发生联系时，通过portal来进行处理，这样Far Cry的场景架构就显得非常简单明了，至
于portal的工作过程我后面再进行介绍。下面来看看Half Life2的做法。
Half Life2:
在介绍Half Life2架构之前，我需要先解释一下surface的概念，因为Half Life2的场景都是由surface
所组成，它是场景中最基本的图元。surface是由共处于一个平面上多个顶点所组成的物体，例如一面
墙我们可以称它为surface，因为组成墙的所有顶点位于同一个平面内。通常在Half Life2中把surface
分为四类：水面、水面之上、水面之下、横跨水面。了解了surface的基本概念，下面看一下如何进行
场景处理。在Half Life2中场景被分为三部分：cluster,area,displacement。其中cluster对应于室内
场景的处理，area对应于类似于城市这样建筑物众多的室外场景，displacement对应于地形这样的室外
场景。必须注意的是在Half Life2中对所有的场景都使用BSP来进行场景管理，而不是象Far Cry那样
分别进行处理，它是如何实现的呢，下面我们根据不同的场景分别进行介绍。
对于cluster这样的室内场景，使用最基本的BSP方法来对场景进行管理，也就是基于多边形对齐的BSP
算法，什么是cluster呢？实际上一个房间就可以看作是一个cluster，一个cluster是有严格的定义的，
它必须保证组成cluster的多边形形成一个“凸”物体，也就是组成cluster的任意两个顶点之间的直线
不能位于cluster的外面，一个室内场景完全由一个一个的cluster所组成，cluster之间通过portal进行
连接，房间中的门、窗户都可以看作是一个protal，它是由处于同一个平面上的多个顶点组成的闭合的
多边形，通过使用portal可以对每一个cluster做光线跟踪处理，获得在每一个cluster上可见的cluster
列表，这就是PVS数据了，室内场景在实际运行时可以通过PVS数据快速的进行可见性检查，剔除不可见
的cluster来加速场景的渲染。室内场景中的portal通常是由程序自动生成的，相关的算法非常多，一篇
非常好的参考文章是位于GameDev.net上的由国人胡灵和李振霄所写的Automatic Portal Generation，
非常佩服，这是我在gamedev.net上看到的第一篇由中国人所写的技术文章。当获得了场景的cluster
信息后就可以将它和BSP的节点信息相连了，由于portal必然处于节点的分割面上，因此这一步非常简单。
下面看看如何处理城市这样的室外场景，这类场景由于拥有大量的建筑物并将场景分割成一块一块的区域
，因此也可以使用上面处理室内场景的方法来对它进行处理。这方面的论文也有很多，比较好的一篇是
由Alon Lerner等人写的Breaking the Walls: Scene Partitioning and Portal Creation。我这里只是
简单的介绍一下，这类场景可以看作是由一个个的area组成，area的概念非常类似cluster，一条街道，
一栋楼房都可以看作是一个area，这里必须提醒一下组成area的surface的法线必须指向其内部，cluster
也是这样，因此街道这样的area是由楼房的外表面所组成，而楼房这样的area是由其内表面所组成。每
一个area也是通过portal进行连接，对于这样的场景不能再使用预计算PVS的方法进行可见性检查，而
需要通过使用portal对场景进行实时的剪切剔除运算，必须注意这里对portal的记录方式，在室内场景中
的portal通常需要记录它所连接的两个cluster，而这里的area portal只记录一个与其相连的area，也就
是这里的portal都是单向的，这样做的原因是为了方便进行area的可见性检查，只要知道portal可见那么
和其相连的area一定可见。area和cluster存在一个非常大的差异地方是area不再必须是一个“凸”物体，
它可以是任意的由surface组成的一个空间，因此如果对这样的场景进行BSP分割后，一个area可能只包含
一个叶节点，也可能是包含多个叶节点的完整BSP子树。对于area进行处理时还有一种特殊的情况，就是area
和cluster发生连接时，通常这个时候cluster被包含在area内部，例如对于场景中的一栋建筑物可以看作是
一个area，通向外部的门、窗可以看作是此area的portal，这个建筑物的内部可以看作是一个完整的室内场
景，形成一个BSP子树，这样通过portal可以巧妙的将两种场景融合到一起。下面具体看看如何通过portal
来对area进行可见性检查，需要注意一点area没有AABB，而只有portal和叶节点才拥有AABB，方法如下：
1、由摄象机所位于的area出发递归遍历场景中所有的area portal，检查哪些portal是可见的（使用简单的
frustum culling），通过这些portal我们可以获得一个当前可见area列表。
2、对于所有可见的portal将其顶点投影到屏幕上，获得它在屏幕上的一个包围框。
3、对portal在屏幕上的包围框使用视口的包围框进行剪切，获得portal包围框在当前视口完全可见的部分。
4、通过使用这个包围框可以获得一个frustum，这样每一个可见的portal都可以对其相连的area所包含叶节
点的AABB进行frustum culling运算，从而最终获得一个当前可见的叶节点列表（当然对当前所在的area所
包含的叶节点也需要进行frustum culling）。
最后来看看HL2是如何来处理地形这样的大动态场景的。HL2处理地形使用的是一种非常特殊的displacement
系统，现在heightmap是记录地形信息最流行的做法，但是HL2并没有使用这种方法，他使用了一种称为
displacement map的物体来记录地形信息，为什么这样做呢？根据我的看法主要有以下的原因：首先使用
heightmap记录地形信息其实有一个非常大的弊端，它不能处理非常复杂的地形，用它生成的地形都是连续
的，这是因为在每一个位置它只能记录一个高度值，当同一个位置发生高度重叠时它无能为力。其次我前面
介绍过HL2场景完全是由surface所组成的，使用heightmap你无法将地形信息和surface相连，而通过使用
displacement map可以简单的将地形信息和surface连接起来。下面我们具体来看看它是如何工作的，通常
一个displacement map对应一块地形，它最大可以表示(16+1)*(16+1)这样的地形块，它非常类似heightmap，
不过heightmap只记录每一个位置上的高度值，而displacement map不仅记录高度值而且记录每一点的法线，
由于法线的存在它就可以记录非常复杂的地形，不过displacement map存在一个限制，它的四角的顶点必须
位于同一个平面上，正是这个限制的存在从而使displacement map和surface巧妙的联系在一起，因为surface
上的所有顶点必须位于同一平面上。每一个displacement map不仅记录高度信息还记录了邻边和邻角的
displacement map信息，通过这些信息可以对一片地形快速的建立一个Quad tree，通过它来对地形进行
有效的管理。每一个displacement map都拥有四级LOD，从(2+1)*(2+1)到(16+1)*(16+1)。下面来看看HL2
是如何将地形和BSP相联系的，对于一片地形我们可以把它看作是一个area，这样与其它场景可以通过portal
相连接起来，而每一个displacement map你可以把它看作一个BSP的叶节点，通过前面建立的Quad tree，
你可以快速的将它转换为BSP tree（其实这一步不是必须的，你只需要知道displacement map和叶节点的
连接关系即可），当进行地形的可见性检查时使用Quad tree进行，最终还是可以获得一个可见的叶节点
列表。
通过上面的介绍可以看出Far Cry和HL2的场景架构差异是非常大的，Far Cry的各个场景之间是完全独立的，
而HL2则巧妙的将其融合到BSP格式中，形成了架构的统一性。正是因为如此使HL2对付任意的场景都应付自如
，而Far Cry却只能限制游戏的场景形式，因此HL2的游戏架构明显优于Far Cry，成为了3D引擎发展的主流
趋势，不过Far Cry在一些场景细节上的处理确实非常优秀，如海岸边的潮起潮落，这是HL2需要明显改进的
地方，不过HL2在光源处理上确实是技术超群，全lightmap光照架构，将lightmap应用到极至的bumped lightmap
技术，只能是令人叹服，这里不再一一列举，我只能说HL2是当前商业引擎中的NO.1。
由于行文仓促，难免存在许多错误，尤其是HL2的地形部分由于我还没有完全研究透彻，因此避免不了会出现
错误，请研究HL2的高手给予指正，我这里表示感谢，如果你有什么关于HL2的技术问题希望和我进行交流，
我非常欢迎你发送邮件到我的邮箱dreams_wu@sina.com
终于将HL2的vbsp，vvis看完了，随便也翻了翻q3map代码，发现两者的代码太相似了，可以看出在BSP分割，portal的查找方面在Q2中都应该已经定型了，因此两者使用的算法都是一样的。下面我主要谈一下计算pvs的算法，因为在我翻译的那篇文章《bsp技术详解》中计算pvs是通过在每个portal上确定一些采样点然后进行ray cast来计算pvs的，这种方法的速度没有保证，而且处理起来也非常麻烦。而ID通过对每一个portal的polygen进行clip的方法来获取pvs，确实速度上要比上一个方法好上
很多。下面我来对算法进行详细的介绍，如果你对bsp不是很熟的话需要明确一下几个概念，一个是cluster，对于室内场景来说它完全是由cluster组成的，简单的你可以将它认为是场景中的一个房间，另一个是portal，场景中的cluster是由portal连接为一个整体，你可以把它看作是房间的门或窗户。在进行pvs计算的时候已经将整个场景划分为bsp tree，查找完portal并将cluster和leaf node连接起来了。
1、首先对所有的portal先进行一下预处理，让一个portal只和一个cluster发生联系，这样作的目的是为了获得一个单向的portal，也就是说portal只在一边可见，这样做是为了方便进行处理。我们知道一个portal通常连接了两个cluster，一般情况下使用的是portal所在plane正面的portal，但为了达到上述目的，我们需要将portal分为正反两个，由于在bsp中每一个plane都保存正反两个，因此位于反面的portal只需要对ploygen颠倒一下
顶点顺序即可。这里规定一个portal只和位于其plane的法线方向上的luster发生联系，预处理后保存的portal数量是原来的2倍。
2、接着我们需要对portal进行一下分类处理。通过简单的常识我们知道，由于现在每一个portal都是单向可见，因此只有位于portal可见方向（称为front方向）的portal才可能是可见的，我们需要对每一个portal都获得一个front portal列表并保存起来。
3、下面我们需要进一步的对每一个portal的front portal列表中不可见的portal进行剔除。我们知道场景完全是由一个个portal连接起来的cluste组成的，对于一个portal来说位于同一个cluster的portal一定可见，而其他portal要想可见最基本的要求是它可以通过其他portal连接到这个cluster上，因此通过portal的连接关系我们可以从front portal列表中剔除那些和当前portal没有连接关系的portal，并保存到floodportal列表中。
4、好了经过上面的处理我们已经剔除了大部分不可见的portal，可见的portal一定包含在flood portal列表中，因此需要使用更精确的方法进行检查。为了方便描述，我假定当前计算pvs的portal为A，任选和A所在的cluster ca相连的一个portal称为B，注意B一定是可见，因此B所在的cluster cb一定可见，但是和cb相连的其它portal并不一定可见，为了检查是否可见，我们假定选取其中的一个portal称为C。好了现在的问题简化为已知A和B求C是否可见，算法如下：
在A上选取一条边和B上的一个顶点构成一个clip plane，为了保证这是一个合法的clip plane我们需要做一下检查，为了简单化我们首先需要保证clip plane的法线方向必须指向portal A的外部，也就是说A上所有的顶点都位于clip plane的背面。
其次我们要保证portal B上所有的顶点都位于clip plane的正面，这样做可以保证当你选择A上最左边的一条边时必须要和B上最右边的一个顶点构成clip plane，当你选择A上最右边的一条边时必须要和B上最左边的一个顶点构成clip plane，将所有的clip plane合并起来实际上就获得一个A到B的最大可见frustum，只有位于frustum内部的portal才是可见的。当建立起这个frustum后我们就可以使用它对C的polygen进行clip操作了，当C clip后如果没有polygen在frustum内部那么它是不可见的，否则portal C可见并将可见的polygen保存下来。当C可见后我们需要接着对和C相连的portal进行检查，方法还是一样不过上面的portal B变成了C而且必须要注意，建立frustum使用C的polygen应该是clip后的polygen数据。通过上面的方法对A的flood portal列表进行递归运算最终将获得一个真正的可见portal集合保存到vis portal列表中。还需要指出一点的是建立clip plane的过程实际上需要两次，第一次是从A到B，第二次是从B到A，这样做的原因是并不是所有的极值点都位于B上的，也可能位于A上因此需要进行两次。
Q:怎么根据AB生成Frustum?
A:如果portal A和B都是一个四边形的话，frustum的四个面是这样组成的，A的左边和B的右边构成一个plane，A的右边和B的左边构成一个plane，上下方向也是，这样就形成一个frustum。但是当portal由多个顶点构成时，组成frustum的面也不会只有四个，这样形成的会是一个多面的frustum。