用 UE 做 VR 大空间: 先把多人站在同一个房间这件事做对

两个人戴着头显，准备抬起同一只虚拟箱子。甲伸手够到了把手，乙却觉得箱子还在半步之外。此时再精细的材质也救不了体验：两台设备没有把真实房间解释成同一个空间。

用 UE 做多人共场、真实行走的 VR 项目，可以先把场景留在灰盒阶段。让两个人围着同一张桌子走一圈，再交换位置。这比先做一段漂亮的开场，更容易检验底层架构是否可靠。

三套坐标，别都塞进 Pawn

建议显式区分 Tracking、Venue 和 Scene：设备跟踪空间、真实场地空间、虚拟关卡空间。头显报告自己在哪里，依据的是设备参考空间；立柱和地面标记属于场地；剧情里的大厅与电梯属于关卡。

设备姿态先经过标定转换进入场地，再映射到关卡。两段转换分别保存：重新标定只更新前者，剧情移动只更新后者。这样出现偏移时，才查得出是定位变了，还是关卡移动错了。

在 UE 中可以用独立的 Scene Component 承担空间偏移，把相机与 Motion Controller 放在跟踪节点下。相机继续接受本机跟踪更新，业务逻辑调整它的父级。别在多个蓝图里轮流修改相机世界位置，否则标定、转向和剧情传送很容易互相抵消。

两台设备需要将同一对象映射到同一场地位置。AI 生成概念示意，非 UE 运行截图。

标定不能只验起点。作为几何例子，朝向差一度，走到十米外就可能产生约十七厘米的横向偏差；这不是某款设备的实测精度。检查点应覆盖远端和转角，同时检查位置与朝向。UE 接入 XR 并不等于设备之间自动拥有了共享地图，共享定位仍需按硬件能力实现。

同步头和手，也同步“谁说了算”

只勾选 Pawn 的移动复制，通常不足以表达真实行走。玩家可能已经在跟踪空间里走了几步，Pawn 根节点却还在原处。头部、双手和根节点应分别确认各自代表什么。

一个可行的划分是：本机相机走本地跟踪；远端化身接收转换后的头手姿态，按采样时间插值；抓取归属、机关状态和场次进度由服务器裁决并复制。每次转头不应等待网络往返，两个人同时抓箱子却必须有一致结果。

姿态包建议带序号、采样时间和标定版本。旧包可以丢弃，长时间没有新姿态要进入掉线状态；重新标定后，旧版本数据不能继续混用。服务器还应检查异常位移，避免一条错误姿态触发远处的机关。

看见同一件物体之后，还要对交互归属达成一致。AI 生成概念示意，非运行截图。

恢复定位，不等于可以继续走

摘戴、待机或重新定位后，参考空间可能发生变化。把突变位置平滑回去，只是让画面没那么跳，并不能证明玩家仍在安全区域。

可以将定位状态分成正常、丢失和等待恢复确认。丢失时暂停要求行走的任务，提示玩家停留；恢复后检查场地映射，必要时重新标定，再恢复交互。项目需要按实际运行时接入相关事件，不能假定所有头显的通知方式都相同。

这段逻辑适合集中在设备与空间管理层，用 C++ 管理状态和转换，再向蓝图开放少量事件。关卡只处理暂停演出、显示提示和继续任务，不必各自实现一套恢复规则。

还要区分虚拟碰撞与真实边界。胶囊体被墙挡住，不会阻止玩家在现实中继续迈步。真实立柱、设备盲区和人员通道需要单独纳入场地配置，不能靠角色碰撞逻辑代替现场防护。

把最拥挤的一幕搬到真机上

本地渲染还是 PC 串流，要在美术量产前确定。前者受头显算力和散热约束，后者还要计入编码、传输和解码。桌面窗口流畅，不能代替戴上头显转头行走。

如果目标是九十赫兹，一帧间隔约十一点一毫秒。应分别观察 CPU、GPU 帧时间及尖峰，不能只看平均帧率。把预计同屏的玩家、交互物和特效放齐，尤其检查首次加载、场景切换和长时间运行后的表现。

定位恢复后，先确认场地映射，再恢复行走任务。AI 生成场景示意，非现场测试记录。

测试记录至少保留场次、设备、标定版本和状态变化时间。工作人员看到的也不能只有“设备在线”：网络连着，定位仍可能不可用。让这两种状态分开显示，现场才能判断是等待重连，还是引导玩家重新标定。

开场前的设备与场地检查，也属于交付流程。AI 生成场景示意，非现场测试记录。

交付前，再做一次并不好看的演示：两人共同搬箱子，其中一人摘下头显，恢复后继续；随后换一台备用设备，开启下一场。检查箱子归属、场次进度和空间位置是否仍然正确。这几个动作走通，才能知道定位、UE 客户端和场馆操作流程接在了一起。