前不久看了看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,曙光还未来临,吾辈还需努力!
分享到:
相关推荐
3D游戏中的BSP二叉空间分割技术.doc
基于VxWorks 的BSP 技术分析 基于VxWorks 的BSP 技术分析 基于VxWorks 的BSP 技术分析 基于VxWorks 的BSP 技术分析
bsp场景管理的实现. Bsp.h,Camera.h,Port.h,Node.h,SkinnedMesh.h...... vs2008直接打开;可运行BspSceneMgr.exe
此篇论文描述了前一些年的3D游戏中广泛使用的BSP场景组织结构的算法,全篇英文,不过却是深入简出,对于想了解和研究BSP场景组织算法的朋友是份非常好的资料
原创文章,著作权属本人所有,本人也对一切言行负有责任,望大家能尊重劳动者的辛勤努力,不要侵犯我们这些底层劳动人民的知识产权。
带源码讲解游戏场景管理 流行的BSP技术
经过几天的努力,完成了一个基于BSP的室内场景管理,包括BSP编译、渲染、碰撞检测,地图文件是从一个网站下载的BSP演示程序中拿来的,该网站的地址:http://home.planet.nl/~monstrous/mons.html ,不过现在不能访问...
详细介绍BSP树(Binary  Space  Partioning  trees,二维空间分割树)的原理和实现。
好东西,[转]3D游戏中的场景管理(八叉树和BSP树简介).doc
Quake3 BSP 技术简析 关于bsp技术的论文,喜欢游戏制作或者想了解bsp的可以下载看看 相关技术可以去搜索更多专业论文
[转]3D游戏中的场景管理(八叉树和BSP树简介)[转]3D游戏中的场景管理(八叉树和BSP树简介)
详细介绍BSP技术的资料,看完之后对BSP有全面的了解,并会知道portal技术,了解从室外到室内的场景裁剪.希望对大家有帮助
用DX渲染Q3 BSP场景 没有在其他的机器上试过,如果无法运行,请编译源代码,并修改加载的BSP路径。
bsp 漫游程序 用bsp树组织场景,并应用于碰撞检测
如碰撞检测 A* 四叉树 BSP分割树 地形LOD等等
描述了整个游戏引擎的框架,并详细阐述了实现三维场景的技术和场景中的碰撞 检测与碰撞反应的技术。 在整个游戏引擎设计中,作者主要采用了BSP树的数据结构。这种数据结构 有助于三维场景的快速实现和有效管理,并且...
基于Android的BSP移植自动适配技术.pdf
想要学习bsp技术的同学们可以看看这个文档,这里面讲了很多bsp的东西,很深入
简要分析了目前Linux BSP开发存在的缺陷,通过分析两个不同版本嵌入式Linux的Ac97声卡驱动程序的异同,针对不同处理器提出了一种基于Linux的BSP标准。在此基础上,实现了一套基于XML的Linux BSP标准化配置工具,实现...
基于vxWorks的BSP启动过程实例分析