李飞飞旗下 AI 世界模型公司 World Labs 发布并开源了一个最新成果：Spark 2.0。
这个专为网页端设计的动态 3D 高斯点云（3DGS）渲染引擎，让在任何设备的浏览器里流畅运行上亿粒子的超大 3D 场景，开始逐渐成为现实。
https://www.worldlabs.ai/blog/spark-2.0
1. 连续 LoD 树：把好钢用在刀刃上
LoD（Level of Detail）在游戏圈早已是成熟概念。近处的树用几千个三角形，远处的树只留几十个，按需分配，省算力。Unreal Engine 的 Nanite 系统也是这个思路，把三角形细节和视距挂钩，自动缩放。
Spark 2.0 把同样的逻辑搬到了 splat 上，做得更彻底。
离散切换几个版本容易产生画面「跳变」，Spark 的做法是构建一棵完整的「连续 LoD 树」，每个内部节点都是其子节点 splat 融合后的近似版本，层层向上汇聚，最终到达根节点，也就是整个场景最粗粒度的单一 splat。
渲染时，系统根据当前视角在这棵树上动态划一刀，靠近视角的区域取底层细节，远处取高层粗粒度。
整个过程受一个固定的 splat 预算约束，移动端约 50 万，桌面端约 250 万。场景里总共有多少 splat 都无所谓，实际送上 GPU 的数量始终稳定在预算范围内，帧率自然稳了。
在此之上，Spark 还引入了「注视点渲染」（Foveated Rendering），把更多预算集中分配给你正在看的方向，边缘和背后的区域细节自动收窄。这个效果放在 VR 设备上尤其直观，通常需要眼动追踪才能实现，Spark 用固定锥形区域近似模拟，同样奏效。
2. 全新 .RAD 格式：像刷短视频一样「流式」加载
渲染效率的问题解决了，传输效率的问题同样棘手。现有的 3DGS 文件格式有两个：.PLY 和 .SPZ。前者未压缩，10M splat 高达 2.3 GB，虽然可以边下边显示，但体积实在吃不消。
后者用列式存储加 Gzip 压缩，同等数据量压缩到 200-250 MB，代价是必须等整个文件下载完才能显示，因为每个 splat 的属性分散在文件各处，缺了哪一段都拼不出完整内容。
为了鱼和熊掌兼得，Spark 2.0 设计了新格式 .RAD（RADiance fields）。它把 splat 数据切成每块 64K 个 splat 的独立小块，分别压缩，并在文件头中记录所有块的字节偏移位置，支持随机访问任意一块。
第一块永远是整个场景最粗粒度的 64K 个 splat，下载完毕后场景轮廓立刻可见。此后系统根据视角判断哪些区域最需要细化，优先拉取对应的数据块，画面从模糊逐渐推演出细节。3 个并行的 Web Worker 线程在后台同步拉取和解码，你走到哪，细节就跟到哪。
3. GPU 虚拟内存：在有限显存里装下无限空间
流式加载解决了带宽的问题，但 GPU 内存的硬上限依旧是个难啃的骨头。移动端浏览器对显存有严格约束，塞不下整个 4000 万 splat 的场景。
从已有的落地案例来看，开发者确实在用 Spark 做各种方向的尝试。Webby 奖得主 James C. Kane 独立开发了一款名为 Starspeed 的多人宇宙飞船射击游戏。
4.应用案例
整个游戏场景由超过 1 亿个 splat 构建，附带 10 首合成波风格原声音乐，全部通过浏览器以 .RAD 格式流式加载，惊艳的科幻环境可以直接在网页里跑起来。
附体验地址：https://starspeed.game/
艺术方向则有 Hugues Bruyère 的《Dormant Memories》。他是互动体验工作室 Dpt. 的联合创始人，这个系列把真实地点的 3D 扫描和想象中的空间并置在一起，做成可探索的交互环境。现实与虚构之间的边界在 splat 颗粒感里变得模糊，倒是意外地切题。
附体验地址：https://smallfly.com/dormant_memories/
来自 Hololive 空间信息技术部门的藤原龍则用 Spark 渲染了多个大型真实捕获场景，单场景最高达到 4000 万 splat，在智能手机、Quest 和 Vision Pro 上均能流畅运行