来源:3DGS 技术调研笔记与外部公开资料汇总
面向读者: 图形程序员
3D 高斯泼溅(3D Gaussian Splatting,3DGS)用几百万个各向异性高斯椭球表示场景,再用一个 tile-based 可微光栅器把它们投影、排序、α 混合成图像。它把 NeRF 那套「逐像素沿光线跑 MLP」整个换掉了:渲染从 0.06 FPS 到 134 FPS,训练从 48 小时压到 41 分钟,代价是存储与显存涨 85 倍。
对 UE 来说,它现在的角色很明确——一个只读的舞台背景。渲染它已经不难,第三方插件做到了十亿级高斯 60–120 FPS;难的是让它和几何、光照、物理、后处理讲同一种语言,而这四件事目前都还没有通用解。
目录
- 定位:它是什么,不是什么
- 前史:NeRF 卡在哪里
- 方法:显式高斯椭球与可微光栅化
- 账本:换来什么,付出什么
- 2026 现状:前馈化与标准化
- UE 集成:为什么没有第一方模块
- UE 里的实际可用边界
- 为什么不建议直接转成 Static Mesh
- 尚未解决的问题
- 附录 A:完整演进链路
- 附录 B:核心概念速查
- 参考链接
一、定位:它是什么,不是什么
3DGS 属于新视角合成(Novel View Synthesis,NVS):从多视角照片或视频出发,重建一个可实时渲染、可从任意角度观看的照片级场景表示。它重建的是外观和光照,不是严格的几何测量模型。
有三点必须精确,否则后面所有工程判断都会整体偏掉。
1.1 产物是”可渲染的辐射场”,不是”3D 模型”
传统三维重建的产物是网格——有拓扑、有 UV、有材质球、能进 DCC 编辑。3DGS 的产物是几百万个高斯椭球的参数集:没有面、没有边界、没有材质概念,无法选中”那面墙”然后给它换个贴图。
Framestore 在《超人》项目里对它的用词很准确——“living photography”(活的摄影),而不是 “3D model”。
⚠️ 更准确的定位是:3DGS 干的事更接近”把照片变成可以走进去的空间”,而不是”把照片变成模型”。这个区别直接决定了它能做什么、不能做什么。
1.2 “几张照片就能重建”目前是研究前沿,不是工程现实
原版 3DGS 要求密集多视角输入,并且需要预先用 COLMAP 一类工具算出相机位姿。
| 方法 | 输入视角数 | 需要预先算位姿 | 说明 |
|---|---|---|---|
| 原版 3DGS(2023) | 密集多视角(几十~几百张) | 需要(COLMAP) | 拍得越多、覆盖越全越好 |
| CF-3DGS(2024) | 视频 | 不需要 | 从连续视频帧直接重建 |
| SparseGS(2025) | 3–12 张 | 需要 | 稀疏视角专用 |
| InstantSplat(2024) | 6–12 张 | 不需要 | 重建 <1 分钟 |
| DropGaussian(2025) | 少至 3 张 | 需要 | 结构化正则 |
| Splatter Image / Flash3D | 单张 | — | 单目重建,本质是”猜” |
论文对原版方法的措辞很直白:vanilla NeRF 与 vanilla 3DGS 都对重建条件提出了 stringent requirements——输入图像数量、拍摄角度、光照一致性都有硬要求。
实际工程经验值:有人用 iPhone 16 Pro 超广角拍了 600 张才完整覆盖一个厨房,换成鱼眼镜头后降到 205 张。稀疏视角(<20 张)目前仍会出现背景塌陷、浮点噪声、几何不一致。
⚠️ 少视角意味着几何约束不足,模型只能靠先验去填——要么用深度估计先验(DNGaussian、LM-Gaussian),要么用扩散模型生成(Generative Sparse-View GS,CVPR 2025)。用生成模型补出来的部分不是”重建”,是”编造”,这在需要真实性的场景里是致命的。
1.3 逐场景训练,不能泛化
原版 3DGS 对每个场景都要单独跑一遍优化(约 20–40 分钟),换一个场景全部重来。这正是 2025–2026 年前馈式 3DGS 成为最热方向的原因——目标是训一次模型、对所有场景通用。
1.4 与其他三维获取方式的关系
| 方式 | 强项 | 卡在哪 |
|---|---|---|
| 摄影测量(普通照片建三角网格) | 产物是可编辑网格,管线成熟 | 对光滑、反光、透明、无纹理表面(玻璃、金属、水面、白墙)经常失败,破洞、扭曲、噪点;毛发、树叶细节也难处理 |
| 仪器扫描(LiDAR、结构光、手持扫描仪) | 精度可达毫米甚至亚毫米级,适合工程测量、逆向工程、数字孪生 | 设备贵、操作麻烦,对大场景和复杂外观仍有局限;纹理与光照效果不如照片真实,后期贴图是额外工作量 |
| 3DGS | 普通手机/相机拍一圈(甚至一段视频)即可,照片级真实感 + 实时渲染,特别擅长反光、半透明、复杂光照 | 不追求绝对几何精度(误差通常厘米级),不适合精确测量 |
3DGS 的合适场景是可视化、VR、数字内容、游戏场景这类要好看而不是要准的地方。
二、前史:NeRF 卡在哪里
2023 年之前,这个领域被两条路线同时卡住。
2.1 路线 A:显式几何(网格 / 点云 / 纹理)
摄影测量、激光扫描、重建网格都属于这条路线。
- 优势:直接跑在光栅化管线上,快。
- 死穴:表达不出复杂的光照现象。网格 + 纹理是”表面颜色”,没法表达视角相关的高光、半透明、体积雾、复杂的反射折射。重建出的网格在细节和破损区域还需要大量人工清理。
这条路线的问题不是”不够快”,而是表示的表达力天花板——无法把一个反光玻璃杯的视角相关外观,塞进一个只带 albedo 贴图的三角面里。
2.2 路线 B:隐式神经场(NeRF,2020)
NeRF 用一个 MLP 把场景编码成连续函数:输入是 5 维(3D 空间坐标 + 2D 视线方向),输出是颜色 + 密度。渲染一张新图时,对每个像素发射一条射线,沿射线采样数百个点、每个点跑一遍 MLP,再把颜色和透明度累加起来做体渲染。
- 优点:效果非常真实,能捕捉反光、透明、复杂光照。
- 缺点:训练要几小时到几天,渲染一张图也要几秒甚至更久。实时应用(游戏、VR、手机)基本做不到。
2.3 核心矛盾:隐式表示把”场景”藏进了网络权重
⚠️ 3DGS 论文真正的洞察不在于”高斯好用”,而在于它指认了 NeRF 慢的根因是”表示形式”,而不是”实现不好”。因为表示是隐式的,四个问题同时出现:
| 隐式表示带来的问题 | 具体表现 |
|---|---|
| 渲染慢 | 每个像素都要独立地、从头跑一遍网络 |
| 训练慢 | 梯度必须穿过整个 MLP 反向传播 |
| 不可编辑 | 想局部改一个物体?场景里根本没有”局部”这个概念,改一处等于动全局权重 |
| 硬件错配 | GPU 有极强的大规模并行光栅化单元,但 NeRF 一个也用不上 |
第四点尤其讽刺:图形学界花了几十年优化光栅化硬件,NeRF 却完全绕开了它。
2.4 中间态的尝试,以及它们为什么不够
在 3DGS 之前,学界做过一轮”加速 NeRF”的努力:
- Instant-NGP:用多分辨率哈希编码替代大 MLP,训练从小时级降到秒级到分钟级
- Plenoxels / SNeRG:用稀疏体素网格或延迟计算,把渲染推到 30 FPS 上下
但它们有一个共同的天花板:仍然在做”沿光线积分”。只要还沿光线采样,渲染成本就被采样密度锁死,只能在质量上妥协换速度——最快也就到 10–15 FPS 量级,且峰值质量不如 Mip-NeRF 360。
要真正突破,必须放弃”沿光线积分”这件事本身。
2.5 所以 3DGS 想要什么
3DGS 就是为了解决 NeRF 的”又慢又难实时”问题,同时保持甚至超越它的画质。目标很明确:
- 训练更快(几分钟到几十分钟)
- 渲染实时(轻松 100+ FPS,甚至手机也能跑)
- 画质超高
- 场景更容易编辑(因为是显式表示,而不是黑盒神经网络)
三、方法:显式高斯椭球与可微光栅化
核心思路:用大量可学习的 3D 高斯椭球来显式表示场景,而不是用隐式的神经网络。
换个说法:从”从相机发射光线去问场景”,反过来变成”从场景把图元投影到屏幕上来”。 前者叫 ray marching,后者叫 splatting。
3.1 为什么偏偏是高斯
选高斯不是审美偏好,是因为它有一个别的图元没有的性质:
一个 3D 高斯投影到 2D 图像平面上,仍然是一个 2D 高斯——而且这个投影有解析闭式解。
这意味着渲染时不需要任何采样、任何迭代、任何网络求值。从 3D 到屏幕,本质就是一次矩阵乘法:用透视投影方程在零点处的雅可比矩阵 J 做线性近似,把 3D 协方差 Σ 变成 2D 协方差 Σ’:
┌ f_x/t_z 0 -f_x·t_x/t_z² ┐
J = │ 0 f_y/t_z -f_y·t_y/t_z² │
└ 0 0 0 ┘
Σ' = J W Σ Wᵀ Jᵀ而高斯还有一个性质同样关键:它是可微的。所以整个光栅化过程可以反向传播,从而对着照片做梯度下降训练。
这就是 3DGS 的全部魔法来源:既像点云一样好渲染,又像神经场一样可微、能表达对应体渲染的成像模型。
3.2 血统:这条路二十年前就铺好了
3DGS 常被当作”凭空出现的新东西”,但它的渲染方法实际上是二十年前点渲染研究的一次成功复活。
| 年份 | 工作 | 贡献 |
|---|---|---|
| 2001 | Surface Splatting(Zwicker et al., SIGGRAPH) | 首次提出屏幕空间的 EWA(椭圆加权平均)滤波,用一个 “surface splat” 图元从无连接点云直接渲染出有正确透明度和抗锯齿的表面 |
| 2002 | EWA Splatting(Zwicker et al.) | 把 EWA 形式化为基于椭圆高斯核的通用 splatting 框架,同时覆盖体数据和点采样表面,处理非球形核 |
| 2004 | Perspective Accurate Splatting | 用齐次坐标修正透视投影的仿射近似误差,消除”洞” |
| 2023 | 3DGS | 用这套 splatting 数学 + 现代可微渲染与梯度优化,做成可训练系统 |
关键事实:3DGS 原论文的 2D 协方差计算,直接沿用了 EWA Splatting 的公式(原文第 29、31 式),只针对屏幕尺寸与宽高比做了修正。
所以 3DGS 真正的”新”在于:把 2002 年的 splatting 数学,接上了 2020 年代的可微渲染与端到端优化——让这套老光栅化方法第一次变得”可训练”。
3.3 每个高斯存什么
| 属性 | 维度 | 说明 |
|---|---|---|
| 位置 μ | 3 | 椭球中心 |
| 协方差 Σ | — | 决定形状、大小、朝向。关键:不能直接优化 Σ |
| 不透明度 α | 1 | 基础的 alpha 值 |
| 颜色 | — | 用球谐系数表示,支持视角相关 |
| 旋转 q(四元数) | 4 | Σ = R S Sᵀ Rᵀ 的 R |
| 缩放 s | 3 | Σ = R S Sᵀ Rᵀ 的 S |
为什么协方差要拆成旋转 × 缩放? 因为协方差矩阵必须保持半正定(否则不是一个合法的椭球),而直接对 Σ 做无约束梯度下降会破坏这个性质。拆成 Σ = R S Sᵀ Rᵀ 之后,R 由四元数参数化、S 由缩放向量参数化,两者的合法取值范围天然宽松得多,优化就稳定了。
球谐函数(SH)是干什么的? NeRF 能表达视角相关效果(高光、反射)靠的是把视线方向作为网络输入。3DGS 没有网络,就改用在球面上定义的一组基函数来编码”从不同方向看这个高斯是什么颜色”——系数是学出来的,基是固定的。低阶用 0 阶(纯漫反射),高阶用 3 阶(能表达各向异性高光)。
原论文的消融实验把这两个设计的价值量化了:
- 去掉各向异性(改为一个标量控制三轴半径)→ 质量明显下降。论文明确指出:各向异性让高斯能够”贴合”表面走向,相同点数下渲染质量显著更高。
- 加上球谐 → PSNR 提升,因为它补偿了视角相关效果。
规模:原论文测试的所有场景,最终生成 100 万到 500 万个高斯。
3.4 优化:自适应密度控制
题目是:一个场景该用多少个高斯?该撒在哪? 没人知道答案,也不能手工指定。
3DGS 的解法是让系统自己长出来:观察每个高斯位置属性在视图空间的梯度累积幅值。
- 梯度大 = 这个区域**“重建得不够”,模型在这里反复想动却动不到位 → 克隆(复制一个小高斯)或分裂**(把一个大高斯劈成两个小的)
- 高斯被优化到不透明度很低 = 它没用 → 剪枝移除
论文原文的描述是:优化过程中”添加,偶尔也移除”高斯,整个过程与参数优化交替进行。
⚠️ 这个机制的本质是把”资源分配”问题交给了梯度信号去自动求解——梯度是”模型在这里还差多少”的天然度量,用它当稠密化触发器,几乎不需要调参就能适配各种复杂度差异极大的场景。这也是后续几年最活跃的改进方向之一。
3.5 渲染:tile-based 可微光栅器
原论文自己明确说了:「我们方法效率的关键,是这个 tile-based 光栅器。」
流程拆开是这样:
- 剔除与变换:视锥剔除,把高斯变换到屏幕空间,算出每个高斯的 2D 均值、2D 协方差、深度
- 切 tile:把屏幕切成 16×16 像素的小块
- 算覆盖:对每个高斯,用它的 2D 投影 AABB 面积算出它压到了哪些 tile,建立 tile → 高斯列表的映射
- 深度排序:在每个 tile 内部,用 GPU 基数排序按深度给高斯排序
- α 混合:每个像素从前往后做 alpha 合成
- 反向传播:通过跟踪累积的 α 值实现快速反向传播
第 6 点是论文特别强调的设计优势:因为反传只依赖累积 α,所以**“可以接收梯度的高斯数量没有上限”**——不像逐 tile 的固定容量缓冲区那样会截断梯度。
这一步替换到底换掉了什么?
| NeRF | 3DGS | |
|---|---|---|
| 每像素做什么 | 独立地沿光线采样数百次,每次跑一遍 MLP | 只处理落在该像素所属 tile 里的那些高斯 |
| 计算组织 | 逐像素串行的采样循环 | 全图元并行投影 + 排序 + 混合 |
| 用的硬件 | 通用 ALU 跑推理 | GPU 光栅化单元 + 基数排序 |
| 视角相关颜色 | 把视线方向喂给网络 | 查球谐系数(几次乘加) |
这张表才是 3DGS 高性能的根本解释。它不是”把 NeRF 加速了”,而是换了一种与 GPU 架构对齐的计算形式——把大规模并行的规整工作交给本就为此设计的硬件,而不是让每个像素各自跑一段推理。
3.6 初始化:从 SfM 稀疏点云出发
训练不是从零开始的,而是从 Structure-from-Motion(SfM,通常是 COLMAP)产出的稀疏点云初始化高斯集合。
这个设计是一把双刃剑:
- ✅ 好处:跳过了”从二维照片猜三维几何”这个最难的问题,直接拿到一个合理的初始分布
- ❌ 代价:完整继承了 SfM 的失败模式——低纹理场景、弱视差、反光表面会让 SfM 算不出位姿,3DGS 直接崩。同时它把”位姿求解”变成了外置依赖,整个流程因此有一条脆弱的、耗时(SfM 随图像数呈平方级增长)的前置链路
⚠️ 这正是 2025–2026 年前馈式 3DGS 研究的全部动机——不是为了渲染更快(渲染已经够快了),而是为了杀掉 COLMAP 这个前置依赖,用单个网络一次前向直接回归出高斯。
3.7 一个高斯椭球长什么样
单个高斯本体是一个连续的概率密度函数——中心密度最高,向外平滑衰减。但看不见密度函数本身,看见的是它的等值面。原论文的做法是把指数部分设为 3²(即取 3σ 等值面),在这个面上切一刀,切出来的形状就是一个椭球。
Σ 与椭球的关系非常直接:
- Σ 的特征向量 → 椭球三个主轴的方向
- Σ 的特征值 → 三个主轴的半径
| 各向同性(isotropic) | 各向异性(anisotropic) | |
|---|---|---|
| 形状 | 球——三轴等长 | 椭球——三轴可任意不等 |
| 参数 | 一个标量半径 | 缩放向量 s + 旋转四元数 q |
| 表达能力 | 只能表示”一团” | 可以拉长、压扁、任意朝向 |
为什么必须各向异性? 因为要贴合表面。一个被压得很扁的椭球,沿着墙面铺开,可以用很少的图元精确表示一个平面;而球形高斯只能堆出一层”毛茸茸的雾”。
渲染时 3D 椭球 → 屏幕上的 2D 椭圆,靠的是一个很优雅的性质:3D 高斯沿一条坐标轴积分,结果仍然是高斯。这就是为什么从 3D 投影到 2D 有闭式解、不需要任何采样:
3D 椭球(世界空间)
↓ 视图变换 W
相机空间椭球
↓ 雅可比矩阵 J(透视投影的局部仿射近似)
Ray Space(光线被"掰"成平行)
↓ 丢掉第三行第三列(沿深度轴积分)
2D 椭圆 Σ' = J W Σ Wᵀ Jᵀ屏幕上的最终形态就是一个软边的椭圆——中心颜色浓、不透明度高,向边缘平滑淡出。这就是 “splat” 这个词的来源。
3.8 为什么只拟合几个已知角度,其他角度也能出图
关键在于它学到的是场景的三维结构和外观表示,而不是死记硬背某几张照片。
- 优化过程中,系统不断调整所有高斯的位置、形状、颜色、透明度,让从已知相机角度渲染出来的图尽可能和真实照片一模一样
- 因为高斯是真正放在三维空间里的,它们共同描述了”物体在哪里、表面长什么样、从不同方向看颜色怎么变化”
- 换一个全新的相机位置时,系统只是从新角度把这些已经优化好的 3D 高斯投影到屏幕上并混合,自然就能生成合理的新图像
这相当于用已知视角”约束”出了整个场景的三维表示,然后进行插值/外推。如果输入照片太少、角度覆盖不全,新视角就会出现模糊、空洞或伪影。
四、账本:换来什么,付出什么
4.1 与 NeRF 的实测对比
以下对比来自同一榜单、同一数据集、同一评测协议:
| 维度 | Mip-NeRF 360 | 3D Gaussian Splatting | 差距 |
|---|---|---|---|
| 渲染速度 | 0.06 FPS | 134 FPS | 约 2200× 更快 |
| 训练时间 | 48 小时 | 41 分 33 秒 | 约 70× 更快 |
| PSNR ↑ | 27.69 | 27.21 | 略低 |
| SSIM ↑ | 0.792 | 0.815 | 更好 |
| LPIPS ↓ | 0.237 | 0.214 | 更好 |
| 存储 / 显存 | 8.6 MB | 734 MB | 约 85× 更大 |
第三方复现(NerfBaselines)给出的平均数字也一致:
| Mip-NeRF 360 | 3DGS | |
|---|---|---|
| 平均训练时间 | 30 小时 14 分 | 23 分 25 秒 |
| 平均显存 | 33.61 GB | 11.14 GB |
| 平均 PSNR | 27.43 | 27.43 |
结论:3DGS 做的是「用存储和内存,换时间」。
NeRF 是计算时付出——每次看都要重算一遍;3DGS 是存储时付出——一次性把场景烤进几百万个高斯的参数里,之后每次看几乎不花什么。这也是为什么 3DGS 参数量比 NeRF 大两个数量级:NeRF 把场景压进了几 MB 的网络权重,3DGS 则是把它摊开成了几百万个显式图元。没有免费午餐,只是把账单换了个地方记。
4.2 其他必须付的代价
| 代价 | 说明 |
|---|---|
| 没有几何 | 高斯是”体积的云雾”,不构成水密表面。要网格得额外做提取(SuGaR / MILo / 2DGS 这一系) |
| 光照是烘焙的 | 颜色直接学了训练时的光照,无法重打光。这是影视落地最大的拦路虎 |
| 视角排序导致的伪影 | 图像空间图元排序会引入 popping / 闪烁 |
| 显存随场景线性膨胀 | 城市级场景直接爆显存 → 催生了 LOD、分块流式(SOG / 3D Tiles) |
| 对输入数据极敏感 | 覆盖不足 / 运动模糊 → 重建直接失败 |
| 无 AOV、无动画 | 影视合成管线要的深度、ID、运动模糊都得额外想办法 |
4.3 一页对比
| 方面 | NeRF | 3D Gaussian Splatting |
|---|---|---|
| 表示方式 | 隐式(神经网络) | 显式(一堆高斯椭球) |
| 渲染方式 | 射线行进 + 神经网络查询 | 光栅化(溅射 + 混合) |
| 速度 | 慢 | 实时(100+ FPS) |
| 可编辑性 | 很难 | 容易(可以直接移动、删除高斯) |
| 训练时间 | 较长 | 较短 |
五、2026 现状:前馈化与标准化
5.1 热度的量化证据
| 指标 | 数值 |
|---|---|
| 被索引的辐射场论文总数 | 3,333 篇 |
| 2026 年(截至 7/9)新增论文 | ≥749 篇,约每天 4 篇 |
| 追踪的 3DGS 平台/工具数 | 212 个 |
| 3DGS 相关岗位招聘 | 665 条 |
| 2023 年以来的相关新闻 | 992 条 |
顶会投稿量的增长速度更直观:
| 会议 | 2024 | 2025 | 2026 |
|---|---|---|---|
| CVPR | 67 篇 | 157 篇 | 已收录 |
| ICCV | — | 109 篇 | — |
| SIGGRAPH | 27 篇 | 35 篇 | — |
| NeurIPS | 70 篇 | 35 篇 | — |
| ICLR | 2 篇 | 42 篇 | 26 篇 |
| 季度归档量 | 2024/07:176 篇 | 2025/07:216 篇 | — |
季度归档 216 篇意味着平均每天有 2–3 篇 3DGS 论文被顶会接收。这是一个领域处于高速扩张期、而非退潮期的典型特征。
5.2 技术演进主线:2023 → 2026 的三级跳
阶段 1(2023.08):原版 3DGS 问世
Inria 的 Kerbl 等人发表 3D Gaussian Splatting for Real-Time Radiance Field Rendering,用各向异性高斯椭球 + 可微光栅化替代 NeRF 的隐式 MLP。
| 技术名称 | 诞生时间 | 所属机构 | 关键特性 |
|---|---|---|---|
| NeRF | 2020 年 3 月 | 开启隐式神经辐射场时代,质量高但渲染极慢 | |
| 3DGS | 2023 年 8 月 | Inria | 转向显式高斯点云,实现实时渲染和超快训练 |
| DUSt3R | 2023 年 12 月 | NAVER LABS Europe | Transformer 架构,稠密无约束立体三维重建 |
| VGGT | 2025 年 3 月 | Meta (FAIR) | 3D 大模型,通过 Transformer 直接推理出几何属性 |
阶段 2(2024–2025):变体爆发与数学基础夯实
综述文献在这一阶段快速堆积,主要分支方向包括:2DGS(表面重建)、4DGS(动态)、Scaffold-GS(锚点+稀疏化)、Mip-Splatting(抗锯齿)、SuGaR/MILo(网格提取)、语义 3DGS、可重光照/逆渲染。
阶段 3(2025–2026):前馈化 + 标准化
(a)前馈式 3DGS 成为主战场。 传统 3DGS 依赖 COLMAP 做 SfM 求位姿,耗时长、低纹理场景易失败。前馈方法用单个网络一次前向直接回归高斯,抛弃逐场景优化:
| 工作 | 会议 | 要点 |
|---|---|---|
| AnchorSplat | CVPR 2026 | 锚点对齐高斯 + 3D 几何先验,摆脱像素对齐,高斯数量大幅减少 |
| SparseSplat | CVPR 2026 | 像素非对齐预测,面向实际可用性 |
| EcoSplat | CVPR 2026 | 效率可控的前馈 3DGS |
| Compact Proxy Anchors | CVPR 2026 | 基于 Scaffold-GS 的任意分辨率抗锯齿渲染 |
| AnySplat / VGGT-X / PF3plat / YoNoSplat / VolSplat | SIGGRAPH Asia 2025 / ICML 2025 | 无约束视角、无位姿前馈重建 |
| ATSplat | arXiv 2607.20417 | 自适应 Token,高斯数砍到 1/5,单图重建 <1s、渲染 1136 FPS |
(b)标准化落地——这是 2026 年最硬的信号。
- 2026 年 2 月 3 日,Khronos 发布
KHR_gaussian_splattingglTF 扩展 Release Candidate,预计 2026 Q2 完成批准。同时采纳 Niantic 开源的 SPZ 作为压缩扩展(KHR_gaussian_splatting_compression_spz),压缩率约 90%(250MB PLY → ~25MB)。 - OpenUSD 26.03(2026 年 3 月)新增原生 schema
UsdVolParticleField3DGaussianSplat,继承自Gprim——意味着高斯成为可分层、可引用、可做 variant 的 USD 一等图元。 - Nuke 17(2026 年 2 月) 首个原生支持高斯泼溅的合成软件;Houdini 21 提供 Karma XPU 技术预览;V-Ray 7 是最早的商用光线追踪支持者。
⚠️ Khronos + OpenUSD 双标准同时接纳,是判断”技术是否真的成为基础设施”最可靠的分水岭。3DGS 已经跨过了这条线。
5.3 当前最热的研究方向
- 动态场景(4D 高斯):将时间维度引入,处理运动物体和非刚体变形
- 在线重建与 SLAM 融合:实时相机跟踪、地图更新与渲染的闭环
- 场景编辑与可控生成:文本指令或交互式编辑材质、结构、增删物体
- 可重光照与逆渲染:把”烘焙”在颜色里的光照分离出来,独立估计材质和光照
- 模型压缩与流式传输:剪枝、量化、LOD,让模型能在移动设备或网络环境中高效使用
- 语义理解:给高斯附加语义信息,支持分割、编辑、查询
光照解耦是 2025–2026 最热的攻坚方向,近期工作:
- GeoSplatting(ICCV 2025):用显式几何引导修正法线估计,改善材质-光照分解
- LightBridge(arXiv 2609.02543):前馈生成式重打光,单次前向完成,无需逐场景再优化
- F-RNG / InvSplat:前馈生成可重光照 3DGS,每个高斯基元参数化 albedo/metallic/roughness
5.4 反向趋势:前馈 3D 基础模型
VGGT、MapAnything、Depth Anything 3 等用 Transformer 直接推理几何。行业判断是 2026 年将并行两条路线:① 算法建图 + 高质量 3D/4D GS;② 前馈网络提供最快最便宜的 GS 构建。但前馈路线目前仍在模型规模不足时丢失几何精度,位姿估计偏差会直接导致高斯图损坏。
⚠️ 前馈模型不是 3DGS 的替代者,而是把 3DGS 的上游(SfM/位姿)吃掉了。3DGS 作为”可光栅化的输出表示”这个定位反而被强化了——这也是 Khronos 把它写进 glTF 的底层逻辑。
六、UE 集成:为什么没有第一方模块
6.1 引擎侧现状
多方来源一致确认:UE 5.7 与 UE 5.8 都没有 Epic 官方的 Gaussian Splatting 模块,进入引擎的路径全部是第三方插件。5.8 的官方特性列表(MegaLights 转正、Composure 深度工作流、Tiled Mipmap Video 等)中也没有高斯泼溅相关内容。
⚠️ 这一缺席有其合理性——3DGS 的高斯基元与 UE 现有的 RDG / Nanite / Lumen 管线在心智模型上差异过大(无几何、无材质、无 UV、烘焙光照),要做成第一方模块需要重构光照与阴影交互。第三方的”插件生态代替官方模块”状态,至少还会持续一个引擎大版本。
6.2 插件生态
| 插件 | 关键能力 | 链接 |
|---|---|---|
| LCC-3DGS-Unreal-Plugin(XGRIDS) | 功能最全面:十亿点级大规模场景、流式 LOD、重打光、原生深度缓冲(真电影级 DOF)、nDisplay 虚拟制作、VR、自动碰撞生成;支持 LCC/LCC2/PLY/SOG/SPZ;UE 5.1–5.8;DX11/12/Vulkan。有免费 + Pro 版 | GitHub |
| NanoGaussianSplatting(NanoGS) | 免费、安装简单。采用 Nanite 式 LOD Cluster + 屏幕空间误差 LOD 选择 + Splat 压缩 + 全局累加器 + GPU Radix Sort;UE 5.6/5.7 | GitHub |
| MLSLabsRenderer | 3DGS + 4DGS 体积视频、Sequencer 驱动、非 Niagara 的自研渲染管线。Pro 版宣称 500 万+ 高斯静态场景 60 FPS+、4DGS 120 FPS+(RTX 4070 Ti 实测) | GitHub · Epic 论坛帖 |
| SplatRenderer | 3DGS + 4DGS(.gsd)、Sequencer 关键帧、3D 裁剪框、音频同步;UE 5.5+ | GitHub |
| YaGS(Yandex,Film XR 预编译版) | 把 3DGS 对象直接放进关卡与多边形物体并存;UE 5.5–5.7 | GitHub |
| UEGaussianSplatting | 八叉树优化、动态 LOD、自动碰撞生成、自研组件绕开 Niagara 粒子数上限 | GitHub |
| XScene-UEPlugin(XVERSE) | 早期较流行,基于 Niagara,支持混合渲染和基础编辑 | — |
| Luma AI 官方 UE 插件 | 免费、文档完整,与 Luma 采集栈打通。受 Niagara 200 万粒子数限制 | StraySpark 评述 |
| unreal-splat | 用 Niagara 渲染,上限约 200 万高斯;仅 UE 5.5,已停更 | GitHub |
| SplatBus(学术) | 把光栅器做成独立渲染服务器,通过 NVIDIA IPC API 与 UE/Unity/Blender 客户端通信,支持深度感知混合 | SplatBus 论文 |
6.3 根因:高斯不是几何,是一团”体积的云雾”
高斯基元没有面、没有深度、没有法线。它的成像方式是按深度排序后做 α 混合。
而 UE 的整个渲染架构建立在一条前提上:不透明几何写深度 → 延迟着色读深度。这条链上的每一环——Nanite 的 cluster 剔除、Lumen 的 surface cache、虚拟阴影图、TSR 的历史帧——都依赖”几何与视角无关,因此可以跨帧、跨视角缓存”。
而高斯的可见性和正确的混合顺序,每一帧、每个视角都要重算。
⚠️ 这就是”高斯难以变成 UE 里像 Nanite 那样的一等图元”的根本原因——不是实现难度,是表示形式与架构前提的冲突。成熟插件清一色走”自研管线 + 独立合成层”,正是在这个约束下的必然选择。
6.4 与网格正确合成需要多趟渲染
混合场景下前向混合需要多趟,因为网格的贡献依赖于”该像素上累积的 splat 透射率”,而这个值在画网格时还不知道:
| 趟次 | 做什么 |
|---|---|
| 1. Mesh depth pre-pass | 网格只写深度、不写颜色。让网格后面的 splat 被深度测试正确剔除 |
| 2. Splat FTB pass | splat 前向混合(under 混合算子),累积颜色与透射率 |
| 3. Mesh color pass | 网格重新画一次,这次带颜色,用累积的 splat alpha 做混合:C_final = C_mesh × (1 − α_dst) + C_splats |
| 4. Depth consolidation | 把挑出的 splat 深度写回硬件深度缓冲,让后处理和视觉辅助能拿到完整场景深度 |
这意味着要在 UE 的 base pass 前后插入自己的 pass,并接管深度缓冲的组织方式。 RDG 能表达这个,但不是”加个组件”的量级。
对照 Unity 的 URP 集成:splat 渲染插在 BeforeRenderingTransparents,依赖 activeDepthTexture 做遮挡测试,中间还要开一张 R16G16B16A16_SFloat 的中间纹理来保持 HDR 精度。并且明确不支持 MSAA——因为 3DGS 用自己的高斯核抗锯齿。
6.5 光照:彻底断裂
(a)splat 默认是自发光(emissive)的——辐射亮度是训练时”烤”进去的,不与场景光照交互:
“Splat sets are emissive by default — their radiance is baked in and does not interact with scene lighting. When a splat set is used as an environment around mesh geometry, the emissive contribution has no occlusion: meshes appear to float without contact darkening.”
(b)Lumen 不支持。 Epic 论坛上的插件作者说法很直接:
“Lumen is not supported. Shadow is not supported. Ray traced translucency is not supported.”
(c)splat 不投也不接收阴影,不出现在反射里。
“Splats do not currently cast or receive shadows and do not appear in reflections.”
现有变通方案:
- 代理网格(proxy mesh):PlayCanvas 明确文档化——splat 不能接收阴影,但可以用一个不可见的 mesh 近似 splat 形状、写深度、接收阴影,即 “shadow catcher”
- NVIDIA 的 Particle emissive AO:从 splat 表面打一条 cosine-weighted 半球光线,只对 mesh 求交,命中就按距离衰减自发光——用来缓解”网格浮在场景上”的观感。不做 splat-to-splat 遮挡
- LCC 插件:用 proxy mesh 做重光照
- Union VFX 的真重光照方案(影视侧):明确批评了现有做法——“relighting baked in at training time or render-time relighting, resulting in the introduction of artefacts”,他们的做法是让 splat 像传统 CG 资产一样被标准灯光打光
6.6 后处理的”颜色战争”
Epic 开发者论坛上有一位实践者把这个问题总结得非常准:
“3DGS colors often get distorted by UE5’s default post-processing. If you disable post-processing to fix the color, you lose the ability to blend the Gaussians with your standard Mesh/Lighting scene.”
⚠️ 这本质是色彩管理管线不匹配。3DGS 的颜色是”训练照片的颜色”(通常已经过某种隐式色调映射、display-referred),而 UE 全程 linear working space + 自己的色调映射器。没有任何信息能把这个变换逆回去——因为高斯里存的是最终像素值,不是辐射度。
6.7 Niagara 路线的性能天花板
| 事实 | 来源 |
|---|---|
| Niagara 超过 10 万–50 万高斯就吃力 | Epic 论坛 |
| Niagara 的排序不是为 3DGS 设计的 → popping、严重 overdraw、颜色失真(过曝) | Epic 论坛 |
| LumaAI 插件受 Niagara 200 万粒子数限制 | ICT USC |
| MLSLabs 明确采用”非 Niagara 的自研渲染引擎” | GitHub README |
unreal-splat 用 Niagara,上限约 200 万,仅 UE 5.5 且已停更 | GitHub |
Niagara 的排序是为粒子特效设计的,不是为逐像素正确的前后顺序设计;而 3DGS 的成像正确性完全依赖这个顺序。
6.8 若干个真实的坑
来自插件 changelog 的实际记录:
- “Fixed blending artifacts caused by depth buffer resolution mismatch between Editor and Play modes.”
- “Fixed Repeatedly dragging to update the Gaussian Actor’s transform causes the engine to crash.”
- “Resolved the ‘access denied’ error when deleting libraries (e.g.
cublas64_12.dll) during the packaging process.”
⚠️ 第一条特别值得注意——UE 编辑器和 PIE 的深度缓冲分辨率/格式并不总是一致,而高斯混合的正确性直接依赖深度比较。这类”编辑器里看着对、打包后不对”的问题,是高斯集成里最容易消耗工时的部分。
七、UE 里的实际可用边界
7.1 能做的
- 整体变换(移动 / 旋转 / 缩放)
- 体积裁剪(Box / Sphere 等删除不需要的部分)
- 亮度、缩放、颜色校正
- 与普通网格混合放置和渲染
- Sequencer 驱动 4DGS 播放、关键帧控制亮度 / 缩放 / 裁剪 / 播放速度
- 自动生成碰撞体(LCC、UEGaussianSplatting 支持)
- 部分插件支持重打光(用代理网格模拟灯光/阴影)
- 导出到外部工具(如浏览器端 SuperSplat)精细修剪,再导回 UE
- VR、nDisplay 虚拟制作已有成熟支持
7.2 不能做的(硬限制)
| 需求 | 状态 | 证据 |
|---|---|---|
| 参与物理引擎(刚体、动力学) | ❌ | Isaac Sim 实测:“they cannot interact with physics engines… would require supplemental geometry such as bounding boxes or proxy meshes” |
| 被射线检测命中 | ❌ | 同上 |
| 被 LIDAR / 深度传感器看到 | ❌ | Isaac Sim 实测:“splats are not detected by LIDAR sensors, meaning they do not appear in depth scans or point clouds” |
| 投射 / 接收阴影 | ❌(原生) | PlayCanvas / NVIDIA / Evercoast 三方一致 |
| 出现在反射里 | ❌ | Evercoast 实测 |
| 编辑拓扑 / UV / 骨骼动画 | ❌ | 表示形式不支持 |
| 与半透明物体正确混合 | ❌ | “splats overlap or intersect with translucent materials → hard edges and incorrect occlusion… billboard-style rendering” |
⚠️ “对 LIDAR 不可见”这一条被严重低估了。 它意味着在仿真、自动驾驶、机器人场景里,splat 重建的环境对传感器是”透明”的——这直接切断了”用 3DGS 做仿真环境”这条路,除非额外生成几何。
大场景对显存和 GPU 要求较高(推荐 RTX 30/40 系列及以上),部分插件对 UE 版本有对应要求,需匹配下载。
7.3 实际能用到什么程度
| 用法 | 可行性 | 说明 |
|---|---|---|
| 远景背景板 / skybox | ✅ 成熟 | 反正够远,LOD 和剔除都友好 |
| 虚拟制片 LED 墙背景 | ✅ 已有生产案例 | SIGGRAPH 2026 学生项目用 XGrids 插件;TBS 剧集用 Preferred Networks 的私有插件 |
| 建筑可视化 / 房产漫游 | ✅ 成熟 | 目前产业化最扎实的场景 |
| 实景拍摄素材 / 参考底景 | ✅ 成熟 | 成本优势明显 |
| 与网格深度交错的混合场景 | 🟡 可做但需自研管线 | 3–4 趟渲染 + 深度接管 |
| 可碰撞的游戏场景 | 🟡 需要额外生成 collider | 碰撞能做,光照仍断裂 |
| 主角 / 可玩资产 | ❌ | 静态、无动画、无 AOV |
| 替换 CG 环境 | ❌ | 不可重打光、不可美术指导 |
业界共识的表述(两位独立从业者的说法几乎一致):
“Splats are read-only — you cannot easily place a chair on a splat floor and have it occlude or shadow correctly. So they live behind the action, not within it.”
“Comparison table: Replacing CG environment builds → No (can’t relight, can’t art-direct). Hero character work → No (static, no animation, no AOVs).“
7.4 推荐工作流
常见流程:外部训练/清理 → 导入 UE → 用插件做场景级调整 + 代理碰撞 → 混合传统资产。
具体到 UE 里:
- 直接导入 3DGS 用插件渲染(保持最高画质)
- 额外生成一个低精度/中精度的代理 Mesh 只负责碰撞和物理
- 如果真的需要完整 Mesh 资产,再导出做二次优化(简化拓扑、UV、贴图烘焙)
起步建议:先试 NanoGS(免费简单)或 LCC 插件(功能全)。安装后直接拖 .ply 进关卡就能看到效果。
⚠️ 在 UE 里,splat 目前是一个”只读的舞台背景”,不是”场景的一部分”。 渲染它很容易(插件已经做到十亿级 60–120 FPS),难的是让它和几何、光照、物理、后处理讲同一种语言——而这四件事目前都还没有通用解。
如果目标是把实景扫描当作远景底景,现在就能用;如果目标是让角色走进这个场景并正确接收光照和碰撞,需要做好自研管线的准备,且光照断裂这一条在 UE 侧没有干净的绕法。
八、为什么不建议直接转成 Static Mesh
把 3DGS 导入后直接转成 Static Mesh,不是”不能做”,而是会明显损失它最核心的优势。 主要原因是精度(尤其是视觉精度)大幅下降,而不是渲染变慢。
8.1 视觉精度会严重下降
3DGS 的”神奇”之处在于它用数百万个半透明、可重叠、可变形的软椭球来表示场景:
- 能完美捕捉视角相关效果(反光、高光随角度变化、半透明、毛发、树叶、烟雾等)
- 边缘是软的、渐变的,重叠后自然融合,看起来像真实照片
- 不需要严格定义”表面”,所以对复杂光学效果特别友好
转成 Static Mesh 后:
- 必须强制抽出一个硬表面(通常用 Marching Cubes、Poisson 重建或类似方法从高斯密度场提取)
- 细小结构(自行车辐条、树叶、毛发、线缆)经常丢失或变成粗块
- 反光、透明、半透明效果几乎全部丢失或只能靠后期贴图硬凑(而且贴图是固定视角的,换角度看就不对了)
- 表面会变得过于平滑或出现噪点、破洞、拓扑错误
- 即使是目前最好的提取方法(SuGaR、2DGS、MeshGS 等),渲染质量(PSNR/SSIM)通常比原 3DGS 低 1–3 dB,视觉上差距明显
3DGS 是”体积 + 外观”的表示,Mesh 是”表面几何”的表示。转换过程会把最值钱的外观信息丢掉。
8.2 渲染速度不一定变快
- 原 3DGS 在专用插件下已经能实时(百万级高斯轻松 60–100+ FPS)
- 转成 Mesh 后如果想保留接近的细节,网格会非常密(几百万到上千万三角形),普通 Static Mesh 渲染反而可能更重;用 Nanite 可以缓解,但纹理烘焙、LOD 管理又增加额外成本
- 而且 Mesh 无法原生保留视角相关着色,想模拟反光还得加复杂材质或额外光照计算
8.3 什么时候值得转
| 场景 | 建议 |
|---|---|
| 需要物理交互、碰撞、导航 | 提取一个简化的代理网格专用于碰撞,视觉仍用原 3DGS 渲染(很多 UE 插件就是这么干的) |
| 需要骨骼动画、变形、精细编辑、3D 打印、CAD | 必须转 Mesh |
| 游戏核心可玩资产、需要标准材质管线 | 转 Mesh 更合适 |
| 纯背景、可视化、虚拟制作、数字孪生看图 | 保留 3DGS,画质完胜 |
一句话:不转 Mesh 是为了保住 3DGS 最强的照片级真实感和视角相关效果;转了就会变成”普通扫描模型”,优势大减。精度损失主要体现在视觉真实感上,而不是几何测量精度——几何精度本来就不是 3DGS 的强项。
九、尚未解决的问题
- 内存 / 显存消耗大,城市级场景对硬件要求高
- 对输入数据质量极敏感:覆盖不足或模糊直接导致重建失败
- 动态物体、透明与反光表面仍然困难
- 浮点噪音(floaters)、高斯膨胀(popping)、针状畸变等特有伪影,PSNR/SSIM 这类传统 IQA 指标对其几何失真不敏感
- 光照烘焙:无法重打光,这是影视与游戏落地的最大障碍
- 无几何:不构成水密表面,物理、碰撞、传感器仿真都要额外补几何
附录 A:完整演进链路
问题:从照片重建可任意视角观看的场景
│
├── 路线A 显式几何(网格)──── 快,但表达不了复杂光照/视角相关效果
│
└── 路线B 隐式神经场(NeRF)─ 照片级质量,但:
① 每像素沿光线采样数百次 MLP → 0.06 FPS
② 梯度穿过整个网络反传 → 训练 48 小时
③ 场景藏在权重里 → 完全不可编辑
④ 绕开光栅化硬件 → GPU 白给
中间态尝试(Instant-NGP / Plenoxels):
把网络换成哈希网格 → 训练快到分钟级 ✅
但仍然"沿光线积分" → 渲染卡在 10-15 FPS ❌
────────────────────────────────────────
结论:不放弃 ray marching,就没有出路
3DGS 的破题(2023):
表示:把"隐式函数"换成"1-5M 个显式各向异性高斯"
└─ 关键性质:3D 高斯投影到 2D 仍是高斯,且有闭式解
优化:自适应密度控制 —— 用视图空间位置梯度决定克隆/分裂/剪枝
渲染:tile-based 可微光栅器(16×16 tile + 基数排序 + α 混合)
└─ 原论文原话:"我们方法效率的关键"
颜色:球谐函数承载视角相关性
初始化:SfM 稀疏点云(★ 这也是它唯一的软肋)
账单:
渲染 0.06 FPS → 134 FPS ✅ 2200×
训练 48 小时 → 41 分钟 ✅ 70×
质量 基本持平甚至更好 ✅
存储 8.6 MB → 734 MB ❌ 85×
────────────────────────────────────
本质:把"计算时付出"换成了"存储时付出"
余波(2023 → 2026):
因为"显式",所以可改/可标/可压/可切/可拼/可喂/可反解
→ 长出了整个 3DGS 研究领域,并被 Khronos + OpenUSD 接纳为标准
→ 下一个要杀的目标:SfM 前置依赖(前馈化)与烘焙光照(可重光照)附录 B:核心概念速查
| 缩写 | 英文全称 | 中文 | 说明 |
|---|---|---|---|
| 3DGS | 3D Gaussian Splatting | 三维高斯泼溅 | 用显式高斯椭球做实时辐射场渲染 |
| NeRF | Neural Radiance Fields | 神经辐射场 | 用神经网络隐式编码场景 |
| NVS | Novel View Synthesis | 新视角合成 | 从已知视角生成新视角图像 |
| SfM | Structure-from-Motion | 运动恢复结构 | 从多视角图像估计相机位姿与稀疏点云,如 COLMAP |
| SH | Spherical Harmonics | 球谐函数 | 编码视角相关颜色 |
| EWA | Elliptical Weighted Average | 椭圆加权平均 | 3DGS 投影数学的来源(Zwicker 2001/2002) |
| FTB | Front-to-Back | 前向混合 | 高斯按深度从前往后做 α 混合 |
| LOD | Level of Detail | 细节层级 | 大场景流式加载的基础 |
| SPZ | — | Niantic 开源压缩格式 | 约 10× 压缩,已被 Khronos 采纳为 glTF 扩展 |
| SOG | — | PlayCanvas 压缩格式 | 约 15–20× 压缩,面向 Web 分发 |
| AOV | Arbitrary Output Variables | 任意输出变量 | 影视合成所需的深度/ID/运动模糊等通道 |
参考链接
原论文与数学基础
🔗 3DGS 原论文 — 3D Gaussian Splatting for Real-Time Radiance Field Rendering(ar5iv 全文)
🔗 3DGS 原论文 PDF(INRIA 官方)
🔗 INRIA 官方项目页
🔗 Surface Splatting (SIGGRAPH 2001)
🔗 EWA Splatting (MERL TR2002-49)
🔗 Object Space EWA Surface Splatting (CGF 2002)
🔗 Projecting Gaussian Ellipsoids While Avoiding Affine Projection Approximation(arXiv 2411.07579)
🔗 SG-Splatting 论文(含参数化公式)
教程与可视化
🔗 Rendering in 3D Gaussian Splatting(Scthe’s blog,含完整推导与代码)
🔗 How to Render a Single Gaussian Splat?(Shi Yan)
🔗 SuperSplat 在线编辑器
🔗 LearnOpenCV: 3D Gaussian Splatting Paper Explained
🔗 Hugging Face 入门文章(含单个/多个高斯示意)
🔗 交互式可视化页面
🔗 A Comprehensive Study for Gaussian Splatting(Tarek Bouamer)
🔗 Gaussian Splats Explained(Splat Labs)
🔗 Gaussian Splats 底层原理(wallabyway)
🔗 Arnold for Maya — Gaussian Splat 形状文档
🔗 3DGRUT 实测教程(视频)
综述与统计
🔗 A Survey on 3D Gaussian Splatting(ACM CSUR)
🔗 3DGS: Survey, Technologies, Challenges, and Opportunities(arXiv 2407.17418)
🔗 Recent advances in 3DGS(Computational Visual Media, 2024)
🔗 Semantic 3DGS: A State-of-the-Art Review(MDPI, 2026)
🔗 Human reconstruction using 3DGS: a brief survey(Frontiers in AI)
🔗 RadianceFields 统计页
🔗 Awesome3DGS/3D-Gaussian-Splatting-Papers
🔗 Sparse-View 3D Reconstruction: Recent Advances and Open Challenges(arXiv 2507.16406)
🔗 RayGaussX 论文(对 3DGS 固有限制的论述)
评测榜单
🔗 SOTA2: Mip-NeRF 360 (test) 榜单
🔗 NerfBaselines: Gaussian Splatting
🔗 NerfBaselines: Mip-NeRF 360
标准化与格式
🔗 Khronos 官方新闻稿 — glTF Gaussian Splatting
🔗 Cesium: 3D Gaussian Splats LOD
🔗 PlayCanvas 格式对比文档
🔗 PlayCanvas Shadows 文档(proxy mesh 方案)
UE 集成
🔗 StraySpark: UE5 采集到游戏管线 2026
🔗 Gaussian Splatting options(Epic 开发者社区论坛)
🔗 LCC-3DGS-Unreal-Plugin(XGRIDS)
🔗 NanoGaussianSplatting
🔗 MLSLabsRenderer
🔗 SplatRenderer
🔗 YaGS(Film XR)
🔗 unreal-splat
🔗 SplatBus 论文
🔗 UnityGaussianSplatting 的 URP 集成细节
🔗 Open3D 的 3DGS 渲染设计
🔗 NVIDIA Vulkan Gaussian Splatting — Lighting and Shadows 深潜
🔗 ICT USC: Large-Scale 3DGS
🔗 Integrating 4D Gaussian Splats into Omniverse and Isaac Sim(Evercoast)
🔗 Epic 官方 UE 5.7 发布说明
🔗 CG Channel: UE 5.8 五大特性
影视与产业化
🔗 Framestore 4DGS 管线报道(《超人》)
🔗 Computer Graphics World: Union VFX 人群重光照
🔗 cglounge: Gaussian Splatting for VFX — 诚实指南
🔗 aukimi: Gaussian Splatting in Production 2026
🔗 SIGGRAPH Blog: Gaussian Splatting in Virtual Production
🔗 RadianceFields: Preferred Networks × TBS《GIFT》
🔗 RadianceFields: 3DGS 年终总结
🔗 Apple SHARP 实测(LAVFX)