← 返回文章列表

从 3DGS 到世界模型:论文更新里的四条渲染路线

PenguinWiki 最近收录的一批图形学论文,把静态高斯、动态高斯、occupancy 世界模型和生成式 4D 场景放在了一张地图上。这里按“它究竟在表示什么、能不能控制什么”重新梳理一遍。

PenguinWiki 在 2026 年 10 月 28 日更新了一批渲染方向论文摘录:3D Gaussian Splatting(3DGS)、4D Gaussian Splatting(4DGS)、神经重光照,以及世界模型和可渲染场景。论文数量很多,但真正值得先分清的不是模型名字,而是它们正在表示什么状态,以及这个状态能不能被时间、动作和物理约束改变。

这篇先把四条容易混在一起的路线拆开:静态场景的 3DGS、已捕获动态场景的 4DGS、流式 occupancy 预测,以及把视频世界模型当作数据机器的 4D 场景生成。

先看一张路线图

路线主要表示时间或控制更适合回答的问题
3DGS带空间范围、透明度和视角相关颜色的 3D 高斯通常是静态、逐场景优化“从另一个视角看这段已捕获的场景会怎样?”
4DGS随时间变化的高斯位置、外观和透明度按时间查询,通常不是动作条件“这段动态场景在另一个时间/视角是什么样?”
GaussianWorld流式 3D/4D 语义 occupancy 状态由连续传感器帧递推“当前和下一时刻哪里被什么占据?”
DriveDreamer4D世界模型生成的视频数据,再训练 4DGS可由新轨迹等结构化条件控制数据生成“如何补足真实驾驶数据里没有的轨迹?”

表里的“更适合”很重要:它们都可能输出看起来像场景的结果,却不代表它们都拥有网格、材质、碰撞和可重光照能力。

1. 3DGS:把静态场景变成可泼溅的显式表示

Kerbl 等人的 3DGS 从多视图图像和相机位姿得到的稀疏点开始,为每个点建立一个带位置、协方差、透明度和球谐颜色的三维高斯。协方差让高斯可以沿表面展开,而不是只能用一个固定半径的圆点覆盖场景。

训练时,三维高斯被投影成屏幕上的椭圆核,再按屏幕 tile 分桶、按深度排序并进行 alpha 合成。优化和密度控制交替进行:需要更多表示容量的地方 clone 或 split,贡献不足的高斯则 prune。这样做的关键变化是:相比 NeRF 对每条射线反复采样空空间,3DGS 把场景表示变成更接近 GPU 光栅化的数据流。

论文报告了 1080p 新视角合成的实时显示,但这只是论文数据集、实现和硬件条件下的结果。3DGS 仍然是逐场景优化的辐射表示:它不自动给你水密网格、物理材质、光照重新求解或碰撞体。

2. 4DGS:给高斯加上时间,但不等于世界模型

4D-GS 的做法是用 3D Gaussians 和 4D neural voxels 表示动态场景,再让轻量 MLP 根据时间预测高斯的形变,最后复用 Gaussian Splatting 渲染器生成新视角。论文在 RTX 3090、800×800 配置下报告了约 82 FPS。

这条路线解决的是“一个已捕获的动态场景怎样被压缩并回放得更快、更连续”。时间变量进入形变预测,训练目标仍然是多个时间和视角下的光度重建。因此,4DGS 可以很好地描述训练时间范围内的动态外观,但不能仅凭这个机制回答“如果角色采取另一个动作,场景会怎样”。

这里有一个经常被忽略的边界:

  • 按时间查询是回放或插值;
  • 按动作查询才更接近世界模型;
  • 满足碰撞、接触和动力学还需要额外的物理状态与验证。

4DGS 可以作为捕获背景、过场或远景代理,但交互角色和物理对象仍然需要网格、骨骼、PBR 材质以及专用模拟。

3. GaussianWorld:高斯也可以承载 occupancy 状态

GaussianWorld 把自动驾驶里的流式三维语义占用预测重新表述成由当前传感器输入条件化的 4D occupancy 预测。它显式维护稀疏语义 3D Gaussian,并把场景演化拆成三部分:

  1. 根据自车轨迹对齐静态场景;
  2. 更新动态物体的局部运动;
  3. 为自车移动后出现的新区域初始化并补全高斯。

论文在 nuScenes 流式设置下报告 GaussianWorld IoU 33.02、mIoU 21.87,并称相较单帧对应模型 mIoU 提升超过 2%、没有增加额外计算量。这些数字对应论文指定的数据、模型和评估设置,不能直接当成所有传感器和序列长度下的保证。

更重要的是输出定义:这里的高斯主要承载语义占用状态。occupancy 告诉我们哪里有物体或空间被占据,却没有自动提供颜色、粗糙度、BRDF、光源和自由视点 RGB 渲染器。把 GaussianWorld 当成 3DGS 渲染器,会把“场景状态”和“场景外观”混为一谈。

4. DriveDreamer4D:让世界模型成为数据机器

DriveDreamer4D 的思路不是把视频世界模型直接当作最终渲染器,而是先用它生成真实数据里缺少的新轨迹视频,再和真实视频一起训练 4DGS。

它的 Novel Trajectory Generation Module(NTGM)从原始自车轨迹提出变道、加速、减速等新轨迹,并用道路可行性和与行人/车辆的最小距离做安全检查。随后,轨迹框、高清地图等结构化信息与首帧、文本或控制条件一起送入可控视频扩散世界模型,得到新轨迹视频。Cousin Data Training Strategy(CDTS)再把原始轨迹和时间对齐的新轨迹组成“表亲数据”对,共同优化 4DGS。

Waymo 实验中,论文在新轨迹视角上报告了相对 PVG、S3Gaussian、Deformable-GS 的 FID 改善,以及驾驶主体 NTA-IoU 的相对提升。这里的贡献是扩充训练分布,而不是声称已经获得了通用、物理完备的驾驶模拟器。合成视频仍可能有飞点、重影、相对位置误差和分布偏差;新轨迹的深度监督也不完整。

对游戏开发者的实际启发

把这四条路线放回内容生产流程,选择会清晰很多:

  • 想把实拍环境做成可自由视角的背景或预演素材,可以先看 3DGS;
  • 想回放一段已捕获的动态表演,可以看 4DGS;
  • 想做驾驶感知、可通行空间或连续传感器理解,应关注 occupancy 世界模型;
  • 想覆盖真实数据里没有的驾驶轨迹,可以研究“世界模型生成数据 → 4DGS 重建”的管线。

但如果目标是一个可以让玩家自由走动、换灯光、发生碰撞并长期运行的游戏世界,仍然需要把表示拆成几层:网格或高斯负责几何/外观近似,PBR 材质和光照负责可重光照,碰撞体和动力学负责物理,世界模型负责预测时还要有独立的任务与不确定性验证。没有哪一个论文关键词可以替代整条运行时管线。

一条值得保留的判断标准

阅读这批论文时,我会连续问四个问题:

  1. 它表示的是 RGB 外观、几何表面,还是 occupancy 状态?
  2. 时间输入是在做插值/回放,还是在预测状态转移?
  3. 是否有动作条件,动作是否真的改变了未来状态?
  4. 论文评估的是视觉一致性,还是也验证了碰撞、接触、可通行性和任务成功率?

这四个问题能把“看起来像世界”的结果,与“可以在世界里行动”的系统区分开来。PenguinWiki 的新页面也正是沿着这条边界,把 3DGS、4DGS、occupancy 和可渲染世界模型放到同一张知识地图上。

继续阅读

输入关键词开始搜索

滚轮或双指缩放 · 拖动平移 · 双击放大 / 还原