高斯飞溅3DGS原理与实操：从照片到实时三维场景重建-平芜编程栈

最近一段时间，三维重建领域最热的关键词，已经从“NeRF”悄悄换成了“高斯飞溅”。如果你关注过 CV 顶会论文或者三维视觉相关的开源仓库，大概率已经见过这个名字，也知道它的全称叫 3D Gaussian Splatting，通常缩写为 3DGS。但真正值得开发者关心的，可能并不是“它比 NeRF 快了多少”这个表面结论，而是它背后那套完全不同的场景表达方式：把连续场景拆成上百万个可微分的三维高斯椭球，再通过光栅化渲染到屏幕。这种“用粒子表达连续世界”的思路，既绕开了神经辐射场的体渲染计算瓶颈，又保持了照片级的渲染质量，才是它能在短短一年多时间里快速落地的真正原因。

这篇文章会从实际工程出发，先把高斯飞溅解决的核心问题讲清楚，再拆解它的原理和训练流程，最后给出一套可以在本地跑通的完整操作路径。无论你是刚接触三维视觉的开发者，还是正在做数字孪生、自动驾驶仿真、VR 展示项目的工程师，都可以照着本文的步骤和实践建议做一次完整的场景重建实验。

1. 这篇文章真正要解决的问题

在正式介绍高斯飞溅之前，先想一个问题：如果你手里有一组从不同角度拍摄的照片，比如几十张手机拍摄的室内场景照片，你希望把它们变成“可以自由旋转、缩放、从任意视角观看”的三维模型，过去你会怎么做？

传统做法是走摄影测量流程。先把照片输入到类似 COLMAP 的工具里做特征提取和稀疏重建，得到相机位姿和稀疏点云，再用 MVS（多视角立体匹配）生成密集点云，最后经过网格重建、纹理映射，才能得到一个可以导入游戏引擎或三维软件使用的模型。这条路线的缺点是明显的：中间环节多、参数敏感、计算时间以小时计，而且植被、玻璃、反光表面这类场景经常重建失败。换句话说，传统流程擅长处理“建筑级”的刚性场景，但不擅长处理“复杂材质、细节丰富”的真实环境。

后来有了 NeRF。NeRF 通过一个多层感知机网络，把场景编码成连续的颜色场和密度场，渲染时从相机发射射线，沿着射线采样一堆空间点，逐一查询网络输出，再做累加合成。这个方案在重建质量和细节还原上比传统 MVS 强很多，尤其是对复杂反射和半透明表面的表现力，几乎碾压传统方法。但它的代价也很大：训练慢，单个场景往往要训练数小时甚至更久；渲染慢，因为每个像素都要走大量神经网络前向推理；同时场景是隐式表达，很难直接编辑、切割或做二次处理。

高斯飞溅的出现，正好同时解决这两个问题。从方法归属上说，它属于显式场景表达，每个三维高斯都有明确的中心位置、协方差矩阵、颜色和不透明度，像一堆“模糊的小点”悬浮在空间中。训练时，我们用图像梯度对这些点做位置、形状、颜色和透明度的迭代优化，使最终渲染结果逼近真实照片；渲染时，经过排序和光栅化直接画出这些椭球体，不再需要神经网络推理，也不再需要沿射线逐点采样。

所以，如果你正在做以下事情，高斯飞溅值得你重点关注：

需要用有限数量的照片，快速生成高质量的三维场景；
需要渲染速度足够快，甚至达到实时帧率；
需要场景可编辑、可定位、可嵌入现有三维引擎；
需要一种比 NeRF 更容易工程化的三维重建方案。

一句话概括：高斯飞溅真正降低的，是“从一组照片到可交互三维场景”的工程成本。它把三维重建从“小时级加服务器级”往“分钟级加单卡可跑”推进了一大步。本文会按“原理—环境—实操—排错—工程建议”的顺序，把它讲透。

2. 三维重建技术演进与高斯飞溅的定位

要理解高斯飞溅，最好先把它放进三维重建的技术脉络里。下表对比了传统重建、NeRF 和高斯飞溅三种路线在关键维度上的差异：

技术路线	场景表达方式	训练速度	渲染速度	可编辑性	硬件门槛	适用场景
传统摄影测量（MVS）	点云 / 网格 / 纹理	中等	快	一般	低	测绘、建筑、静态物体
NeRF	神经网络隐式场	慢	慢	差	较高	科研、离线高质量渲染
3D Gaussian Splatting	显式三维高斯集合	快	实时	好	中等	交互应用、实时渲染、AR/VR

从这个对比可以看出，高斯飞溅并不是凭空冒出来的，它是三维重建“显式 vs 隐式”反复拉锯之后，找到的一个新平衡点。

前面的章节提到，NeRF 的优点是渲染质量高，但它是隐式表达，这意味着场景信息被编码在神经网络权重里，看不到、摸不着、剪不开。如果你想在重建结果里做“删除某个物体”“平移某个区域”这样的操作，是极其痛苦的。高斯飞溅则完全不一样：场景中的每个三维高斯都是一个可独立操作的对象，你可以按空间位置做裁剪，也可以改变某一组高斯的属性，甚至把多个场景的高斯合并到一起。这种显式特性，让它在工程落地上拥有天然优势。

再往深处看，3D Gaussian Splatting 的定位本质上是一个“可微光栅化器”。论文作者把场景建模成上百万个三维高斯分布，训练的第一步是用 SfM（运动恢复结构）点云做初始化，第二步是迭代优化每个高斯的参数，第三步是自适应地对高斯进行分裂、克隆和剪枝。渲染时，所有高斯先按深度排序，再投影到二维平面上，与图像像素做 alpha blending 合成。整个过程完全可微，因此可以用 SGD 或 Adam 来逐步优化参数。

对开发者来说，这里真正值得注意的点是：高斯飞溅虽然看起来像“点云渲染”，但它和普通点云有本质区别。普通点云是离散的，从一个角度看不到的点，换一个角度依然看不到；但高斯飞溅的每个元素是一个连续的“软椭球”，覆盖一个局部区域，通过透明度混合能够表达连续表面，同时保留一定的非刚性表达能力。这也是为什么高斯飞溅在渲染效果上远远好过传统的“点云上色”，但在效率上又远快于 NeRF 的原因。

3. 高斯飞溅的核心原理拆解

这一节会把 3D Gaussian Splatting 论文中的核心设计拆成几个部分来理解。不追求把所有数学公式都推一遍，而是重点说明“每一层设计解决什么问题”，方便后续实操时定位问题。

3.1 三维高斯：场景的最小单元

高斯飞溅用“三维高斯分布”作为场景的基本表示。一个三维高斯，可以理解为一个在空间中中心密度最高、向四周逐渐衰减的椭球体。它的数学参数包括：

中心位置：高斯球在三维空间中的坐标；
协方差矩阵：决定椭球的形状、大小和朝向；
颜色：通常用球谐函数系数表示，以便从不同视角观察时颜色连续变化，而不会出现生硬高光；
不透明度：控制这个高斯对最终色彩合成的影响权重。

场景初始化时，通常使用 COLMAP 生成的稀疏点云作为每个高斯的中心。后续的训练过程，就是不断调整这些参数，使渲染结果和真实拍摄图像之间的误差逐渐变小。

3.2 可微光栅化：渲染不再依赖射线追踪

NeRF 渲染时要沿视线方向采样很多点，计算量非常大。高斯飞溅则用了类似传统图形管线中的光栅化思路：先把每个三维高斯投影到图像平面上，变成一个二维高斯形状，然后对所有投影到同一像素区域的高斯，按照深度由近到远排序，从前往后做 alpha 合成。

这里的关键操作是“对高斯做分块剪裁”，论文中称之为 tile-based rasterization。GPU 渲染时，把图像分成许多小块（tile），每个小块对应一个线程块，共享同一组高斯数据，减少重复排序开销。这个设计让渲染速度大幅提升，使得在训练完成后，场景可以在普通消费级显卡上以实时帧率渲染。

从开发者角度看，这一阶段最容易混淆的概念是：高斯飞溅并没有真正“画”出一个高斯的闭合表面，每个高斯只是对场景局部颜色和密度的软性拟合。因此，渲染结果看起来会有“软糖质感”，尤其是边框、边缘、细小结构等区域，可能出现模糊或飞溅状伪影。这也是很多人在初学时误以为“高斯飞溅效果不如 NeRF 精细”的原因——从某些静态对比图来看确实如此，但在动态旋转、缩放和实时交互场景中，高斯飞溅的总体体验要强很多。

3.3 自适应控制：决定场景密度的关键机制

训练一个高斯飞溅场景，并不是简单地学固定数量的三维高斯，而是在训练过程中动态调整高斯数量。这一步叫自适应密度控制，大概逻辑是：

当一个高斯覆盖的区域在多个视角下出现了明显的几何缺失或颜色错误时，就把这个高斯分裂成两个，或者在其附近克隆一个新高斯；
当一个高斯的不透明度很低、对最终图像几乎无贡献时，就把它删除，降低计算量；
当一个高斯变得特别大、把远处区域的细节抹平时，也把它拆分或缩小。

正是因为有了这一步，高斯飞溅才能从初始稀疏点云出发，逐步生长出覆盖整个场景细节的高密度点集。实际重建一个室内场景，最终高斯数量通常在几十万到数百万之间。

3.4 损失函数与优化

训练损失主要由两部分构成：L1 颜色损失和 SSIM 结构相似性损失。前者保证逐像素颜色逼近，后者保证局部结构清晰。两个损失的加权组合，是训练过程中唯一直接监督信号。这种简洁的设计，让 3D Gaussian Splatting 可以被快速工程化——数据准备完成后，只需要一个 PyTorch 训练脚本就能完成全部优化。

从实际工程角度，如果想深入优化一个场景，通常可以调整的是损失权重、学习率、迭代次数、初始点云密度等。但首次上手时，建议先用默认参数跑通全流程，再去动这些超参数。

4. 环境准备与前置条件

开始实操之前，先确认硬件和软件环境。下面的说明以通用实践为准，具体版本请以你下载的仓库当前状态为准，不要机械照搬旧教程。

4.1 硬件要求

GPU：建议 NVIDIA 显卡，显存 8GB 以上。训练一个普通室内场景，8GB 显存属于“能跑但偏紧”；如果想重建大场景或高分辨率图像，建议 12GB 以上。
内存：16GB 起步，建议 32GB。加载多张高清图像和中间缓存时，内存占用会比较明显。
磁盘：预留 20GB 以上空间，用来存放原始图像、中间特征、点云模型和训练结果。

4.2 软件依赖

主要依赖包括：

Ubuntu 20.04 或 22.04（Windows 也可以跑，但编译环境会多踩一些坑）；
CUDA 11.8 或更高版本，版本请以显卡驱动和 PyTorch 的匹配关系为准；
Python 3.8 或更高版本；
PyTorch 1.13 或更高版本，需与 CUDA 版本匹配；
COLMAP，用于从图像生成稀疏点云和相机参数；
三个子模块：diff-gaussian-rasterization、simple-knn、submodules/diff-gaussian-rasterization。

一个常见误区是：很多人以为高斯飞溅是一种“开箱即用”的工具，下载仓库后直接跑即可。实际上，它需要编译包含 CUDA 代码的光栅化器子模块，编译过程会遇到很多环境问题，这是新手最容易卡住的地方。

4.3 准备原始数据

数据来源有两种。第一种是自己拍摄图像，建议使用手机或相机绕着目标匀速拍摄 50 到 300 张照片，注意相邻照片之间保持足够的重叠度，目标物体尽量覆盖画面中心；另一种是使用公开数据集，比如 Mip-NeRF 360、Tanks and Temples 等。无论哪种，建议把图像统一放到一个文件夹下，例如data/input。

拍摄时需要注意：

避免过度运动模糊，快门速度尽量快；
避免重复拍摄同一角度的照片，要让相机位置沿轨迹变化；
场景光照尽量稳定，不要拍一会儿开灯一会儿关灯；
对反光强烈、透明玻璃占比很大的场景，高斯飞溅重建难度高，需要额外处理。

5. 从照片到场景：完整实操流程

下面以gaussian-splatting官方仓库为例，演示从原始图片到可交互三维场景的标准流程。操作中需要执行的具体命令以你实际 clone 的仓库 README 为准，这里展示的是通用思路。

5.1 克隆仓库与安装依赖

git clone --recursive https://github.com/graphdeco-inria/gaussian-splatting.git cd gaussian-splatting # 创建虚拟环境 conda env create --file environment.yml conda activate gaussian_splatting

这里使用--recursive参数，是因为仓库包含子模块，而子模块包含了关键的 CUDA 光栅化实现。如果没有加这个参数，后面编译时会提示找不到子模块目录。

5.2 准备数据目录

官方仓库约定，数据目录按照data/<scene_name>/来组织，其下有input文件夹存放原图，images文件夹存放经过 COLMAP 处理后的图像。为了省省磁盘和加快处理，通常先用image_resize.py把图像缩放到合适分辨率。

python convert.py -s data/room

convert.py会自动完成以下操作：

读取data/room/input下的原始图像；
使用 COLMAP 提取特征，做特征匹配，输出相机位姿和稀疏点云；
将图像缩放并写入data/room/images；
生成训练需要的sparse/0目录，内含cameras.bin、images.bin、points3D.bin。

只要这个命令成功完成，后续训练就只是让 GPU 去“学习”这些数据。如果这里失败，后面的训练不可能成功。

5.3 开始训练

训练命令相对简单：

python train.py -s data/room -m output/room

其中-s指定数据目录，-m指定输出目录。命令执行后，程序会经过以下阶段：

读取相机参数和稀疏点云；
初始化三维高斯；
在训练循环中，每迭代若干次就对渲染图像和原图计算 L1 与 SSIM 损失，并反向传播更新所有高斯参数；
定期执行自适应密度控制，新增或删除高斯；
保存检查点。

训练过程中，终端会输出每步的迭代次数和损失值。在 8GB 显存的 GPU 上，一个 100 张照片左右的场景，训练几万步通常需要 20 到 40 分钟。实际时间取决于图像分辨率、GPU 型号和迭代次数，不要拿论文里的“几分钟”作为硬性预期，那通常是在特定配置下的优化结果。

训练结束后，output/room目录下会生成多个文件，其中比较重要的是：

point_cloud/目录，保存每一次保存点云时的三维高斯参数；
cameras.json，相机参数描述；
cfg_args，训练配置信息。

5.4 渲染与导出

训练完成后，可以运行渲染脚本，以训练好的模型生成指定视角的图像：

python render.py -m output/room

该命令会遍历验证集视角，输出渲染图像到output/room/test目录。同时，你可以在根目录运行可视化脚本，启动一个实时的交互窗口，用鼠标拖拽旋转视角。

如果需要导出可供其他三维软件或引擎使用的网格，官方仓库还提供了简单工具，可以用 Marching Cubes 从点云和高斯中提取网格。不过要注意，3D Gaussian Splatting 的定位并不是传统三维网格重建，它导出的网格质量和网格化后的精细度，通常不如原生渲染效果好。如果你需要的是带贴图的三角网格，传统 MVS 流程可能仍然更合适。

5.5 一个最小示例：验证环境是否正常

在跑完整训练之前，建议先用官方仓库提供的示例场景验证环境。具体做法是下载一个已经处理好的公开场景数据，放到data/目录下，直接执行训练命令。这样可以把“环境问题”和“数据问题”分开排查。如果连现成数据都训练失败，那就先解决编译和依赖问题；如果现成数据训练成功而自己的数据失败，问题大概率出在拍摄质量和 COLMAP 处理上。

6. 训练效果与质量验证

训练完成后，怎么判断场景重建得好不好？不能只看训练损失，因为损失只反映了对训练视角的拟合程度，不代表其他新视角的效果。更可靠的做法是分几步验证。

6.1 观察新视角渲染

用官方可视化工具载入训练结果，从训练视角之外的任意角度观察场景。重点看以下区域：

边缘轮廓是否清晰，有没有大片模糊或重影；
细长结构，如电线、树枝、栏杆，是否发生断裂；
大面积光滑表面，如白墙、玻璃，有没有斑驳的伪影；
视角转动时，高光区域的颜色是否连续变化，还是突然闪烁。

如果发现新视角下很多区域是“雾状”的，往往说明训练轮数不足，或拍摄图像数量不够、视角覆盖不全。

6.2 量化指标对比

在评测脚本中，通常会使用 PSNR、SSIM、LPIPS 三个指标衡量渲染质量。PSNR 越高越好，SSIM 越接近 1 越好，LPIPS 越低越好。初次实验时，可以拿自己的结果和官方仓库 README 中的示例数据做对比，但不要期待完全一致，因为硬件、分辨率、迭代次数都会影响结果。

6.3 用测试视角做交叉验证

如果拍摄时能额外采集一部分“测试视角”照片，不参与训练，专门用来验证，就能更客观地评估泛化能力。把测试照片输入渲染脚本，计算渲染结果和真实照片之间的差异。这是判断“过拟合训练视角”的最直接方法。

6.4 注意分辨率对质量的影响

图像分辨率直接影响训练速度、显存占用和最终质量。分辨率过低，细节纹理丢失严重；分辨率过高，训练时间和显存开销成倍上升。常见做法是先缩放到 1600 像素左右，观察效果后再决定是否需要更高分辨率。如果你想做最终展示场景，可以先用低分辨率做快速实验，确定参数后再用高分辨率正式训练。

7. 常见问题与排查思路

从社区反馈和实际经验看，以下问题是上手高斯飞溅时最常见的几类。

问题现象	可能原因	排查方式	解决方案
编译 submodule 报错	克隆时没有加`--recursive`	检查子模块目录是否存在	在仓库目录执行`git submodule update --init --recursive`
CUDA 版本不匹配	PyTorch 与 CUDA 工具链冲突	执行`python -c "import torch; print(torch.__version__)"`	按 PyTorch 官方提示重装匹配版本的 CUDA 和 PyTorch
convert.py 找不到 COLMAP	COLMAP 未安装或未加入 PATH	终端执行`colmap -h`	安装 COLMAP 并确认可执行文件在 PATH
稀疏重建失败	图像质量差、纹理特征少	查看 COLMAP 输出日志	增加照片数量，避免纯色墙壁等弱纹理区域，调整特征提取参数
训练时显存不足	图像分辨率过高、高斯数量过多	查看`nvidia-smi`显存占用	降低图像分辨率，减少初始迭代次数，关闭其他占用显存的程序
新视角出现严重雾状伪影	训练不充分或相机位姿不准	查看损失曲线和相机轨迹	增加训练迭代，检查 COLMAP 重建的相机轨迹是否平滑
渲染帧率低	高斯数量太多、未分块优化	观察高斯数量	使用官方 render 脚本的 tile-based 路径，不自行实现 CPU 渲染
Windows 编译失败	依赖库路径和 CUDA 工具链配置不当	查看 CMake 编译日志	优先用 Linux 环境，或按官方 Windows 说明逐项配置
场景中玻璃和镜面效果差	3D GS 对纯镜面反射表达有限	观察是否与真实物理不符	减少镜面场景，或在拍摄时避免高光反射大面积入镜

这里面，最值得新手留意的是前三个环境类问题。很多人花大量时间调训练参数，结果发现卡在编译环节，白白消耗精力。建议按“子模块 → CUDA 匹配 → COLMAP 可用 → 现成数据训练通过 → 自有数据训练”的顺序逐层推进。

7.1 训练过程中怎么判断是否正常

从终端输出中可以看到损失值和当前迭代步数。正常情况下，损失应当整体下降，中间有些抖动很正常。如果损失长时间不降，或者反而上升，可能是学习率设置不合适，也可能数据中的相机位姿有严重错误。此时不建议盲目加迭代次数，而应该回头检查 COLMAP 输出的相机轨迹和稀疏点云数量。

7.2 输出结果中有大量飞溅伪影

“飞溅”这个词本身描述了渲染时高斯被投影到画面上留下的痕迹。如果看到渲染图上出现很多细长的小块，通常是某些高斯在空间中被拉成了异常细长的形状。一种处理方式是在训练后修剪掉体积过小或透明度过高的高斯，另一种方式是在训练中调整正则化相关参数，让高斯形状更均匀。

8. 最佳实践与工程化建议

如果前面几步都跑通了，下面这些建议能让你在真实项目中少走很多弯路。

8.1 数据采集规范

固定相机参数，尽量使用定焦镜头；
环绕目标时，相邻照片角度差控制在 5 到 15 度之间；
光圈不要开太大，保持整个画面清晰；
室内场景要保证光照均匀，不要出现大面积过曝或死黑；
不要只拍一个环形圈，要增加俯拍、仰拍，否则重建顶面和底面会失败。

8.2 训练参数调整顺序

进入调参阶段后，优先改这些参数：

图像分辨率：决定训练速度和显存占用，优先调整；
迭代次数：影响细节收敛程度和过拟合风险；
损失权重：L1 和 SSIM 的权重影响边缘锐度和颜色还原；
学习率：通常保持默认即可，除非损失剧烈震荡；
初始点云密度：稀疏点云数量过少时，可以在 convert 阶段抽出更多特征点。

调参时，每次只改一个变量，并记录结果。不要同时改分辨率、迭代次数和损失权重，否则很难定位到底是什么导致的改善或劣化。

8.3 场景管理与版本控制

高斯飞溅的产物本质上是点云文件加训练配置。建议把原始照片、COLMAP 中间结果、训练输出、导出网格分开存放，方便复现和对比。多轮实验可以使用类似下面的目录结构：

projects/room_scan/ ├── input/ # 原始照片 ├── processed/ # convert.py 生成的数据 ├── runs/ │ ├── exp_1600_30000/ │ ├── exp_2000_40000/ │ └── exp_1200_20000/ └── reports/ # 截图、指标记录

8.4 与三维引擎集成

如果想把高斯飞溅场景嵌入 UE、Unity 或 Web 应用，不能直接使用官方训练脚本的输出，而是需要转换成对应平台支持的格式。目前社区中已经有多种插件和转换器，可以把训练好的高斯模型打包成引擎可加载的格式。选择插件时，要注意版本匹配，并重点测试大场景的加载和渲染性能。

8.5 安全与合规提醒

三维重建技术本质上是对物理世界的数字化，在采集公共空间、他人财产、敏感建筑、人脸等数据前，务必确认合规授权，遵守数据采集和模型发布的相关规定。不要拍摄和发布涉及他人隐私、商用受限或安全敏感的场景。公开发布模型时，建议检查是否包含可识别的人脸、车牌等敏感信息，必要时先做脱敏处理。

8.6 性能优化方向

如果场景规模很大，比如整个园区、体育场、大型展厅，几十万张图片的规模会让训练和渲染都面临挑战。常见优化方向包括：

对空间做分块训练，再合并相邻块的高斯；
使用更稀疏的采样策略，减少冗余高斯；
使用多卡并行或分布式训练；
在渲染端做裁剪，只渲染视野内的点。

这些方向都需要对 3DGS 的结构有较深理解，实际项目中可以按需研究。

9. 总结与后续学习方向

从接触这个概念到完成一次场景重建实验，你会发现高斯飞溅真正打动开发者的点，不是某一个“魔法参数”，而是它重新定义了三维场景表达和渲染之间关系的思路。它用上百万个显式三维高斯替代了隐式神经网络体素场，用可微光栅化替代了射线采样，用显著更低的算力成本换来了接近甚至超过传统方案的效果。这套设计思路本身就值得深入学习。

如果你接下来想继续深入，建议按下面顺序推进：

读完 3D Gaussian Splatting 的原始论文，理解每个公式在代码中对应哪一部分；
阅读官方训练脚本的源码，重点看高斯参数在优化器中如何更新；
尝试用你自己的手机拍摄一个物体，走完“采集 → 重建 → 渲染”全流程；
如果对实时应用感兴趣，研究如何通过分块和剪裁提高大场景渲染帧率；
关注后续的改进工作，例如动态场景、结构化表示、光照编辑等方向。

在做实际项目时，请记住一件事：高斯飞溅不是万能的三维重建解决方案，它在复杂反射、纯色区域、超大尺度场景上仍然有明确的短板。判断一个项目是否适合用高斯飞溅，核心看三个条件：是否有多视角照片、是否需要实时交互、是否接受点云式而非网格式的最终表达。三个条件都满足，这个技术大概率会给你带来很好的体验；如果只满足其中一个，建议再对比传统重建和其他方法再做决定。

建议把这篇文章收藏备用。当你以后在训练中遇到编译失败、显存不足或结果模糊时，再回来看第 5 节和第 7 节的内容，很多问题都能快速定位。

高斯飞溅3DGS原理与实操：从照片到实时三维场景重建