最近一段时间三维重建领域最热的关键词已经从“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.04Windows 也可以跑但编译环境会多踩一些坑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/roomconvert.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 --recursiveCUDA 版本不匹配PyTorch 与 CUDA 工具链冲突执行python -c import torch; print(torch.__version__)按 PyTorch 官方提示重装匹配版本的 CUDA 和 PyTorchconvert.py 找不到 COLMAPCOLMAP 未安装或未加入 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 节的内容很多问题都能快速定位。