基于ROAM的无限大地形实现思想.docVIP

基于ROAM的无限大地形实现思想 前言：什么是无限大地图？ 无限大地图的产生是在3D游戏中，为了给玩家带来全方位的真实游戏感觉而产生的。在3D游戏中决定是否使用无限大地图技术的关键并不是我们的游戏世界的大小，而是游戏是否需要模拟人类的视线，能再视椎体中需要渲染深度很高的地形区域。如下图： 图1-1 一般在普通的MMORPG中（不需要无限大地图）的游戏中，d的值为100-150左右，所需渲染的三角形数量在10-20万之间。而在真实世界里面，我们的眼睛会看到几百米，甚至几千米之外的景色。假设我们要提高玩家的体验，将渲染的距离提高到500米，从数字上看起并没有增加太多，但是我们如果使用跟普通的游戏一样的场景管理方式，所需要渲染的三角形数量将增加25倍。 图1-2 那么所需要渲染的三角形数量将变成25*15 = 375万个三角形。这个使我们的显卡所不能支持的。 所以，我们要对无限大地形进行特殊的管理和优化。 要实现无限大地形，需要实现哪些技术难点 内存的组织——决定要分块处理世界地形 后台加载——决定要使用多线程对资源进行全方位管理 Patch之间的无缝拼接——对地形网格的三角形复杂度进行按需分配 大场景物体的管理——碰撞，快速拾取 一些除地形以外的降低渲染压力的方法——让我们的场景跑得更加流畅 无限大地图的寻路方法 各个击破这些难点 内存的组织——决定要分块处理世界地形 原因： 无限大地形的游戏世界一般是非常的广阔的（因为看得远，否则走没有几步就走完整个世界了）。魔兽世界的地图高达320000000平方米。这么大的地形上面得有多少的数据信息（还不包含副本和外域等）。我们的游戏中一个场景为262144（512*512）的大小，资源从300-600M不等。按这个比例，那么如果一次性将整个无限大地图的游戏资源都加载到内存里面，那么需要600*(320000000/262144)= 732421.875M的内存大小。汗，这个数据绝对是用户所不能承受的。 具体方法： 既然在像WOW这么大的世界中，我们跑个30分钟我们也不一定能跑到地图的另一边，那么我们干嘛吧这块地形加载到内存中呢？所以，解决这个问题的关键在于一部分一部分的加载我们所需要的资源，看到哪里就加载哪里的资源，卸载已经看不到的地方的资源。这样我们不就可以让游戏的内存保持到很少的大小么？所以，问题的关键在于，怎么分割世界，以及什么时候加载，什么时候卸载。 关于分割世界的方式有很多，最简单的方式就是先分割成一个一个区域（area）,比如荆棘谷、暴风城、等等。区域与区域之间以门的方式连接。每个区域分割成一个一个的页片（TILE）。比如36*36大小的一块地形数据（包括场景数据），tile被作为游戏中的一个加载卸载的整体进行管理。 图1-3 怎么决定一个场景对象是属于哪个tile？有2中方法：精确的、或者松散的。这里介绍第2种方法。在场景编辑器中导出某个Area的时候，根据某个物体的包围盒来决定物体属于哪个TILE，导出成场景资源配置文件。 决定什么时候加载某个TILE。 图1-4 如上图，当tile进入蓝色的区域的时候加载器才需要加载，当tile离开绿色区域才能卸载资源。这样设计的原因是因为角色的移动速度是非常快的，如果角色在移动中反复的来回于跨越2个区域，那么这2个AREA里面的资源将会被频繁的被加载和卸载，非常不划算。增加了资源进出阀门，那么这样的频繁卸载加载的情况就不会出现。 后台加载——决定要使用多线程对资源进行全方位管理 如果决定要使用分块加载的方法，那么一定会使用多线程资源加载。需要完成一个资源管理器，对所有的贴图，模型，高度图信息，动画文件等等进行分别的后台加载。 Patch之间的细分 —— 对地形网格的三角形复杂度进行按需分配 前言中说到，无限大地图需要渲染的视野范围非常大，三角形数量非常大，地形就占了其中非常大的一部分。我们必须要降低这部分的三角形数量。有2种方式来决定三角形数量： 离摄像机的远近。试想，一个离我们非常远（500）米远处的一块地形，经过投影矩阵的计算，映射到我们的屏幕上，像素也就3、4个，我们为什么要为它绘制好几十个三角形呢？这样的一块地形（36*36），我们绘制一个1-2面就足够了。那么我们眼前的三角形又为了保持精度，需要甚至36*36的格子大小。 地面自身的复杂度。一个地面非常复杂的区域，比如山区、丘陵等地方，地形复杂，我们需要更高的三角形密度，然而像平原，沙漠，这样的地方，平平的，就只需要很低的三角形密度足够了。 那么，我们怎么来利用上面 2个条件来决