3DGEER：几何精确的3DGS框架，破解鱼眼与超广角重建难题

1. 为什么3DGS一碰到鱼眼和超广角就露怯

1.1 标准3DGS的透视假设到底意味着什么

3DGS整个流程本质上就是要把一个三维场景“拍扁”到二维像素网格上。每个高斯基元由中心位置、各向异性的协方差、不透明度和颜色构成，训练时用球谐系数表达视角相关的颜色变化。渲染时最关键的一步是投影：先把高斯基元的中心从世界坐标变换到相机坐标系，再通过透视投影拿到图像平面上的像素坐标。这里面有一个隐藏很深的假设，就是相机是针孔模型，成像遵循线性透视，视场角通常只有几十度。

用生活经验来理解就是：针孔投影像透过一个小孔看世界，视野内的直线还是直线；鱼眼镜头则像透过一个玻璃球看世界，边缘的直线会被弯成弧线。当视场角超过110度以后，画面边缘的桶形畸变已经非常明显，如果仍然用针孔公式去计算每一个像素的对应关系，投影位置就会在边缘系统性偏出好几个像素。这个误差对3DGS是致命的，因为训练时高斯基元要靠梯度不断调整位置和形状，投影模型错了，等于让整个场景在错误的空间映射下去拟合观测，最终的渲染效果必然是边缘模糊、重影，甚至场景几何被整体拉弯。

更要命的是，这种误差不是随机的，而是随着像素到图像中心距离的增加越来越大。网络在训练时想尽力补偿，结果就是把大量高斯点堆到错误位置去“凑”这些偏移，导致高斯基元数量爆炸，收敛速度却很慢。我见过不少人在超广角数据上跑标准3DGS，loss怎么都降不到理想值，最后发现根本不是场景复杂，而是镜头模型从第一步就错了。

1.2 先矫正图像再训练，为什么总是不对劲

很多人第一反应是把鱼眼图像先用校正算法展开成透视图，再跑标准3DGS。这条路我也走过，小场景、小视角的时候确实能出效果，但一旦视角开阔、场景有真实纵深，问题就层出不穷。图像校正的本质是把非线性映射强行拉直，结果必然是中心区域像素被压缩、边缘像素被过度拉伸，插值产生的模糊和锯齿直接进入训练数据。

更关键的问题是，校正后的图像并不是原始传感器输出，每个像素都被不同程度地重采样过，有的像素携带的信息少，有的像素信息密度高。但是3DGS的光栅化并不感知这些权重，会把插值出来的伪影也当成场景细节去学习，等于给训练数据增加了一层系统性噪声。边缘越广，这层噪声越明显，最后渲染出来的图虽然看起来“矫正过”，但细节已经糊了。

还有一种常见方案是切分视角，把大视场切成多个透视子视锥分别处理再合并。听起来有道理，实际操作起来处处是坑。子视锥之间的重叠区域会重复计数高斯点，边界处因为位姿估计和拼接误差经常出现明显断层；想让接缝看不出来，还得额外做跨区块的深度一致性约束，工程复杂度比预想大得多。鱼眼图像本来就有非线性畸变，做分区处理前还得先确定畸变分区规则，整套流程下来，已经快忘了原本要做的是3D重建。

1.3 为什么传统光栅化在广角场景反而更慢

标准3DGS的光栅化采用基于图块的并行策略：把屏幕划分成固定大小的块，同一个块内的高斯并行排序、融合。这个设计在针孔投影下非常高效，因为三维空间到像素网格的映射在局部近似均匀，每个图块里需要处理的高斯数量相差不大。

但超广角和鱼眼的投影会让边缘区域的像素密度急剧增加。同一个三维点靠近画面边缘时，它的投影在像素空间中会被“拉伸”，覆盖许多像素；相反，中心区域一个像素可能对应很大的一片空间。这种不均匀性导致的直接后果是，图块内的高斯数量差异悬殊，有些边缘位置的图块需要排序和融合的高斯数量远超中心图块，并行负载失衡，整体效率反而下降。

精度也没占到便宜。由于投影公式不匹配，边缘区域的高斯位置始终在错误位置附近挣扎，必须用更多高斯点去覆盖模糊区域，计算量上去的同时，质量还留不住。所以我说“精度和效率双输”并不是夸张，成像模型不匹配，付出的代价是一开始就注定的。

2. 3DGEER核心设计解构：几何精确如何落地

2.1 从硬编码透视投影到统一可微相机模型

3DGEER最大的改动并不在网络结构，而是把标准3DGS里写死的透视投影抽象成一组可微的相机模型接口。你可以理解成给渲染管线换了一套“可换镜头系统”：针孔、等距鱼眼、等立体角鱼眼、柱面投影这些模型都实现了同样的前向投影和反向梯度接口，光栅化器只关心“从三维点如何映射到像素坐标”，不再默认图像一定是透视投影。

这个设计让“几何精确”从一句口号变成了结构约束。高斯基元的职责回归到本来的位置，只需要拟合场景的几何形状和材质属性，不需要再偷偷补偿相机模型误差。我在自己采集的鱼眼数据上看训练曲线，感受非常明显：同样的迭代次数，3DGEER的边缘区域梯度下降得更平稳，长尾模糊明显减少，而标准3DGS在边缘位置长时间停留在高损失状态。

官方把这个工作定位成“首个几何精确的3DGS框架”，这里说的几何精确不是加一个深度正则项那么简单，而是投影数学和传感器模型从第一性原理上保持一致。渲染器里每一条从三维点出发、穿过镜头、落到像素的光线路径，都由相机模型严格决定，而不是近似。

2.2 鱼眼、超广角与跨相机联合优化的实现思路

实现层面，3DGEER里每个视图都有自己的相机参数对象，包含投影类型、内参、畸变系数和位姿。训练时所有视图共享同一组三维高斯，但每个视图按照自己的投影分支完成渲染。如果你对某个相机的内参不太放心，可以开启内参优化，让焦距、主点坐标、畸变系数一起参与反向传播。因为整个链路是可微的，相机参数和高斯参数可以在同一轮迭代里同时更新，不需要在训练之前做任何图像矫正。

跨相机联合训练解决的是多源数据融合问题。同一个场景里，如果有手机拍的透视照片、运动相机拍的鱼眼视频，还有车载摄像头捕捉的超广角画面，传统做法是先做统一投影变换，把鱼眼纠正成透视，把全景切块，每一步都在损失原始信息。3DGEER的处理方式很直接：保留每个视图原来的投影类型，在训练循环里按视图选择对应的投影分支，损失函数在原始像素空间统一计算。这样一来，不同传感器的信息可以以原始质量共同参与重建，而不是先被降到同一个有损格式。

我特别欣赏的一点是，它对“跨相机”的支持不是靠分别训练再融合，而是在同一个优化问题里联合求解。场景是一个三维高斯场景，所有相机看到的都是同一个三维模型，不同投影模型只是同一物理场景在不同传感器上的成像结果。这种统一视角让跨相机对齐从操作层面变成数学结构的一部分，而不是训练后的人工后处理。

2.3 效率提升至少来自三个层面

标题里说“渲染精度与效率全面提升”，听起来像宣传语，但实际拆开看，效率提升是有明确机制的。第一，几何精确后，边缘区域不再需要用大量高斯去掩盖投影误差，高斯基元总数可以更经济，同样的显存就能容纳更多有效细节。第二，光栅化器针对非针孔投影做了更聪明的剔除：鱼眼前向投影时可以主动跳过视场外的点，而不是先投影到平面再丢弃；超广角下图块分配按角度密度而不是像素坐标均匀划分，避免了大量无效计算。第三，预处理流水线变短了，不需要图像矫正和重采样环节，数据从原始格式直接进入训练，加载、存储和每次迭代的成本都更低。

过去这个方向做得少，不是大家不想做，而是门槛实在高。要在GPU光栅化核心循环里同时支持多种投影模型的forward和backward，还要保持高斯基元排序和图像块管理的效率，代码复杂度很高。很多团队宁可花大力气修图像矫正也不愿意动渲染器，这个选择我能理解，但不代表问题不存在。

3. 实操记录：从零跑通3DGEER

3.1 环境准备与编译安装

官方仓库推荐在Linux类服务器上运行，且要有支持并行计算扩展的GPU环境。我这边用的是一台配置中等的单卡机器，编译过程顺利，但有几个细节值得提醒。

首先，强烈建议用虚拟环境工具创建独立环境，不要和已有的三维重建项目混装。不同版本的光栅化扩展会互相覆盖同一个共享库文件，出了问题很难排查。其次，编译阶段的报错大多集中在编译器版本和GPU工具链不匹配上，建议编译器版本保持在行业通用范围内，不要盲目追求最新。

我把安装命令整理成了最基础的一版：

git clone <3DGEER官方仓库地址> cd 3DGEER python setup.py build_ext --inplace

如果官方额外提供了环境依赖清单，先在当前环境里逐一确认版本，再执行编译。还有一点经验是，如果机器上之前装过旧版本的开源光栅化扩展，编译安装3DGEER之前最好先把它卸载干净，否则运行时可能会import到旧模块，出现“明明装了新版却还在走旧逻辑”的诡异问题。

3.2 数据准备：别在相机参数格式上省时间

3DGEER的数据组织方式延续了三维重建领域常用的稀疏重建格式，但相机描述文件里多了一个投影类型字段。这个字段支持透视、鱼眼、柱面、全景等不同取值。准备数据时，我建议直接用官方提供的转换脚本，把图像序列、相机内参、畸变系数和位姿统一写入一个场景描述文件。

流程大致是这样：先用标定工具得到每张图或每个视频帧的初始内参和畸变系数；然后对图像序列做特征匹配和稀疏重建，拿到相机的位姿和场景点云；最后运行转换脚本，把这些信息转成3DGEER可用的格式。这个过程需要小心畸变系数的单位，有的标定工具输出的是像素单位，而3DGEER的接口默认使用归一化坐标。单位填错，训练一开始就会出现飞点或者分裂爆炸，非常打击信心。

我的习惯是转换完成后做一次可视化验证：把训练图像和3DGEER渲染出的初始深度叠加在一起，如果边缘有明显偏移，优先检查投影类型和畸变参数，而不是急着调学习率。这一步虽然花不了几分钟，但能省掉后面大量的无效训练时间。

3.3 单卡鱼眼训练：我的标准命令与参数习惯

以一个室内鱼眼序列为例，我常用的启动命令是：

python train.py -s data/fisheye_scene \ --camera_model fisheye \ --sh_degree 2 \ --iterations 30000 \ --optimize_camera_params \ --eval

有几个参数值得展开说。球谐阶数在多数室内场景设为2就够，过高的球谐阶数不仅增加计算量，还容易把高频噪声也学进去。内参优化参数建议不要一开始就打开，先让三维高斯分布成型，再放开相机参数做微调，否则初始内参误差会误导致密化过程。

鱼眼数据经常会遇到有效视野没有覆盖整张图像的情况，画面四角是黑的或者没有有效内容。如果这些区域不处理，网络会尝试用高斯把它们重建出来，白白浪费表达能力。建议使用掩膜功能，或者自己生成一个有效视野掩膜，让边缘无效像素不参与损失计算。除此之外，我习惯把高斯基元分裂的结束迭代数稍微延长一些，因为鱼眼场景的边缘区域像素密度高，太早停止分裂会留下大片欠重建区域。

3.4 跨相机联合训练：把不同类型数据放进同一个场景

跨相机场景的关键是统一坐标系和数据集描述。如果有多个子目录，每个子目录由不同相机拍摄，官方推荐使用自动模式，让程序按每个视图的投影类型选择对应的分支。我的做法是把所有子目录的数据合并到一个场景描述文件里，每个图像条目绑定正确的相机编号，然后运行：

python train.py -s data/multi_cam \ --camera_model auto \ --joint_opt_cameras \ --densify_grad_threshold 0.0003 \ --iterations 40000

开启内参联合优化后，相机内参会在训练中持续微调。这里最关键的是不能把错误离谱的初始内参直接交给优化器。我自己总结的流程是：第一阶段冻结内参，训练几千步让三维高斯大致成型；第二阶段再放开内参，并把相机学习率设成位置学习率的十分之一左右。这样一来，内参只会在合理范围内做细微调整，不会在前期被梯度带着乱跑。

跨相机还有一个容易被忽略的问题，就是分辨率不均衡。大分辨率视图贡献的梯度绝对值天然更高，会压制小分辨率视图的学习。如果不同相机拍摄的原始图像尺寸相差很大，建议先统一训练分辨率，或者按视图的像素数量对损失函数加权。我在包含鱼眼大图和普通小图的混合数据上深有体会，不做这一步，大图区域的重建细节会明显好于小图区域。

4. 调优、评估与常见问题排查

4.1 评估不能只看渲染指标，几何验证更重要

三维重建领域习惯用PSNR、SSIM这些二维图像指标来衡量质量，但对3DGS来说，这些指标对几何误差并不敏感。一个地方几何偏移了，只要网络用一点模糊把误差掩盖住，二维指标照样好看，但重建出的深度图其实是错的。

既然3DGEER强调几何精确，我觉得评估时至少要加三类几何证据。第一，渲染深度和已知点云或者激光雷达扫描之间的误差；第二，从训练好的高斯基元中抽取点云，和稀疏重建点云做配准，观察有没有系统性偏移；第三，跨相机联合训练时，不同相机对同一个表面的几何重建是否连续。我在自己做的一组混合相机数据上验证时发现，画面看起来已经没什么问题，但深度图上不同相机覆盖区域的接缝处有明显断层层级，二维指标完全体现不出来。

所以我的建议是，在项目里同时维护一套二维指标和一套几何验证脚本。渲染图指标用于整体质量监控，几何指标用于判断重建是否真的可信。对做重建应用的人来说，后者往往更重要。

4.2 高频问题速查手册

这些坑大部分不是理论推导出来的，而是在实际数据上踩出来的。我遇到最多的问题是“看起来在收敛，但边缘总是有一层淡雾”，最后排查下来发现只是因为没有处理图像边缘的黑边，网络一直在拟合无效区域。很多情况下，先解决数据质量问题，比调任何超参数都有效。

4.3 大视野场景的稠密化调整建议

3DGS的致密化机制依赖每个高斯的梯度累积和透明度。大视野场景里，边缘区域单个像素对应的空间范围比中心大很多，梯度尺度天然偏小，所以边缘经常分裂不足。建议在用超广角数据时，把分裂梯度阈值调低一点，同时把分裂结束迭代数适当延长，让网络有更多时间去补齐边缘。

另一个实用的技巧是限制高斯基元的初始尺度，让网络从更细的粒度开始分裂。这样做的好处是细节更容易贴合，代价是显存占用明显增加，所以我一般只在场景规模不大或者单卡显存充足时使用。超广角还容易在相机环绕采集但上下视野不足的场景中出现背景空洞，这种情况与其盲目增加高斯数量，不如先用场景包围球初始化背景高斯基元，后续训练再逐步雕刻细节。加了这个初始化之后，后方黑洞的问题基本就消失了。

5. 个人观察与后续扩展

5.1 对生产流程的影响

3DGEER对多相机重建流程最大的影响，是把“原始数据直接参与训练”变成了可行方案。以前为了把多个来源的数据放进同一套3DGS流程，总要牺牲某一路相机的原始几何信息：鱼眼要矫正，全景要切块，超广角要裁边。现在可以让传感器回归本来面目，每个相机用自己的投影模型参与重建。做合成数据的人会更有体会，虚拟相机、鱼眼传感器、多目系统的仿真数据现在可以端到端直接训练，不用为每一种传感器单独写一个矫正模块。

我判断这个方向会逐渐成为一种基础设施能力，而不是某个项目的独门特性。三维重建走到今天，瓶颈已经从“有没有足够的数据”变成“能不能让不同来源的数据真正协同工作”，几何精确的投影模型是绕不开的一环。

5.2 后续可以怎么扩展

如果条件允许，我最想在这套框架上继续做两件事。第一是把时间维度引进来，变成动态场景版本，配合跨相机时间同步，可以做多视角时空一致的动态重建，这对运动场景和实时应用会很有价值。第二是加入显式几何约束，比如深度正则、法向一致性、边缘感知损失，让几何精确从“渲染正确”向上走一步，达到“表面正确”。

最后分享一个个人经验：很多新用户上来就直接挑战跨相机联合训练的终极形态，结果被内参优化和位姿误差折腾得崩溃。我的建议是先从一个鱼眼或超广角场景跑通，确认投影类型、掩膜、稠密化策略都正常，再逐步加入第二种相机。这条路线看起来慢，实际踩的坑比一步到位少太多。技术本身再强大，也经不起一开始就把所有不确定因素叠加在一起。