Gaussian Splatting 实时渲染原理与游戏场景重建实践

最近高斯泼溅（Gaussian Splatting）相关的视频在技术圈和游戏圈同时刷屏，而其中“Gaussian Splat in GTA: San Andreas”这个方向尤其让人过目难忘。如果你只看标题，可能会以为这又是一次“用AI把老游戏画面变清晰”的趣味实验；但真正懂行的人会意识到，这个视频触碰的是三维渲染领域一个更深层的转变：传统引擎用三角形网格和贴图描述世界，而这类演示正在尝试用一堆可实时渲染的高斯分布点来描述整个开放世界。

这篇文章想讲清楚三件事：第一，Gaussian Splatting 到底是什么，它凭什么能实时渲染出可自由漫游的场景；第二，把一个游戏世界变成 Gaussian Splat 场景，技术上要经历哪些步骤、会踩哪些坑；第三，如果你想自己亲手跑通一个类似流程，环境怎么搭、数据怎么准备、命令怎么执行。我们不做“看视频喊厉害”的观众，而是从技术的角度拆掉它。

1. 为什么这个视频值得关注

1.1 从一个小视频看到的技术信号

“Gaussian Splat in GTA: San Andreas”这个标题看起来是在展示某个人的技术实验，但它背后指向的是过去两年三维视觉领域最热的趋势之一。GTA: San Andreas 是 2004 年发布的开放世界游戏，场景里有完整的城市道路、建筑、车辆、植被和天空。把一个近二十年前的游戏场景用 3D 高斯泼溅重新表达出来，核心意义并不在于“还原”，而在于两点：一是场景规模足够大，二是渲染过程可以实时交互。

过去我们对“从图片重建 3D 场景”的认知大多是离线流程：拍一堆照片，让程序算上几个小时甚至几天，最后导出一个网格模型。但 3DGS 出现以后，这种“重活”被压缩到了几十分钟以内，而且渲染速度能到实时帧率。视频里那种鼠标一拖、视角就平滑飞过街道的体验，在以前的 NeRF 时代是难以想象的。NeRF 要渲染一帧新视角，往往需要网络推理几十次甚至上百次，根本做不到流畅。

所以这个视频值得关注，不是因为它把 GTA: SA 做“好看”了，而是它用最简单的例子告诉所有人：3DGS 已经能从视频或照片里重建出一个可以实时漫游的开放世界。这个能力一旦成熟，影响面会非常广。

1.2 3DGS 的定位：不是另一个 NeRF

很多人看到 Gaussian Splatting 的第一反应是“又一个 NeRF”。这个判断不算错，但不够准确。NeRF 把场景编码在一个神经网络的权重里，渲染时需要通过 MLP 查询每个采样点的颜色和密度，本质上是一种隐式表达。3DGS 则完全不同，它把场景显式地表示成上百万个三维高斯分布点，每个点有自己的位置、大小、方向、颜色和不透明度。渲染时只需要把这些点按照深度排序，再投影到屏幕上做 alpha 混合。

这种“显式点云 + 实时光栅化”的思路，让 3DGS 同时拿到了两个好处：训练阶段不需要像 NeRF 那样在每条射线上做大量采样，渲染阶段也不需要神经网络逐点推理。从技术演进的角度看，3DGS 的真正价值不是“超过了 NeRF 多少个百分点”，而是把辐射场渲染从离线领域拉进了实时交互领域。GTA: SA 这种开放世界场景演示，恰好是这种能力最直观的证明。

2. Gaussian Splatting 核心概念与原理

2.1 直观理解：把场景拆成无数“半透明光斑”

如果你想给一个完全没接触过 3DGS 的朋友解释，最直观的说法是：3DGS 把场景拆成了一堆半透明的小光斑，这些小光斑在空间中按不同位置、大小、颜色、透明度分布。训练时，程序会不断调整这些小光斑的参数，直到从任意一个相机角度看去，它们叠加出来的画面都和真实照片一致。

这个思路很像我们用很多不同颜色的小圆点去拼一幅画：远看是一张完整的图像，近看是无数离散的单元。不同的是，3DGS 是三维空间中的小圆点，它们不仅带有颜色，还带有“厚度”和“透明度”。渲染时，越靠近相机的高斯点越先被画上去，远处的点被近处的点遮挡，最终形成逼真的画面。

这个设计最大的好处是，渲染过程天然适合 GPU 光栅化。传统网格渲染需要对三角形做顶点变换和光栅化，3DGS 只是把“三角形”换成了“高斯分布点”，整个管线依然是高度并行的，所以能达到实时帧率。

2.2 每个高斯点到底在表达什么

严格来说，3DGS 的每个高斯点对应一个三维高斯分布，可以通过下面的参数描述：

• 位置：高斯点在三维空间中的中心坐标。
• 协方差矩阵：由旋转矩阵和缩放矩阵组合而成，决定这个高斯点在空间中是“圆球”还是“扁椭球”，以及它的朝向。
• 不透明度：控制这个点在渲染中的可见程度。
• 球谐系数：用于表达视角相关的颜色变化，让物体在光照变化下看起来更真实。

训练过程中，程序从一组带相机位姿的图片出发，先用 SfM（运动恢复结构）生成稀疏点云，把这些点作为高斯点的初始位置。然后通过可微渲染，不断把当前模型渲染出的图像和真实图像做比较，计算梯度并更新所有高斯点参数。同时，系统还会根据场景复杂度自适应地分裂或克隆高斯点，让简单区域少放点、复杂区域多放点。

这个过程用一句话概括就是：用可微渲染做端到端优化，把场景的“最佳表达方式”直接算出来。

2.3 与传统渲染管线的对比

从表格可以看出一条清晰的脉络：3DGS 和传统渲染一样是显式表达，因此能得到实时性能；但它没有严格的拓扑和表面约束，所以更像是一堆“视觉上正确的点云”，而不是可以被物理引擎直接使用的实体几何。GTA: SA 这类演示给我们的启发正在于此：如果未来这些高斯点能进一步被编辑、被压缩、被引擎真正接收，那它就不再只是一个“重建工具”，而可能成为一条新的渲染管线。

3. 为什么用游戏场景做演示

3.1 真实场景与合成场景的区别

如果你看过 3DGS 的经典论文，会发现大部分演示都集中在室内物体、户外街道、人像等真实场景。真实场景拍摄有几个天然难点：相机位姿需要靠 COLMAP 等工具从图像中估计，光照会随时间变化，场景中的行人、车辆、树叶会造成动态干扰。这些问题不是不能解决，但会显著增加实验门槛。

游戏场景恰好相反。它是由引擎渲染出来的合成画面，我们完全可以控制相机轨迹、锁定游戏内时间，尽量避免动态物体。最理想的情况下，如果游戏本身支持自由相机脚本，还能直接导出精确的相机位姿，省掉 COLMAP 估计的环节。这就是为什么很多 3DGS 技术验证会选择游戏场景来做：数据获取成本低，控制变量容易，实验可复现性强。

但游戏场景也不是没有坑。游戏贴图往往大面积重复，建筑墙面、路面纹理都很相似，这会导致特征匹配出现歧义；天空、光滑水面这类无纹理区域也会让 SfM 算法很难算准。换句话说，游戏数据在“获取”上更友好，但在“特征质量”上反而更考验预处理。

3.2 GTA: SA 作为测试场景的合理性

GTA: San Andreas 的场景规模在 2004 年是相当惊人的，放在今天看则是一个“结构复杂度适中”的开放世界：它有完整的街道布局、不同类型的建筑、桥梁、植被和天气变化，但场景总规模又不像现代 3A 游戏那样动辄数百平方公里。用这种场景做 3DGS 演示，既不会因为数据量太大导致训练完全不可行，又能证明方法在“城市级”场景中的潜力，是一个平衡得很好的选择。

从技术传播的角度看，经典游戏本身就自带流量。一个大家共同记忆里的游戏场景，突然可以被鼠标拖拽着自由飞行，这种反差感比“在城市街道上重建一个路口”更容易让普通观众理解 3DGS 在做什么。因此这类视频的意义往往是双重的：对内是技术验证，对外是极佳的技术科普素材。

3.3 不要神化这类演示

不过，也要冷静看待这类视频。它们展示的是“静态场景的实时渲染”，不是“一个可以玩的游戏”。3DGS 模型里没有物理碰撞、没有 NPC 逻辑、没有任务系统，本质上只是一组静态高斯点在按照相机视角做正确投影。如果你试图让一辆车在模型里开起来，就会发现它根本没有“路面”的几何概念，所有交互都要重新开发。

所以更准确的定位是：这类项目验证了 3DGS 对复杂场景的表征能力，同时也提醒我们，它距离成为游戏引擎的替代品还有很长一段路。真正有价值的问题是“这种新渲染表示未来怎么接入游戏引擎、数字孪生、虚拟制片”，而不是“它能不能直接重制一款老游戏”。

4. 从游戏画面到 3DGS：通用技术路线

4.1 总体流程

无论目标场景是真实城市还是游戏世界，用 3DGS 重建一个可漫游场景的整体流程都很相似：

1. 采集数据：从游戏内录制视频或截图，得到多视角图像。
2. 估计相机位姿：用 COLMAP 对图像做特征提取、匹配和稀疏重建。
3. 数据格式转换：把 COLMAP 结果转换成 3DGS 训练脚本能读取的格式。
4. 训练 3DGS：用多视角图像和相机位姿训练高斯点参数。
5. 渲染与验证：用训练好的模型渲染新视角，评估画面质量。
6. 可视化与导出：用查看器自由漫游，或者把渲染序列合成视频。

从这张流程表可以看到，3DGS 的“门槛”并不在训练本身，而在数据准备。数据质量直接决定重建结果的上限，后面的训练只是把这个上限尽量逼近。

4.2 两条位姿获取路径

第一条路径是用 COLMAP 从视频帧中估计位姿。这是最通用的做法，适合任何“只能录屏”的游戏场景。录制时，相机需要缓慢平稳地移动，画面之间要有足够的重叠区域，避免快速转向和大幅抖动。帧率可以选择 2 到 5 帧每秒，数量太少会导致匹配不稳定，数量太多则会大幅增加特征提取时间。

第二条路径是直接导出相机位姿。如果场景来源不是普通商业游戏，而是自研引擎、可调试的开源游戏，或者用 Blender/Unreal 生成的合成渲染，那就可以在渲染管线里直接记录每帧相机的内外参数，配合深度图一起输出。这条路径通常能得到更精准的位姿，重建质量也更高。对于标题中的 GTA: SA 项目，具体是哪种路线无法仅凭标题确定，但从社区实践看，绝大多数游戏场景 3DGS 演示都基于第一条路径，也就是“录屏 + COLMAP”。

4.3 数据质量决定结果上限

这是所有 3DGS 项目里最容易被忽略的一点。模型效果不好，99% 的情况不是训练参数不行，而是输入数据有问题。数据采集阶段只要控制好这几点，结果通常不会差：

• 相机运动速度要慢，避免运动模糊。
• 视角覆盖要全，街道路口最好从多个方向扫过。
• 光照环境保持一致，关闭动态天气和昼夜循环。
• 尽量避免大范围水面、透明玻璃、动态角色入镜。
• 画面之间重叠度建议在 70% 以上。
• 不要用过强的后期滤镜，避免颜色被过度扭曲。
• 分辨率保持一致，建议至少 1080p 起步。

有人会问：游戏场景不是引擎渲染出来的吗，怎么还会有运动模糊？事实上很多游戏默认开启景深和动态模糊，这些后处理效果会破坏帧间特征匹配，录制时最好在画质设置中关掉。

4.4 版权与合规提醒

这里必须强调合规边界。用游戏录屏做个人技术学习、本地实验，在社区里是很常见的事情；但如果要把重建出的模型、视频对外发布，甚至用于商业项目，就涉及游戏版权问题。GTA: SA 的场景资产属于发行方，3DGS 重建结果本质上是对这些场景资产的再处理。建议只把这类实验限定在学习和研究用途，引用时注明来源，必要时咨询版权方授权。不要使用破解、提取内部资产等不合规手段，这既不符合技术分享的底线，也可能带来法律风险。

5. 动手实践：环境准备与安装

5.1 硬件与软件要求

3DGS 训练和渲染都需要 NVIDIA GPU，因为官方实现依赖 CUDA 加速。显存越大越省心，但显存偏小的机器也不是完全不能跑，可以通过降低输入图像分辨率、减少迭代次数、限制高斯点数量等方式缓解。日常做实验建议准备 8GB 以上显存，如果目标场景是大型开放世界，16GB 会更从容。

软件层面推荐使用 Linux 或 Windows + WSL。官方仓库对 Linux 的支持最稳定，Windows 原生的编译依赖多一些。需要提前装好：

• Python 3.8 及以上版本。
• conda 或 venv。
• NVIDIA 驱动和 CUDA 工具包。
• CMake 与编译工具链。
• COLMAP，用于相机位姿估计。

5.2 安装官方 gaussian-splatting 仓库

官方代码库由 INRIA 团队开源，是目前最核心的参考实现。安装时可以这样做：

git clone https://github.com/graphdeco-inria/gaussian-splatting.git cd gaussian-splatting # 使用 conda 创建环境并安装依赖 conda env create --file environment.yml conda activate gaussian_splatting

environment.yml会安装 PyTorch、CUDA 相关依赖以及其他 Python 包。这个环境创建过程通常需要几分钟，具体版本以仓库当前 README 为准。如果 conda 在国内网络环境下下载缓慢，可以考虑配置镜像源。

5.3 安装 COLMAP

COLMAP 的安装方式取决于操作系统。Linux 上可以直接用包管理器安装，但版本可能偏旧；Windows 上更推荐到 COLMAP 官方发布页下载预编译版本。安装后建议执行以下命令验证：

colmap -h

能正常输出帮助信息即可。需要注意，COLMAP 的 GUI 版本和命令行版本在部分 Windows 安装包中是分开的，训练流程只需要命令行工具，不必依赖 GUI。

6. 完整实操示例：视频抽帧、位姿估计与训练

6.1 数据准备：从视频抽帧

假设你有一段游戏内录制的视频，先用 Python 加 OpenCV 把它抽成序列帧。这里建议每秒抽 2 到 5 帧，不要直接把 60FPS 的视频全部导出，否则后续 COLMAP 的特征提取和匹配会非常慢，而且相邻帧太相似对位姿估计没有额外帮助。

import os import cv2 video_path = "source/gtasa_clip.mp4" frame_dir = "input/frames" os.makedirs(frame_dir, exist_ok=True) cap = cv2.VideoCapture(video_path) fps = cap.get(cv2.CAP_PROP_FPS) interval = max(1, int(round(fps / 2))) # 约每秒抽 2 帧 index = 0 saved = 0 while True: ret, frame = cap.read() if not ret: break if index % interval == 0: frame_path = os.path.join(frame_dir, f"frame_{saved:05d}.jpg") cv2.imwrite(frame_path, frame) saved += 1 index += 1 cap.release() print(f"saved {saved} frames")

运行完后，检查input/frames目录下生成多少张图片。如果只有几十张，可能覆盖不足；如果上千张，可以考虑提高抽帧间隔，先跑一个较小的集合验证流程。

6.2 COLMAP 特征提取与匹配

接下来进入input目录，对抽出的帧做特征提取、匹配和稀疏重建。这里用的都是 COLMAP 命令行接口：

cd input # 1. 特征提取 colmap feature_extractor \ --database_path database.db \ --image_path frames \ --ImageReader.single_camera 1 # 2. 特征匹配（图片量不大时用 exhaustive_matcher 即可） colmap exhaustive_matcher \ --database_path database.db # 3. 稀疏重建 mkdir -p sparse colmap mapper \ --database_path database.db \ --image_path frames \ --output_path sparse

--ImageReader.single_camera 1表示所有图片都来自同一个相机，对游戏录屏非常合适。如果你的图片集是不同相机拍摄的，就不应该加这个参数。exhaustive_matcher会做两两匹配，精度高但耗时与图片数平方相关，建议先用 100 到 300 张图的小集合测试。

稀疏重建完成后，sparse目录下会生成0子目录，包含cameras.bin、images.bin、points3D.bin等文件。这些就是后续训练所需的初始位姿和稀疏点云。

6.3 数据格式转换

官方代码库中提供了convert.py，它的作用是把 COLMAP 的输出转换成 3DGS 训练脚本需要的数据格式。可以在仓库根目录执行：

python convert.py -s input

这一步会先对图像做去畸变，再为训练准备稠密点云和相机参数文件。如果 COLMAP 重建成功，但convert.py运行报错，最常见原因是sparse/0目录结构不完整，或者 COLMAP 版本与脚本预期不一致。此时优先检查input/sparse/0下是否生成了三个 bin 文件。

转换后，input目录下会出现训练需要的关键文件，例如相机参数、点云 PLY 文件以及处理过的图像序列。到这里，训练数据就准备好了。

6.4 训练 3DGS 模型

训练命令非常简单，但背后的计算量并不小。对游戏场景这种大型输入，可以先跑默认迭代看效果：

python train.py -s input -m output/gtasa

如果不指定迭代次数，官方实现默认训练 7000 轮。显存不够时，可以加上--resolution 1或者降低输入图像分辨率，也可以用--iterations 30000提高训练量。具体参数名和默认值以仓库版本为准，本文无法枚举所有分支差异。

训练过程中，控制台会定期输出当前迭代的 PSNR、损失值等指标。训练时间取决于图片数量、分辨率和 GPU 性能，从几分钟到几十分钟都有可能。训练结束后，output/gtasa目录下会保存每个 checkpoint 点和最终模型。

6.5 渲染新视角与计算指标

训练完成后，用官方脚本渲染测试视角：

python render.py -m output/gtasa python metrics.py -m output/gtasa

render.py会根据训练好的模型渲染出一组新视角图片，metrics.py会计算 PSNR、SSIM 等量化指标。指标只能反映“和训练数据分布类似的视角”有多接近，真正适合游戏场景演示的是自由视角漫游，需要用到官方查看器。

6.6 用查看器自由漫游

官方仓库附带 SIBR 查看器，可以加载训练好的模型并沿任意路径飞行。如果你在安装时已经构建了查看器，可以这样打开：

./SIBR_viewers/bin/ibr_viewer --path output/gtasa

具体参数与构建方式以仓库 README 为准。打开后，按住鼠标拖拽就能在重建出的游戏场景里自由飞行，这是对整个流程最直观的验证。如果你更习惯命令行，也可以用render.py生成任意轨迹的图片序列，再用 ffmpeg 合成视频：

ffmpeg -framerate 30 -i output/gtasa/test/ours_7000/renders/%05d.png \ -c:v libx264 -pix_fmt yuv420p gtasa_result.mp4

注意ours_7000这个路径中的数字对应实际迭代次数，如果你的模型迭代了 30000 次，就要改成ours_30000。如果 ffmpeg 合成后视频无法播放，多半是 pixel format 问题，加上-pix_fmt yuv420p就能兼容绝大多数播放器。

7. 常见问题与排查清单

大多数 3DGS 训练问题都可以归结到“数据质量”和“显存限制”两个根源。如果你在某个环节卡住，优先做的不是改参数，而是回退到数据检查：图片清晰吗？重叠够吗？重复纹理多不多？这比盲目调参有效得多。

8. 最佳实践与工程建议

8.1 数据采集规范

游戏场景的数据采集要做到“慢、稳、全”。慢是指相机移动速度不能太快，否则会产生运动模糊；稳是指不要在录制中频繁快速转向；全是指尽量把要重建的区域从多个角度完整扫过，不要只沿一条街道直线前进。更具体的做法是：

• 录制前关闭游戏内的动态天气、昼夜循环和镜头后期特效。
• 绕目标区域做多次往返扫描，保证街角、建筑侧面都有覆盖。
• 如果场景中有大片天空，尽量让相机视角偏向下半部分，减少无纹理区域对匹配的影响。
• 控制视频长度，单个视频不要超过 10 分钟，方便后续抽帧和试错。

这些工作看起来很基础，但真正决定 3DGS 重建质量的就是这些细节。很多初学者把精力花在调训练参数上，反而忽略了输入数据这一层。

8.2 训练参数与显存优化

显存不足是 3DGS 实践中最常见的问题。可行的优化思路包括：

• 降低输入分辨率：把训练图片从原始分辨率缩放到 1080p 或更低。
• 减少迭代次数：先用 7000 轮快速验证效果，再逐步增加到 30000 轮。
• 限制高斯点数量：官方实现中可以通过--densify_grad_threshold等参数控制密度化速度，具体参数需查看仓库文档。
• 场景切块：把大场景拆成多个小区域分别训练，再用合并工具整合，代价是边界处可能出现接缝。

需要注意的是，显存优化的核心原则是“先保证流程能跑通，再追求画质”。哪怕先用极低分辨率训练一个粗糙模型，也能帮助你排查数据问题和代码问题。

8.3 大场景处理的思路

如果你最终目标就是复刻 GTA: SA 级别的完整场景，一定要意识到：单机单卡训练整个城市是一个不现实的方案。更稳妥的技术路线是：

• 先按区域切分场景，比如按街区或地标建筑划分。
• 为每个区域单独录制数据、单独训练模型。
• 训练完成后在发布端按空间位置加载不同模型，实现类似 LOD 的分块调度。
• 如果多个模型之间有重叠区域，尝试做网格融合或点云融合。

这个思路本质上借鉴了传统游戏引擎中“场景分块加载”的管理方式。3DGS 还很年轻，目前社区里关于大规模场景合并与调度的工具还在快速演进，因此做大型项目前，先拆小场景验证每个环节，再逐步扩展，是比较务实的选择。

8.4 工程化与团队协作建议

如果你是在团队里做 3DGS 相关项目，建议从一开始就规范好数据目录、实验记录和模型版本。例如：

• 统一数据目录结构：dataset/项目名/原始视频、dataset/项目名/抽帧、dataset/项目名/colmap输出。
• 记录每次训练的输入图片数、分辨率、迭代次数、GPU 型号和最终指标。
• 用固定的 conda 环境文件和 requirements 锁定依赖版本，避免不同成员机器上运行结果不一致。
• 所有脚本都做成可重复执行的命令行工具，不要依赖手工点击和临时参数。

3DGS 项目表面上是一个训练脚本的事，实际工程里最耗时间的往往不是训练，而是数据采集、数据清洗、实验对比和结果验证。好的工程习惯可以让这些环节的返工成本大幅降低。

8.5 版权与合规边界

这部分在实操层面的提醒很直接：如果要用游戏画面做实验，优先使用正版游戏和合法录制工具，尊重游戏本身的使用协议。任何形式的破解、绕过保护、直接提取游戏内部资源都是不可取的。技术上你可以做得很酷，但发布和商业化之前，必须先解决场景资产的授权问题。更稳妥的做法是，把技术验证放到自己可控的数据上，比如用 Blender 等软件生成可控合成场景，而不是直接拿商业游戏资源做线上展示。

9. 总结与后续学习方向

从“Gaussian Splat in GTA: San Andreas”这个演示出发，我们看到的不是一个简单的游戏怀旧视频，而是 3D 视觉和渲染方向的一次范式验证：3DGS 用显式的三维高斯点替代了传统网格和隐式网络，在保持实时渲染能力的同时，让“从图像重建开放世界”成为可能。这篇文章带你拆解了它的核心原理、数据准备、训练流程和常见问题，也分析了为什么游戏场景适合做这类技术验证，以及它的边界在哪。

如果你想继续深入，建议按下面的顺序实践：

1. 先不要挑战整个城市，找一个小型场景，比如一栋建筑、一个街角，录一分钟视频，跑通完整的 COLMAP + 3DGS 流程。
2. 学会看训练日志和渲染结果，理解 PSNR、SSIM 指标到底反映了什么。
3. 尝试通过控制变量，观察不同输入帧率、不同分辨率对最终模型的影响。
4. 再逐步扩大场景规模，体会显存、时间和画质之间的平衡。
5. 关注 3DGS 的衍生方向，比如 2DGS、4DGS、场景编辑、压缩与流式传输，这些都会在未来一两年里快速迭代。

把流程跑通只是第一步，真正提升的是你对“渲染场景如何被数据驱动”这件事的理解。建议把官方代码库、论文和 COLMAP 文档保存下来，结合这篇文章的流程反复对照。下次再看到一个“游戏场景被 3DGS 重建”的视频，你就不只是觉得酷，而是能判断出它大概走了哪些技术路线，又在哪里最容易翻车。