游戏中的场景管理技术

1. 游戏中的场景管理技术

2. 作业 • 对游戏的评价（每个人） 10% • 小组游戏proposal (每组) 10% • 对其他小组游戏proposal的评价（每组）10% • 请用OGRE实现任意一项 10% • 三维光照 • 场景组织 • 光影特效（包括阴影） • 大程作业 40% • 平时点名 20%

3. 游戏Quake3的场景

4. 三维游戏场景的组织和绘制 • 三维游戏中的图形技术可分为三个方面 • 场景的几何组织与优化 • 着重于提高绘制效率 • 场景的画面真实度,采用一系列特效生成技术 • 包括高级纹理映射,过程式建模等 • 基于真实物理定律的游戏效果模拟 • 主要是阴影模拟和碰撞检测 • 本次课程将着重讲解三维游戏场景的几何组织,优化管理以及在此基础上的OGRE中的复杂场景的管理

5. 三维游戏场景的组织和绘制 • 三维场景的组织和管理 • 游戏场景的几何优化 • 三维场景的快速可见性判断与消隐 • 地形场景的绘制与漫游 • 碰撞检测简介

6. 基于场景图(Scenegraph)的表达和管理 • 第一步 • 根据游戏的需要更新场景图必要的部分 • 这种更新是部分的,不需要从根节点遍历 • 第二步 • 场景图的剔除和绘制 太阳系的场景图

7. 基于绘制状态的场景管理 • 把场景物体按照绘制状态分类 绘制状态集合实例

8. 绘制状态树实例

9. 基于场景包围体的场景组织 • 加速判断场景物体之间的空间关系,主要有两种方法 • 对单个物体建立包围体,在包围体的基础上建立包围盒层次树 • 场景剖分

10. 常用的包围体技术

11. 包围体和包围球示例 球的体积比立方体大

12. OBB树的构造示意图

13. 物体的凸包围体 • 常用的类型 • 增量式(incremental) • 礼包式(gift-wrapping) • 分治式(divide-and-conquer) • 快速凸包算法(quick-hull) • k-dop(discreted orientation polytope,离散有向多面体) • 比上述的包围体更紧密地包围原物体,创建的层次树节点更少

14. 8-dop结构

15. 场景绘制的几何剖分 • 将场景中的几何物体通过层次性机制组织起来 • 优点 • 使用灵活,能快速剔除层次树的整个分枝 • 注意 • 要保持树的平衡!

16. 包围树

17. 常用的几何剖分技术 • BSP树 （左）场景的BSP树剖分；（右）BSP树结构示意图

18. BSP树的构造过程 （左）一次剖分后的场景平面图；（右）一次剖分后的BSP树 （左）两次剖分后的场景平面图；（右）两次剖分后的BSP树

19. BSP算法处理四个嵌套遮挡的多边形 • 用画家算法无法处理四个嵌套遮挡的多边形情形

20. 四叉树 （a）场景多边形； （b）第一次剖分； （c）第二次剖分

21. 八叉树 （a）（b）（c） （a）初始节点； （b）第一次剖分； （c）第二次剖分

22. 景物包围体和场景剖分技术比较 （左）场景包围体技术（右）场景剖分技术

23. 景物包围体和场景剖分技术比较

24. 景物包围体和场景剖分技术比较

25. 层次细节(LOD)技术 • 简单取舍型LOD • 平滑过渡型LOD • 静态LOD • 动态LOD

26. LOD

27. 经典的简化算法 • 顶点删除 • 边删除 • 最有效! • 面删除 基于边删除的顶点简化

28. 兔子模型的四个层次

29. LOD Models

30. 渐进网格和连续多分辨率绘制技术 • 对于数据量庞大的复杂模型 • LOD模型只能预先产生多个间断的简化模型 • 引起实时绘制时图形画面的跳跃 • 为克服LOD的缺点,Huppe等人于1995年提出 • 渐进网格技术(Progressive Mesh) • 预计算简化过程中原顶点和新顶点的关系 • 由基本网格模型逐步恢复模型细节

31. 示例: SpeedTree的LOD过渡

32. 示例: SpeedTree的LOD过渡

33. 示例:SpeedTree的LOD过渡

34. Demo

35. 场景的可见性判断

36. 可见性判断算法分类

37. 遮挡面剔除技术

38. 遮挡面剔除技术 • 适用于人造建筑物少的室外场景 • 代表性算法:基于阴影体技术 （左）遮挡剔除之前；（右）基于阴影体的遮挡剔除

39. 包围球加速 （左）球A 至少在一个平面之外，球B在所有平面之内，但其半径大于球心到其中一个平面的距离，球C在所有平面之后且到所有平面的距离足够大。（右）一种包围球没有被完全遮挡但包围盒被完全遮挡的情形，故物体不应被绘制

40. 可见性计算（适用于室内场景） • 可见性（Visibility）算法用于决定场景中可能可见的物体 • 一般的：保守地指定这些物体并将他们发送到图形绘制引擎 • 确切的可见性决定对于游戏而言是可能的，但是代价太大 • 因此，存在平衡：在软件中进行可见性判断的时间和在硬件中绘制多余的不可见物体的代价 • 最简单的就是绘制引擎本身自带的视域裁剪算法 • 但是这个算法对于高度复杂性的场景并不合适，特别当很多物体位于单个象素之后 • 比如，第一人称视角游戏中常见的建筑物具有高度的深度复杂性。

41. 区分可见性信息 • Cell-to-Cell 可见性 • 告知在一个cell中的某点处是否可以看到其他的房间 • 但是无法知道每个房间的那个部分可能是可见的，也无法知道观察者在这个房间的哪个地方可以见到另外的房间 • Cell-to-Region 可见性 • 可以知道某点处，其他房间的哪些部分是可见的 • Cell-To-Object: 对于某给定的房间，告知哪些物体是可见的。 • Eye-To-Region 可见性 • 记录当前视点处的哪些房间的哪些部分是可见的 • 同理，Eye-to-Cell 以及 Eye-To-Object

42. 基于入口(Portal)技术的可见性判断 • 根据单元与单元之间的邻接图,通过深度遍历建立起单元与单元的入口序列

43. 基于入口结构的绘制技术 • 分为两类 • 精细型入口绘制方式 • 粗略型入口绘制技术 • 优点 • 方便定义场景 • 快速绘制 • 缺点 • 消耗大量的内存,换取效率的提高 • 不适合室外渲染

44. Cell-Portal 结构 • 许多可见性算法假设单元和入口的数据结构 • 数据结构类似于一个图：节点是房间，边是入口 • Portals本质的意思是两个房间的墙之间存在洞 • Portal 形状一般是多边形 • 两个房间之间也可有多个Portals • 如何建立这个数据图？ • Kd-trees 或者BSP树用于生成cell结构以及寻找与之相关的 portals • 自动或者手工生成 • 建筑物最合适这种情况

45. Cell Portal 实例 • Portals 可以是房间的边缘（即墙壁） • Graph一般保存相邻信息 • 每个房间保留其外向的边（即portals） A B A B C D C D E F E F

46. Cell-Portal 可见性 • 跟踪观察者所在的房间 • 然后遍历graph穷举所有可见的区域 • 可以预处理，对每一个房间计算可能可见集合potentially visible set (PVS) • Cell-to-region可见性，或者cell-to-object可见性 • 也可以在运行之间更进一步地精确获得可见集合 • 从已知观察者的位置出发 • Eye-to-region或者 Eye-to-cell可见性 • 平衡：节省下列的时间 vs. 计算小的可能可见集合的代价 • 与所在环境有关，如房间的尺寸、房间物体的个数…

47. PVS:可能可见集 • PVS: 对于某个特定的房间，可能可以看到的房间/区域/物体/多边形 • 一般地，保存可以看见的物体的标识号 • 也要考虑内存的因素 • 预处理的计算过程 • 应该能良好地管理动态变化的物体列表 • 用法: • 可见性确定 – 对于当前房间，绘制所有PVS中的多边形 • 做为第一步：获得可能相关的区域，并做进一步处理

48. I J F H D B E C G A Cell-to-Cell PVS • Cell A 在 B的 PVS中，当且仅当存在一根线，从B出发射到A，并且在途中与任何物体不相交 • 隔壁房间理所当然在PVS之中 I 的PVS 包括: B, C, E, F, H, J

49. Stab 树 • 这个树状结构表示: • 当前房间的PVS • 一个串着的相关的portal序列 • 在进一步的可见性处理中 • 可以减少需要检查处理的cells/portals 数目 A A B A/C C C/E C/D2 C D C/D1 E D D D/F F E F

50. Cell-to-Cell的用法 • 大多数算法比cell-to-cell可见性算法更复杂 • 因为它过估计– 当实际上99.6%的模型应该是不可见的时候，仅排除了大约90%的模型, 而更好的算法可以排除98% • 但是，保持cell-to-cell可见性有利于动态物体 • 当房间中有一个移动的物体 • 并且房间是静态的