添加了occlusion culling功能，当前的OC还是一个演示版本，由于WOW的世界中没有很好的遮挡物，因此我只好使用距离camera最近的wmo物体的AABB作为遮挡物，对地形块进行遮挡剔除。

打开occlusion culling需要使用功能键F8，同时为了方便观察遮挡效果又增加两个键：

NUM_3 显示occluder和occludee的box；

NUM_4 显示遮挡效率。

为了更好的观察效果，建议打开OC功能后直接选择数字键3。

下载地址：wowmapviewer

评论: 3　查看评论　发表评论

最新新闻：
· 百度第四季度净利润6270万美元 同比增48.2%(2010-02-10 09:10)
· 现场直播：Google 社会化产品 Google Buzz 发布(2010-02-10 09:01)
· 阿里巴巴3月推1688网络批发 胡戈韩寒出力宣传(2010-02-10 08:48)
· 第一代互联网拓荒者再掀连环创业潮(2010-02-10 08:47)
· 雅虎将永久性关闭科技站点Yahoo! Tech(2010-02-10 08:45)

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

新版本主要改进有以下几个：

1、修改了上一版本在进行portal culling时在一些山洞和地下城场景出错的bug，现在打开F7功能时不会出现渲染错误；

2、添加了碰撞检测功能，功能键为F10，简单的使用半径为1.0的球体和场景进行碰撞检测；

3、增加了功能键NUM 1来显示wmo的group AABB;

4、增加了800*600的显示选项（原来默认的1024*768在我的CRT上显得有些大，呵呵）。

下载地址：wowmapview

评论: 0　查看评论　发表评论

最新新闻：
· 百度第四季度净利润6270万美元 同比增48.2%(2010-02-10 09:10)
· 现场直播：Google 社会化产品 Google Buzz 发布(2010-02-10 09:01)
· 阿里巴巴3月推1688网络批发 胡戈韩寒出力宣传(2010-02-10 08:48)
· 第一代互联网拓荒者再掀连环创业潮(2010-02-10 08:47)
· 雅虎将永久性关闭科技站点Yahoo! Tech(2010-02-10 08:45)

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

在通过ufoz的wow map viewer对wmo文件研究过程中，尝试在其中加入portal culling功能，经过几天的努力，完成了一个初始的版本，这个版本存在以下的bug：1、一些只包含一个group的wmo在某些情况下会被错误的culling；2、在地下城场景中只要是在indoor就会出现culling错误；3、某些山洞场景会出现culling错误。这些bug打算在以后版本解决。

使用方法：进入程序后使用功能键F7打开portal culling功能。

wowmapview版本号：0.5。

注意一点：使用wowmapview需要下载WOW的客户端。

下载地址：/Files/dreams/wowmapview.rar

问题交流可留言或发送邮件至：dreams_wu@sina.com

评论: 0　查看评论　发表评论

最新新闻：
· 百度第四季度净利润6270万美元 同比增48.2%(2010-02-10 09:10)
· 现场直播：Google 社会化产品 Google Buzz 发布(2010-02-10 09:01)
· 阿里巴巴3月推1688网络批发 胡戈韩寒出力宣传(2010-02-10 08:48)
· 第一代互联网拓荒者再掀连环创业潮(2010-02-10 08:47)
· 雅虎将永久性关闭科技站点Yahoo! Tech(2010-02-10 08:45)

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

评论: 1　查看评论　发表评论

最新新闻：
· 百度第四季度净利润6270万美元 同比增48.2%(2010-02-10 09:10)
· 现场直播：Google 社会化产品 Google Buzz 发布(2010-02-10 09:01)
· 阿里巴巴3月推1688网络批发 胡戈韩寒出力宣传(2010-02-10 08:48)
· 第一代互联网拓荒者再掀连环创业潮(2010-02-10 08:47)
· 雅虎将永久性关闭科技站点Yahoo! Tech(2010-02-10 08:45)

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

对于通用场景来说我以前介绍的区间扫描线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大小上传,抱歉!!!!

评论: 2　查看评论　发表评论

最新新闻：
· 百度第四季度净利润6270万美元 同比增48.2%(2010-02-10 09:10)
· 现场直播：Google 社会化产品 Google Buzz 发布(2010-02-10 09:01)
· 阿里巴巴3月推1688网络批发 胡戈韩寒出力宣传(2010-02-10 08:48)
· 第一代互联网拓荒者再掀连环创业潮(2010-02-10 08:47)
· 雅虎将永久性关闭科技站点Yahoo! Tech(2010-02-10 08:45)

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

隐藏面剔除算法的出现是基于以下的现实，在游戏场景中你不必每帧都将所有的物体渲染到屏幕上，它的作用主要有两个：一个是减少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运算，尤其是那些渲染代价非常大的角色模型。

评论: 0　查看评论　发表评论

最新新闻：
· 百度第四季度净利润6270万美元 同比增48.2%(2010-02-10 09:10)
· 现场直播：Google 社会化产品 Google Buzz 发布(2010-02-10 09:01)
· 阿里巴巴3月推1688网络批发 胡戈韩寒出力宣传(2010-02-10 08:48)
· 第一代互联网拓荒者再掀连环创业潮(2010-02-10 08:47)
· 雅虎将永久性关闭科技站点Yahoo! Tech(2010-02-10 08:45)

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

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的工作，这可能是将其扩展到无限地形系统的一个非常具有挑战性的工作了。

评论: 0　查看评论　发表评论

最新新闻：
· 百度第四季度净利润6270万美元 同比增48.2%(2010-02-10 09:10)
· 现场直播：Google 社会化产品 Google Buzz 发布(2010-02-10 09:01)
· 阿里巴巴3月推1688网络批发 胡戈韩寒出力宣传(2010-02-10 08:48)
· 第一代互联网拓荒者再掀连环创业潮(2010-02-10 08:47)
· 雅虎将永久性关闭科技站点Yahoo! Tech(2010-02-10 08:45)

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

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引擎中只有部分模块使用了这个方法，可能是这个接口引入时间太晚的缘故。
（待续）

评论: 0　查看评论　发表评论

最新新闻：
· 百度第四季度净利润6270万美元 同比增48.2%(2010-02-10 09:10)
· 现场直播：Google 社会化产品 Google Buzz 发布(2010-02-10 09:01)
· 阿里巴巴3月推1688网络批发 胡戈韩寒出力宣传(2010-02-10 08:48)
· 第一代互联网拓荒者再掀连环创业潮(2010-02-10 08:47)
· 雅虎将永久性关闭科技站点Yahoo! Tech(2010-02-10 08:45)

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

对于在运行时可以明确知道分配数量的物体，可以通过一个静态数组来实现它，
但对于不知道分配数量的地方，设计就变的有些复杂，通常需要使用一个链表来
进行实现，如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;
这样就可以将内存块重新连接到未使用的内存块链表中。通常对指针进行转换的时间
非常短，比一般的链表的插入、删除操作速度快的多，因此这个技巧是非常值得借鉴
的做法。

评论: 0　查看评论　发表评论

最新新闻：
· 百度第四季度净利润6270万美元 同比增48.2%(2010-02-10 09:10)
· 现场直播：Google 社会化产品 Google Buzz 发布(2010-02-10 09:01)
· 阿里巴巴3月推1688网络批发 胡戈韩寒出力宣传(2010-02-10 08:48)
· 第一代互联网拓荒者再掀连环创业潮(2010-02-10 08:47)
· 雅虎将永久性关闭科技站点Yahoo! Tech(2010-02-10 08:45)

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

评论: 0　查看评论　发表评论

最新新闻：
· 百度第四季度净利润6270万美元 同比增48.2%(2010-02-10 09:10)
· 现场直播：Google 社会化产品 Google Buzz 发布(2010-02-10 09:01)
· 阿里巴巴3月推1688网络批发 胡戈韩寒出力宣传(2010-02-10 08:48)
· 第一代互联网拓荒者再掀连环创业潮(2010-02-10 08:47)
· 雅虎将永久性关闭科技站点Yahoo! Tech(2010-02-10 08:45)

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库