`
javahigh1
  • 浏览: 1225186 次
  • 性别: Icon_minigender_1
  • 来自: 北京
文章分类
社区版块
存档分类
最新评论

新游戏中出现的基于BSP场景分割技术

阅读更多

前不久看了看WOW的WMO地图文件格式,发现这是一个规整的Interlocking Tiles+Portal+BSP分割体系,与FarCry的引擎体系几乎完全相同。它很通用,而且很有用。

我一说WOW的什么什么技术“很通用”,什么什么技术“挺简单”,就会被人扁,麻木了都。我说他通用,说他简单,并不代表我不顶礼膜拜。简单即美丽,正确的往往是相对于目标最优的路径,而不是最眩的路径。

我想先说说Dreams他们曾经讨论过的FarCry中的技术,这篇文章本来在Gameres的Blog中,但是我现在上不去这个Blog站了,很郁闷。FarCry用的是33X33的Interlocking Tiles室外场景,这一点注意一下WOW的室外场景,虽然NXN不好说,但是同样也是Interlocking Tiles!

首先,这里就能说明,WOW用的决不是什么高不可攀的技术,FarCry都已经诞生多少年了?!可以说:WOW用的是最成熟的技术,构架了最完美的世界。这点我希望大家认清楚WOW的技术实质,国外这是一套比较成熟的场景结合技术,并不是高不可攀。只不过,放到中国,本来大量有希望作出来的好的图形程序员都被某些公司当二奶包养着去做绿色网游了……操,说好这个话题不再说的!我毕竟还是相信山河虽已不幸若此,但好人还是有的!

首先,必须强调一点,FarCry的格式以及HL2的室内场景部分我并未具体研究过,所以以下的发言只是基于Dreams等人在讨论中传达出来的信息。如果大家能登录到Gameres的Blog,可以看看Dreams他们的讨论,关于FarCry主要透露出这样几个点:
1、FarCry的室外场景是IT四叉树,关于这个主题,在这个Blog的前面的文章中提过9X9标准IT算法,代码也有。
2、FarCry的室内场景是BSP。
3、FarCry的内外结合首先通过Portal。
4、FarCry使用IT+Portal可以在内外场景间建立PVS,从而可以在运行时使用PVS系统提高效率。

对于若Dreams、Skullwang这样的前辈来说,这应该是再规整不过的算法了,一点也不华丽。对于FarCry而言,室内场景毕竟并不是它主要想表达的东西,所以FarCry的室内场景或许可能会简单了些。因此,按照Dreams的讨论,它在室内场景的表达上也不会比HL2的概念显得优秀。按照讨论来看,HL2的室内场景概念不是太复杂的概念:
1、HL2的城市以Area作为单元,Area和Area之间通过Portal连接。一个Area,主要可能就是一栋栋房子,和一条条街道。
2、每个Area本身,进行标准BSP分割,分割为一个个Sector(就是房间)。

如果这里,Area不叫Area,而叫做Group,Sector不叫Sector,而叫做BspNode,那么,我们看看WOW的Wiki中WMO的格式,就能找到完全相同的名称。

WMO一个室内地形,由多个Group构成,每个Group可能都是一个规则的Bsp空间分割(Group内部出现了标准的BspNode结构),Group和Group之间以Portal连接。据我的老大说,魔兽中的Portal很少,我认为,我们能看到的Portal主要是G-G之间的Portal,而不包括BspNode之间的Portal,BspNode之间的Portal可能没有渲染出来,没有计入Header的Portal表中(应该是不必要计入),或者干脆可能已经被PVS优化掉。这个我没有具体跟踪一个WMO场景,所以不太清楚到底是那种情况。但无论是哪种情况,我认为,将WMO和BSP划清界线的做法并不可取。

通过这个方法,大空间BSP的“大树”问题被通过Area或者Group轻松干掉,而同时不会丢弃BSP本身的优势——这就类似于无限大场景之于四叉树,相辅相成,不可缺一。Area离开了Sector,房子是好筛选了,然而一次整体渲染一个房子,首先渲染就低效,房子内部的逻辑也不好走。Sector离开了Area,一个可能超过几千个节点的大树就会被建立出来,同时,还有大量的Portal,还有被分割平面分割得过分琐碎的空间——这也不像是一个优秀的算法应该拥有的效率。

BSP是一个老算法,但它不是一个不再发展的算法,相反,BSP在逻辑处理上的优点和高效性,目前没有新的算法可以抹杀,而BSP的缺点,却可以通过种种手段予以消弭。其中主要的琐碎空间问题,通过Area和Sector的划分,Area本身就可以避免大量不必要的空间划分,使得空间划分集中在每个Area本身内部。而在Area内部,又可以通过Struct Face和Detail Face的区分、甚至是手动分割面指定使得空间尽可能少被分割。而凸包问题也早已不是问题,现在的BSP就算是个凹多面体,也不会引发太大的问题——因为在更大的眼光来看,通过Struct Face,再BT的凹多面体都可以被当作凸多面体。而最复杂的光照计算,似乎3DMAX也提供了更简单的做法,可以直接在模型制作的阶段就能直接将光照图打进去。一切都在向着更好的方向走去,就像C++一样,可选的库越来越多,方案越来越多……只有对方案掌握的好坏,没有经典BSP本身的问题了……

BSP目前面临的主要困难应该还是在编辑器,你不能指望美工明确他所在的空间哪些是Struct Face,哪些是Detail Face,而Area的划分,则更必须通过编辑器来进行了,这可能也是导致BSP无法大规模成为制式方案的一个不足之处——在目前,特殊的历史时期,特殊的时代背景下,有足够米和人力的公司宁可花钱养一堆不干事的食客,也不会把这些人团结起来,让他们从事一些研究的工作。而本来被设计为担负这个任务的研究机构,却都据说去研究最关乎“国计民生”的问题了。初级阶段嘛……结果就是,只好靠自己精神病般的一腔狂热来独自面对这种变态问题。

如果有一个哪怕效率稍差的算法,可以连一个刚从学校毕业的美工都能轻松画出一个内外结合的地图,这个算法应该就会很容易替代掉BSP,曙光还未来临,吾辈还需努力!

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics