|
|
对于通用场景来说我以前介绍的区间扫描线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文件）:
http://www.cnblogs.com/dreams/archive/2007/03/26/688650.html
这是我的新blog,呵呵. |
|
发表于 2007-3-26 16:37:00
楼主
