Magpie: Real-Time World Renderer for Interactive Games
Xiaoyu Zhan, Xinyu Wang, Xiaohong Zhang, Huanjie Zhu, Tengjiao Sun, Pengcheng Fang, Jiaxing Yu, Yanwen Guo, Dongjie Fu
cs.CV
2026-08-27
Magpie 用游戏引擎结算玩法并输出白盒帧，Wan2.2-5B 只负责画画面。单卡 H100 算力吞吐约 32.2 FPS，动作到对应画面约 1.55 秒，训练数据约 300 小时人工对局。
游戏不是按时间展开的视频。同一套动作和状态，必须在规则下保持稳定含义，设计师才能改数值、复现场景、把原型做成产品。引擎里的碰撞体、冷却、隐藏触发器，在最终画面上几乎看不出来，却是玩法的真源。
视频生成模型已经能出很好看的材质和光影，单独用它当游戏，规则和状态撑不住。键盘条件、文本插事件的世界模型，都不能保证遵守作者写死的玩法。原型阶段如果还要走完建模、贴图、绑定、灯光、优化，视觉资产会把迭代拖死。
Magpie 把职责切开。设计师在引擎里摆布局、写规则；Game Engine 结算玩家动作、维护世界状态，输出白盒画面（去掉最终材质和复杂光照，保留空间占用、碰撞边界、主要轮廓和可见状态变化）；独立的 Render Server 只负责把白盒变成成品画面。
初始化时，Render Server 收一条文本和一张首帧图，用来定风格和角色外观。之后交互里，白盒帧是唯一持续的去噪条件，相机位姿只用来检索与当前视角相关的历史帧。玩家动作、对象属性、事件信号全部留在引擎，不进生成模型。生成错了最多让反馈变糊，改不了碰撞和进度。
渲染器基于 Wan2.2-TI2V-5B，采用 Helios 的有界多尺度上下文、分层生成和少步蒸馏。白盒注入试了三种：直接塞进噪声 latent（结构跟得紧但细节被压掉）、AdaLN（块内有效、块边界跳变）、cross-attention（质量和结构跟随的折中）。现行方案用 cross-attention。历史按固定顺序拼：早期锚点块稳住初始化外观，FOV 重叠检索支持回看，最近生成块维持局部连续。蒸馏把多步教师压到 3 步学生，再用 self forcing 对齐「训练看真视频、推理看自己生成历史」的差距。部署用 LightTAE 和 FP8。
数据来自 30 多个 Unreal 场景、约 300 小时人工对局，1920×1080@60FPS，成对记录高保真与白盒、相机位姿。操作员按玩家方式玩，覆盖走跑跳、开车、坐下、碰撞和大量 idle。复杂战斗和多人协作还没铺开。
这是系统实现论文，没有和 Matrix-Game、DreamX 一类世界模型做同协议画质对照。给的是可复现的运行数字。
单卡 H100 上，蒸馏后的 5B 渲染器稳态一块（20 帧）约 620 ms，算力侧约 32.2 FPS，峰值显存约 34 GB，输出 1280×768。交互管线按 24 FPS 走。端到端延迟被块边界卡住：引擎先录完 20 帧白盒约 0.83 s，传输编码约 0.1 s，推理解码 0.62 s，动作到对应画面大约 1.55 s。后续块按约 830 ms 的显示窗往外推。
作者把生成渲染的评价落在三件事上：长程记忆、跟白盒的结构一致、整体观感。正文用图展示基座自回归模型和蒸馏实时模型，没有报告 LPIPS、FVD 或结构对齐的定量分数。
对做玩法的人，这条路径让白盒原型在资产没齐之前就能接近目标观感，规则和状态仍然可以检查、修改、复现。对做视频世界模型的人，它给出一个明确边界：模型不要去猜规则，只画引擎已经结算完的结果。
现在还不能当正式游戏渲染器。1.55 秒的反馈对射击、格斗这类要即时手感的品类不可用，32.2 FPS 的算力吞吐也还够不上主机游戏预期。更接近的用法是预演、风格探索、早期体验评审。
作者列得很清楚。块式预录是延迟主因，需要改成帧级流式，让引擎、编码、生成、显示重叠。单张 RGB 白盒有深度歧义，薄结构和同色区域容易画错空间关系。快速运动、大视角变化、遮挡时，生成几何和角色位置会漂。训练目标的视觉质量覆盖不够，缺少音频，记忆还是有界的二维历史而不是可更新的三维场景。34 GB 也上不了端侧。
另外，论文没有把「生成画面是否遵守白盒」做成可报告的结构误差指标。没有这条数字，就很难判断系统在多大程度上真的把规则锁死了。