WorldRover：面向世界探索的可扩展合成视频数据引擎与富标注数据集 WorldRover: A Scalable Synthetic Video Data Engine for World Exploration with Rich Annotations
把世界探索变成可复用轨迹数据源：一次离线渲染，多视角多外观多模态标注同步产出。
前置知识
世界模型
学习预测"当观察者移动或执行动作时视觉世界如何变化"的生成模型。它需要的不只是 RGB 视频，还需要与帧严格对齐的相机位姿、场景几何、时序对应关系和控制信号，才能把"像素为什么变化"分解为相机运动、物体运动、光照变化等相互独立的因素，并在遮挡后维持物体身份。
WorldRover 的全部设计（轨迹复用、动作流、多视角配对）都是为世界模型训练提供因素可控的监督信号，读懂动机必须先理解世界模型的数据需求。
光流与长程点跟踪
光流是相邻两帧之间每个像素的位移场，本文由渲染器速度缓冲直接读出并按每帧 $\pm 64$ 像素范围无损量化；点跟踪则跟随同一个 3D 点在长时序中的投影，逐帧记录 2D 像素位置、3D 世界坐标与可见性标志。本文的点轨迹用"种子帧反投影到世界坐标 + 逐帧重投影回图像"的几何方式生成，完全不依赖图像匹配。
两者是本文的核心标注。理解其来源（渲染器原生 vs 图像匹配）才能明白为什么这些轨迹不会累积匹配漂移、遮挡期间仍有 amodal 位置。
Lumen 与 Movie Render Queue
Lumen 是 UE5 的动态全局光照方案，光照在渲染时实时求解而非烘焙进光照贴图，因此切换天气/光照状态会物理正确地改变间接光、颜色渗透与阴影柔度；Movie Render Queue（MRQ）是 UE 的离线渲染管线，可对每帧累加多个空间子样本做抗锯齿，用渲染时间换取图像质量，专为批量生产而非交互延迟设计。
理解这两者才能明白：为什么同一状态重渲染是物理变化而非图像重着色，以及为什么渲染实例只能占用每个 GPU 的一小部分算力（瓶颈在游戏线程）。
等距柱状全景投影与立方体拼接
360° 全景通常以 equirectangular（等距柱状）格式存储，宽高比 2:1。本文不使用 UE 自带全景通道（它会在累加时对场景颜色硬钳位，高亮部分不可恢复），而是渲染六张 100° FOV 的普通透视立方面（相邻面 10° 重叠），在线性光域重投影并用余弦羽化加权拼接成 $4096\times2048$ 全景，再做曝光估计与色调映射。
这是全景子集数据的生成方式，也是理解全景与透视视图共享相机中心、可逐像素配对比较的关键。
NavMesh 导航网格
在场景可行走表面预先烘焙的多边形网格，供寻路算法查询。本文用三种策略生成漫游轨迹：基于 NavMesh 的规划器（速度快、覆盖广、需逐场景调参）、无需预计算地图的反应式探索器（用射线扇局部避障，可能走进死角）、以及人工录制（路线可控但费人力），三者分别产出 3,662、1,996 和 345 条序列。
轨迹生成策略决定了数据集中路线的长度、时长与覆盖分布，是解读 Figure 11 统计图的前提。
对数深度量化
深度值按 $t=\frac{\log d-\log d_{near}}{\log d_{far}-\log d_{near}}$ 映射到 $[0,1]$ 后量化为 16 位，其中 $d_{near}=0.1$ m、$d_{far}=200$ m，配 FFV1 无损编码和解码 sidecar。对数参数化让近距离绝对精度高、远距离粗，符合视觉任务对近处误差更敏感的特性。
这是使用数据集深度流时必须知道的编码约定，不按 sidecar 中的公式反解就会得到错误的深度值。
研究动机
学习生成或重建可探索的世界需要远超 RGB 的信号：相机运动、场景几何、时序对应，以及交互式模型所需的控制信号。真实视频采集能提供其中一部分，但位姿、深度、对应关系通常靠事后估计——位姿会漂移、遮挡会让对应失效，且密集几何和长程对应往往依赖专业仪器，限制了可采集的环境与条件。现有合成资源又各有短板：任务专用数据集为固定基准优化（如 PointOdyssey 只有 104 段、平均约 2,000 帧）；交互式仿真器（CARLA、AirSim、Habitat）优先低延迟观测而非渲染质量；程序化生成器增加场景数量却缺乏美术级细节。更关键的是，这些资源很少在同一帧上同时给出密集几何与时序对应，几乎不存在"对同一条世界遍历在受控的视角与外观变化下重复观测"的数据——于是相机运动与物体运动、光照变化与几何变化在像素层面相互纠缠，模型无法把视觉变化归因到正确的因素。
本文的目标是本文的目标是把"长时程世界探索"变成一个可规模化的数据生成问题。具体分两层：其一，构建 WorldRover-Engine，一条基于 Unreal Engine 的离线渲染流水线，在美术师制作、商业授权的 UE 环境中自动生成分钟级漫游路线并离线渲染，同时完整保留路线、时序与场景几何；其二，用该引擎构建 WorldRover-10M 数据集，发布 32 个环境、6,003 条序列、21.9M 帧、202.7 小时、约 18.7 TB 的数据。每条序列按子集配对指标深度、稠密光流、长程 2D/3D 点轨迹（含可见性）、渲染相机轨迹、角色轨迹以及由轨迹推导的动作流；同一条路线可分别以第一人称、第三人称和 360° 全景相机观测，也可在不同光照/天气状态或白模材质下重渲染，为世界模型、动态 4D 重建和粗到细生成提供因素可控的监督。
与已有工作不同的是，本文的独特切入是把"一次探索"抽象为可复用的世界空间轨迹，而不是一段定稿视频。已有合成数据要么渲染一次就固定下来（数据即视频），要么围绕交互延迟构建仿真器（数据即接口），二者都无法在保留共享因素的同时规模化变体。WorldRover 把路线、时序与场景结构作为可重放的中间产物保存：同一条轨迹可派生三种视角、多种环境状态与白模变体，任何一对样本之间只有视角或外观一个因素不同，运动与几何严格一致，天然构成控制变量实验。此外论文强调"生产系统"而非"一次性数据集"：场景准备是每环境一次的固定成本，此后扩产只依赖 campaign 配置与渲染算力；并且每条标注与像素的关系被明确规定（同一 EXR 光栅化、渲染时相机、投影式点轨迹），从制度上排除了事后估计带来的噪声与错位。
核心方法
直觉上，WorldRover 像一座"虚拟摄影棚"：先由美术资产搭好舞台（一次性准备），再让虚拟摄影师沿自动规划的路线行走、离线精修每一帧，深度、速度、相机等测量值直接从渲染器读取而非从图像反推。技术路线分两半：编辑器侧在 Windows 主机做一次性资产处理——把商业 UE 资产包重存为 UE 5.5 可无头加载的统一形式、加载流式子关卡与 World Partition 单元、烘焙 NavMesh、在编辑器内制作各环境状态地图；服务器侧在多 GPU Linux 主机无头执行——用 SPEAR 作为控制面加载工程并创建 actor，稀疏路点经匀速重参数化、位置/朝向平滑与偏航率限幅转成逐帧关键帧写入 Level Sequence，交给 Movie Render Queue 渲染，每帧输出包含颜色、深度、速度三层的一次光栅化多层 EXR；宿主侧 worker 流式做色调映射、深度提取与全景拼接，每个 EXR 处理完即删除，中间存储有界。两半在版本化的磁盘交接点汇合，整个 campaign 无需编辑器会话即可重放。
核心创新是"探索即可复用轨迹"与"标注来自渲染器"两个思想。前者指同一条路线和场景结构支撑三种语义不同的观测：第一人称相机即 agent（相机轨迹就是动作来源，匹配自中心视频与具身导航）；第三人称由动画角色重放轨迹、跟随相机保持固定偏移，角色轨迹与相机轨迹是两个真实不同的运动；全景模式共享相机中心、仅帧组装不同。同一路线还能在其它环境状态或白模下重渲染，光照由 Lumen 实时求解，变化是物理的而非图像重着色。后者指颜色、深度、屏幕空间速度是同一瞬间的同一次光栅化，写入同一多层 EXR：深度按 $t=\frac{\log d-\log d_{near}}{\log d_{far}-\log d_{near}}$（$d_{near}=0.1$ m，$d_{far}=200$ m）对数量化成 16 位 FFV1 无损流；点轨迹由"反投影 + 逐帧重投影"几何生成，无匹配漂移，遮挡期位置照写、可见性独立成标志（amodal 2D 轨迹）；全景则弃用 UE 自带通道（会硬钳位高光），改为六张 100° FOV 透视面在线性光中余弦羽化拼接，保住 HDR。
方法步骤详情
流程可拆为八步。① 资产摄取：编辑器主机把资产包重存为 UE 5.5、加载流式内容、烘焙 NavMesh，输出无头可加载的统一场景。② 场景风格化：每个环境状态（日/晨/昏/夕/夜 × 晴/阴/雾/雪）制作为自带灯光 rig 的独立地图；曝光经离线路径一次性标定后写死、禁自动曝光，夜晚因此保持黑暗。③ 轨迹生成：NavMesh 规划器、反应式探索器或人工录制产出路线，经匀速重参数化、平滑与偏航率限幅转为逐帧关键帧，速度从 1.0/1.2/1.5 m/s 三档采样。④ 离线渲染：Movie Render Queue 以 Lumen 动态全局光照逐帧累加两个空间子样本抗锯齿，输出颜色+深度+速度三层 EXR。⑤ 流式后处理：worker 池逐帧做色调映射与深度提取；全景序列另渲染六个 1536² 立方面，重投影到 4096×2048 等距柱状图，余弦羽化拼接、纬度加权估计曝光并压缩动态范围。⑥ 并行调度：瓶颈在 UE 游戏线程，单实例只占一小块 GPU，故每 GPU 跑多实例、RGB 走硬件编码器、实例跨序列复用，看门狗清理异常实例。⑦ 标注抽取：查询像素用种子帧深度反投影成世界点、逐帧投影回图像得到 2D/3D 轨迹与可见性（角色点刚体绑定根位置+偏航，另有蒙皮 LBS 变体）；相机轨迹取自渲染侧车；动作流把相邻帧速度差分到第一人称相机系四轴量化写入。⑧ 质检：格式屏（齐全、可解码、长度一致）与质量屏（曝光失准、相机穿模、路线打转即弃）。
技术新颖性
与相近工作的本质区别有三。其一，对比 Syn4D（通用多视角相机阵列 + BEDLAM 人物）与 OmniX（80K 场景、1.28M 多视角视频但无动作流），WorldRover 定义了具有不同遍历语义的三个视角：第一人称相机即 agent、第三人称相机与角色轨迹分离、全景与透视共享相机中心，且附带环境状态与白模的外观控制变量。其二，对比 PointOdyssey（104 段、平均约 2,000 帧），本文点轨迹是几何投影而非图像匹配，无漂移累积，2D 轨迹是 amodal 的——遮挡期位置照写、可见性独立成标志，不在遮挡段丢失监督。其三，对比录制游戏的路线（WildWorld 108M 帧、450+ 动作词表），本文从轨迹差分推导仅四个量化轴的动作流，语义干净且绑定相机系，可标注内容由渲染器完全决定而非取决于游戏截获钩子。工程上也有独到细节：白模用引擎 default-material show flag 一次性替换材质，而非逐组件改材质，规避了漏掉景观草与流式建筑的坑；每帧一次光栅化保证颜色/深度/速度严格逐像素配准。
实验结果
作为数据引擎论文，主要产出是规模与多样性指标而非基准成绩。当前发布含 32 个环境、6,003 条序列、21.9M 帧、202.7 小时、18.65 TB：第一人称 23 个场景、2,910 条、10.8M 帧、100.5 h、5.9 TB（数据集名称中的 10M 即指这批帧）；第三人称 7 个场景、1,885 条、8.3M 帧、76.5 h、4.4 TB（独占光流与点轨迹）；360° 全景 15 个场景、1,208 条、2.8M 帧、25.8 h、8.4 TB（4K 使单位时长体积最大）。三种轨迹来源为 NavMesh 规划 3,662 条、反应式探索 1,996 条、路点录制 345 条，时长中位数依次 115 s、81 s、105 s，单条中位路程 122 m，平均速度呈 1.0/1.2/1.5 m/s 三个簇。按类别城市最多（2,128 条），其后城镇/年代 1,668、室内 639、历史/奇幻 633、赛博朋克 603。资产库含 30+ 商业级 UE 场景与 70+ 动画角色。必须注意：论文明确声明未报告任何下游训练结果，并把"训练并测标准基准"列为下一步。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 长时程跟踪训练数据规模 | 视频段数 × 平均帧长 | 第三人称子集 1,885 段、8.3M 帧，分钟级序列（中位约 81–115 s） | PointOdyssey：104 段、平均约 2,000 帧 | 段数约 18 倍、总帧数约 40 倍，且轨迹为无漂移的几何投影、含 amodal 可见性标注 |
| 动作条件视频/世界模型数据 | 帧数与动作标注形式 | 21.9M 帧；四量化轴（前后/左右/转向/垂直）的轨迹派生动作流 | WildWorld：108M 帧、450+ 动作词表（录制游戏） | 规模更小，但动作语义由几何严格推导、与相机系绑定，可控性与配准更干净 |
| 多视角配对观测 | 同一轨迹的视角/外观变体数量 | 第一/第三/360° 全景三种视角 × 多环境状态 × 白模，几何与运动严格一致 | Syn4D：通用多视角相机阵列；OmniX：1.28M 多视角视频但无动作流 | 视角语义明确（自中心/跟随/全向）且提供外观控制变量配对样本 |
局限与改进
作者承认三点局限：① 每条第三人称序列只有一个被轨迹标注的独立运动角色，其他动态场景元素未单独控制或标注；跟随相机骑在角色后上方数米处，路线不保证该处可通行，杂乱场景中可能穿入几何体，此类序列在质检中被直接丢弃。② 动态全局光照加美术资产不模拟传感器效应——噪声、卷帘快门、镜头畸变全部缺失，与真实视频仍有域差。③ 本文只报告流水线与数据本身，没有任何下游结果。我补充几点观察：场景库虽达 30+ 但均为商业授权资产，再分发与题材扩展受限；速度只有三个离散簇、动作词汇仅四轴，对精细操纵类任务可能不够表达；三个视角的场景覆盖并不重合（23/7/15 个场景），跨视角配对受子集交集限制；18.65 TB 体量加双主机（Windows 编辑器 + Linux 渲染）架构使完整复现门槛不低；与估计型标注不同，渲染深度固定裁剪在 0.1–200 m，超远场景（大尺度城市远景）的深度监督在该范围外无效。
独立分析的弱点
独立分析四点弱点。① 跟随相机可通行性无保障：第三人称相机偏移固定，复杂场景易穿模导致序列报废，改进方向是让相机偏移自适应、引入遮挡感知的相机放置或简化碰撞体。② "静态世界"假设：除主角外场景无独立动态物体，用此数据训练的世界模型可能低估多主体交互与突发事件，改进方向是引入脚本化 NPC 群与可动物体并纳入轨迹/光流标注（当前光流其实已含所有像素运动，但缺少物体级身份）。③ 光照真实度上限：Lumen 虽动态但无传感器仿真，做真实域训练数据存在差距，可控地加入相机噪声模型、景深、运动模糊与镜头畸变即可大幅拓宽用途。④ 缺评测闭环：数据质量只能靠格式屏与质量屏保证，没有"同规模真实数据/合成数据训练同一模型"的对照，建议发布官方基准任务（深度、光流、长程跟踪、动作条件生成）与数据划分。另外场景类目分布偏城市（2,128/6,003），室内仅 639 条，做室内具身导航的研究者可能需要定向扩产。
未来方向
作者明确提出：为第三人称序列引入多个被跟踪角色、使跟随相机具备遮挡感知；加入传感器效应建模（噪声、卷帘快门、畸变）；在发布数据上训练并测量标准基准。在此框架上还能自然延伸：其一，用环境状态配对与白模-纹理配对训练粗到细生成器、反照率/光照解耦或重光照模型——几何与运动固定、外观是唯一学习目标，是理想的消融数据。其二，用第一人称动作流做动作条件视频生成与世界模型预训练；用第三人称的角色/相机双轨迹研究"区分相机运动与非刚性主体运动"。其三，全景子集（4096×2048，与透视共享相机中心）可用于全向感知、透视-全景蒸馏与 360° 视频生成。其四，引擎按场景×状态×角色×路线×视角组合扩产，天然适合做下游 scaling law 实验。其五，把三种轨迹策略与三档速度作为可控多样性来源，研究路线分布对导航策略泛化的影响；六面立方体拼接与标定式固定曝光的做法也可迁移到其他引擎的数据生产。
复现评估
开源情况较好：项目页、代码与数据均公开——数据在 HuggingFace（xjxu21/WorldRover），代码仓库 AlayaLab/WorldRover，项目页 alayalab.github.io/WorldRover。发布格式规范明确（Table 1）：H.264 硬件编码视频、16 位对数量化深度 FFV1 无损流 + 解码 sidecar、16 位仿射量化光流 FFV1 流 + sidecar（第三人称专属，默认尺度 $g=64$ 像素/帧）、逐轨迹 3D 位置/2D 投影/可见性表、相机与角色轨迹表、量化轴事件动作流、描述清单与路线俯视图，深度与光流均可仅凭发布文件独立解码。复现难度中高：渲染需 Windows 编辑器主机（一次性资产处理）加多 GPU Linux 渲染主机、UE 5.5 与商业授权资产包；完整重建 18.65 TB 数据的算力与授权成本可观，但研究使用通常只需下载所需子集；每条序列带渲染配置与描述清单，单条样本可精确复现。论文未给出渲染吞吐的具体数字（如每小时帧数），估算算力成本需自行基准测试。
论文图表
数据集总览图，四行自上而下：第 0 行展示一个 UE 环境中的三条路线（相机锥体）及每条路线上的四个关键帧；第 1 行展示同一瞬间的第一人称、第三人称与 360° 全景 RGB 观测（各带指标深度小图）；第 2 行展示第一人称视图在不同天气、不同光照与白模材质下的重渲染，场景、运动与相机保持不变；第 3 行展示稠密光流与 2D/3D 长程点轨迹，轨迹逐帧存 3D 位置、2D 投影与可见性。
一张图看懂数据集的全部卖点：同一探索的多视角、多外观、多模态标注。先看这张图能建立对"控制变量式配对数据"的直觉，是理解全文动机与组织方式的入口。
全景组装四步流程：(a) 渲染关闭色调映射的六张 100° FOV 立方面（相邻 10° 重叠），共享同一辐射度量尺度；(b) 重投影到等距柱状图，可看到侧面枕形畸变与极帽；(c) 在线性光域用余弦加权羽化把重叠带无缝融合成线性 HDR 全景；(d) 用纬度感知的亮度加权估计曝光并跨帧平滑，经 base/detail 色调映射压缩动态范围后转 sRGB。
解释了为何不直接用 UE 全景通道（其会硬钳位高光、丢失 HDR）以及 4096×2048 全景数据是如何保证辐射一致与曝光稳定的，是使用全景子集的技术背景。
同一第一人称帧在五种环境状态（白天、黄昏、夜晚、火光、雾）下的渲染对比。因为光照是渲染时模拟而非烘焙，间接光照、颜色渗透与阴影柔度随状态物理正确地变化；每个状态使用各自标定的固定曝光、渲染时禁自动曝光，夜晚保持黑暗而非被归一化到中灰。
这是"外观控制变量"能力的直观证明：几何与运动完全相同、只有光照/天气不同，正是训练重光照、解耦与鲁棒表征所需的配对样本。