5.1 引擎适配与物理仿真：Unity与Unreal

5.1 引擎适配与物理仿真：Unity与Unreal

本节摘要：主流引擎为平面屏幕而生，VR 项目开机第一件事是关掉、降级或重配那些为平面准备的开销。本节给出 Unity 与 Unreal 的 VR 适配清单、双眼渲染的成本构成，以及物理仿真在帧预算里的取舍：步频、碰撞层级、休眠策略——一切为了把逻辑段压回账本。

进入系统防线第一站。第五章支柱页的"演示前夜崩盘"，源头就是把为平面屏幕优化的引擎配置原样跑在了头显上。本节的任务是立一份"开机第一周"的适配清单，并处理一个常被低估的开销大户：物理仿真。

双眼渲染：第一个要理解的成本

VR 渲染不是"渲染两次"那么简单，但确实接近两次：双目画面各占一半像素、视角略有差异，几何提交、光照计算几乎翻倍；加上为高刷新率服务的帧间隔压缩，GPU 预算与平面 4K 相比只紧不松。理解成本构成才能对症减负：几何翻倍靠实例化与合并缓解、光照翻倍靠限制实时光源数量、后处理翻倍靠逐项审查（不少后处理在双目下的开销与收益完全不成比例，抗锯齿、泛光、动态模糊都要重新评估——动态模糊在 VR 里甚至会加重不适，因为它是"伪造的运动"，与真实头动冲突）。

引擎侧还有一笔隐形账：提交与合成的线程模型。VR 需要单缓冲合成与重投影接管（第二章），引擎的图形队列设置必须与运行时合成器对齐；错过提交截止的帧由合成器兜底，但超支的账仍记在体验上——这是为什么适配清单里"帧驱动模式"永远排在画面特性前面。

Unity 侧清单

Unity 项目的开机清单按优先级：切换到单通道实例化渲染（双目一次提交，减少 CPU 提交翻倍）；固定更新频率与时间步长（下文物理部分展开）；光照实时光源数量压到个位数，静态物体烘焙光照贴图；后处理逐项开关实测；资源侧开启纹理压缩与网格合并；最后把动态分辨率闭环挂上（第二节的脚本可直接用）。

; Unity 项目 VR 适配要点清单（摘录，按优先级排列）
[xr] 单通道实例化渲染 Single Pass Instanced      ; 双目一次提交
[xr] 帧率目标 = 设备刷新率，Disable vsync 之外的等待
[quality] 阴影：距离限定 + 贴图降档，或改烘焙
[quality] 实时光源数 <= 4，禁用逐像素额外光源
[physics] Fixed Timestep 与刷新率成整数倍关系
[physics] 默认 Solver Iterations 减半验证是否可感知
[assets] ASTC 纹理压缩 + 网格合并 + LOD 层级就位
[profile] 每帧性能分析脚本常驻，超预算自动告警
​

Unreal 侧清单

Unreal 的 VR 框架成熟，开机清单思路相同而落点不同：开启实例化立体渲染与前向渲染路径（VR 项目用前向着色，为多光源场景优化过的延迟管线在双目下不划算）；关闭或替换为 VR 友好的后处理链；光照贴图与光照图分辨率按移动平台预算；动画蓝图里的每帧逻辑（Tick）逐个审查——Unreal 的 Actor Tick 默认全开，几百个对象各跑一段每帧逻辑，逻辑段立刻超支。两个引擎共同的纪律：任何第三方插件要先查它的每帧开销，"平面项目跑得动"不等于"VR 跑得动"。

物理仿真：把牛顿请回预算内

物理是逻辑段的大户，也是交互可信度的支柱（第三章的反馈闭环离不开物理响应）。取舍从步频开始：物理步频不必等于渲染帧率，但固定步长必须稳定——步长抖动会让碰撞结果不可复现，穿模与时有时无的碰撞判定（"手感发飘"的元凶之一）多源于此。VR 交互物件的物理策略分档：核心交互物（可抓取、可放置）用完整刚体加高解算次数；场景陈设用简化碰撞体加低频率；纯装饰物直接静态化不参与模拟。

碰撞层级与休眠是两个立竿见影的手段：层级矩阵里关掉"装饰对装饰"的碰撞查询；静置物体进入休眠，唤醒条件收紧到真实交互距离。手部交互要单独处理：徒手推动虚拟物体时，直接把手的位置强加给刚体会产生能量爆炸式的弹飞，正确做法是速度跟踪——按手的目标位置与当前刚体位置的速度差施力，给物理系统留出收敛余地。

💡 关键直觉：物理的第一美德不是准，而是稳。玩家可以接受一根柱子的碰撞体是个胶囊，不能接受同一根柱子今天能穿过明天不能——不可复现的物理会直接摧毁交互信任，而信任是第三章那套反馈闭环的地基。

演练：一次逻辑段超支的瘦身

现象：复杂场景里逻辑段从三毫秒涨到八毫秒，掉帧集中在物体密集的房间。排查走五步。第一步性能分析器按模块分组：脚本占大头，其次是物理。第二步脚本侧：找到每帧执行的查找类调用（按名字找对象、每帧遍历全场景），改为缓存引用与事件驱动。第三步物理侧：开启物理性能分析，发现装饰瓶罐全部参与解算——分档策略落地，陈设降为简化碰撞，装饰静态化。第四步步长复核：固定步长调整后与刷新率对齐，碰撞判定恢复稳定。第五步复测：逻辑段回到四毫秒内，物理侧余量留出。归档：清单进工程手册，"新场景入库前先跑这五步"成为流程。

⚠️ 常见坑：只盯 GPU 不看 CPU。渲染段的账目直观（帧时间肉眼可见），逻辑段的超支却常以"莫名掉帧"的面目出现——性能分析器必须常开，凭感觉优化在 VR 里必然跑偏。

清单执行的顺序与验证

两份引擎清单不能按任意顺序执行——依赖关系决定先后。第一批是"结构级"配置：渲染路径、单通道实例化、帧驱动模式——它们改变管线的形态，先做，后面的优化才有意义。第二批是"预算级"配置：光照数量、阴影档位、后处理裁剪、物理分档——在结构稳定后按预算表逐项定量。第三批是"守护级"配置：动态分辨率闭环、性能分析器常驻、超支告警——让前两批的成果有人看守。每批完成都跑同一把尺子：固定测试场景的帧时间分布对比，账目变化写进记录。顺序错了的典型症状：先调预算再切渲染路径，切完发现预算全变了，前功尽弃。

物理调参速查表

物理相关的参数与取舍收进一张表。

这张表与引擎清单共享同一条使用纪律：每次只动一行，动完复测——物理系统的参数耦合深，多行并改等于盲调。

引擎选择的现实考虑

常有团队在立项时纠结选哪个引擎，给一个务实的决策视角。决定性因素通常不是渲染画质或物理精度，而是三件朴素的事：团队既有经验（熟悉的引擎少踩的坑，远多于新引擎多给的性能）、目标平台的工具链成熟度（部署、性能分析、平台特性支持的完整度）、以及生态补件（交互框架、音频中间件、目标设备官方支持的更新频率）。性能差异在正确的适配清单面前反而是小项——两个引擎在 VR 预算纪律下的差距，远小于"随手跑默认配置"与"执行清单"之间的差距。所以决策流程建议倒过来：先列团队与平台的约束，再看生态，最后才比较参数表。引擎是工地，预算纪律才是手艺——手艺不到位，换工地救不了项目。

本节回收站

• 双眼渲染接近两倍开销，减负按几何、光照、后处理三路分头进行。
• Unity 与 Unreal 各有适配清单，共同纪律：帧驱动优先于画面特性，第三方插件先查每帧开销。
• 物理步长要稳定并与刷新率对齐，交互物件按核心程度分档模拟。
• 碰撞层级与休眠策略是免费的性能，手部交互用速度跟踪防弹飞。
• 物理的第一美德是稳与可复现，信任是交互闭环的地基。

引擎内部榨完了，账本还剩一个大项：算力从哪来。下一节比较一体机、PC 头显与云渲染三种平台形态的账本差异。