VR手游 无限地图的场景管理优化

本游戏基于安卓平台，面向国内配备 2G 内存及 4 核处理器的中低端智能机。鉴于 3D 游戏普遍存在内存消耗大、资源占用多的问题，为了让国内多数机型能够流畅运行本游戏，并避免 VR 游戏因掉帧导致玩家眩晕的常见问题，项目技术的主要攻克方向聚焦于系统优化。基于此目标，我们在多个方面展开了努力。

1. 地图的建立和加载

本游戏将游戏空间划分为类似魔方的 27 块立体空间，在每个子空间中随机生成 10 个或更多的物体。在生成物体期间，插入预加载好的过场动画。在播放动画的同时，通过协程（类似于多线程）的方式，每秒加载 60 个物体（即每帧加载 1 个）。这样，当用户观赏完过场动画后，场景内的所有物体就已完整加载，避免了用户等待。

2. 场景管理

目前，游戏通常采用动态渲染的方法对场景内的物体进行渲染。然而，在 VR 游戏这种玩家直接体验游戏画面的类型中，动态渲染导致的帧数降低会极大地影响玩家的游戏体验。因此，必须预先加载好场景内的所有物体，以内存空间换取加载时间，这对整个系统的优化提出了很高的要求。但提前加载所有物体可能会使游戏地图缺乏灵活性，限制玩家的自由移动。为解决这一问题，我们探索了其他方法。

对于场景渲染，常见做法如下：在整个地图中，红色表示当前玩家位置，渲染其周边白色的 6 块区域。当玩家移动后，取消上右图中右上虚线位置的渲染，转而渲染黑色右下位置的模块。

受此方式启发，本游戏将游戏地图设计为可循环的无限模式。具体实现方式为：玩家初始位于 27 块立方体的正中央，当玩家向右前方移动到箭头所指的方块时，将黑色方块面转移到虚线方块面位置。向其他方向移动时同理，始终将玩家位置保持在方格正中心。

3. 动态内存优化

在前面的内容中，我们提到了完全加载对内存的压力问题。如果将 270 个模型同时放置在游戏中，会给内存带来较大压力（这是安卓机的系统缺陷），同时加载延迟也会增加，影响游戏体验。

如图一所示，展示了场景中分布物体的内存占用情况。

若将 270 个物体通过 34 个模型在不同位置、不同方向进行展示，其效果与 270 个物体相同，但在内存中仅占用 34 个模型的空间。这样，即使增加更多物体，堆内存的占用也不会成倍增长，大大减轻了内存压力。

如图二所示，展示了场景中分布 27000 个物体的内存占用情况。

4. 场景与烘焙

一般游戏中，场景光采用单平行光进行渲染。然而，单平行光产生的明暗对比在美观度方面表现不佳，常见的解决方法有以下两种：

• 双反向平行光照：该方法看似可行，但由于 VR 游戏需要双摄像感知，在两个摄像位置和两道光的情况下，GPU 承受的压力是正常游戏的 4 倍。在手机上，这会导致帧数从 60 下降到 50，玩家难以接受。
• 物体自发光：此方法更不现实，对 270 个物体进行自发光处理，GPU 承受的压力比双平行光更大。

针对上述问题，我们决定采用预烘焙的方式。即在播放开场动画时，对所有物体进行双向光照射预先烘焙。当所有物体加载完成后，保留物体被双向光烘焙后的形态。玩家进入游戏后，直接在场景中显示烘焙后的物体。这样既能减轻 GPU 压力，又能为玩家模拟出较为真实的光照环境。

相关问题解释

解释 1：为何不使用八叉树的管理方法

原因是效率较低。八叉树需要创建大量指针和对象，对于小规模场景管理，其效率反而不如其他方法。小规模场景大概指 100k 以下的场景，在我的普通电脑上对 100k 个物体进行搜索时，八叉树仅以微弱优势胜出。

解释 2：为何要开发手机端的 VR 游戏

由于国内现有消费水平难以支撑购买 HTC 等高端 VR 设备，为了更快地抢占市场，厂商们必然会在手机 VR 领域展开竞争。而且手机性能在不断提升，未来可能会达到 VR 游戏的要求。说白了，我目前资金有限，只能先研究 Google Cardboard 这类手机 VR 方案。

解释 3：为何物体在屏幕边缘时能显示，镜头转过去时物体却消失了

这是因为我们没有使用曲面屏。理想的视锥应该是下圆上尖的不倒翁型，但 Unity 中的视锥既不是不倒翁型，也不是圆锥形，而是四棱锥型。由于三角形斜边比直角边长，当物体位于屏幕边缘时，其与摄像机之间的距离可能恰好等于斜边（大于视距），从而导致物体消失。