街景怎么把 3DGS 撑大

街景多出来的那些东西

原版 3DGS 假设了一件事：场景是静止的，相机围着它转。这两条在驾驶数据上都不成立。相机装在车上一路往前开，路上还有别的车在动，而且六个相机的曝光各不相同、标定给的位姿还带误差。

把这些差异列出来，正好就是这一课的目录：

还是先给定位，别默认全都要背：

加粗的那四条不是随便挑的——它们每一条都在你八月到九月的实验里咬过你一次，§9 会一条条对回去。

场景图：把动的和不动的拆开

核心想法一句话：一堆高斯没法同时表示「墙不动」和「车在动」，那就分成几堆。不动的那堆定义在世界系里，动的那堆定义在各自的规范空间（canonical space，可以理解成「以车自己为原点的坐标系」）里，每一帧再按这辆车当时的位姿搬到世界系。

DriveStudio 的场景图有四类高斯节点，外加三个不产生高斯的辅助模块：

1.1 最关键的一点：最后只有一次光栅化

这里非常容易想错，而且你踩过。四类节点不是各渲染一张图再叠起来的。它们各自把自己的高斯变换到世界系，然后被拼接成一个大数组，一次性丢进光栅化器：

# models/trainers/base.py · collect_gaussians()
for class_name in self.gaussian_classes:          # Background, RigidNodes, ...
    gs = self.models[class_name].get_gaussians(cam)  # 各自搬到世界系
    gs["class_labels"] = # 记下这批来自哪个节点
    ...
gs_dict[k] = torch.cat(v, dim=0)                     # 拼成一个数组

为什么这件事重要？因为只有拼在一起排序，深度关系才是对的。车挡住墙、墙挡住更远的车，这些遮挡是在同一次 alpha 合成里自然算出来的。如果分开渲染再叠加，你就得自己处理谁挡谁——那正是你八月做背景渲染缓存时遇到的问题：训练期两层 over-composite 不等于评测期的联合光栅化，硬切换在车和背景的接触带产生脏梯度，最后靠软混合 \(w_{\text{front}} = \sigma((d_{\text{bg}} - d_{\text{dyn}})/\tau)\) 才补回来。那个 bug 的根源就是绕过了这里的「一次光栅化」。

那 class_labels 是干嘛的？留给评测：只有在评测时，代码才会按标签做掩码，把每一类单独渲一遍，产出 Background_rgb、RigidNodes_rgb 这些分区结果。你在 images_test_*.json 里看到的 occupied_psnr 和 vehicle_psnr 就是从这儿来的。

刚体节点：车怎么动起来

一辆车的高斯存在它自己的规范空间里，坐标原点在车中心。这些参数不随时间变——车的形状就是车的形状。变的是每一帧把它搬到世界系的那个位姿：

\(v(p)\) 是「第 \(p\) 个高斯属于哪辆车」，代码里叫 point_ids。位姿参数是两个大张量，形状都是 (帧数, 车数, ...)：

注意这两个是可学参数，不是固定的标注。数据集给的跟踪框有噪声，直接拿来用会把误差烙进车的形状里，所以 Street Gaussians 的做法是把位姿也交给梯度下降。这也是为什么车节点是全场唯二配了学习率衰减的参数组（另一个是背景的 xyz，见第一课 §5.1）。

2.1 车不在画面里的时候怎么办

instances_fv（frame validity）记录每一帧每辆车是否出现。渲染时它直接乘进不透明度：

# models/nodes/rigid.py · get_gaussians()
valid_mask = self.get_pts_valid_mask()      # instances_fv[当前帧][每个点所属的车]
activated_opacities = self.get_opacity * valid_mask.float().unsqueeze(-1)

车没出现，它所有高斯的不透明度就是 0，完全不参与合成。这也意味着它们在这一帧收不到任何梯度——一辆只在前 30 帧出现的车，它的高斯只被 30 帧监督过。这是场景内部覆盖度差异的一个来源。

2.2 一个只在测试帧生效的开关

这条很隐蔽，但它直接影响你怎么读评测数字。位姿是逐帧的可学参数，而测试帧从来没被训练过——它们的位姿会一直停在跟踪器给的初值上，周围的训练帧却都被优化过了。这会在测试帧上凭空造出一个位姿跳变。

DriveStudio 的处理是：在测试帧上，不用该帧自己的位姿，而用前后两帧插值出来的。

# models/nodes/rigid.py · transform_means()
if self.in_test_set and 0 < self.cur_frame - 1 and self.cur_frame + 1 < self.num_frames:
    interpolated_trans = (instances_trans[t-1] + instances_trans[t+1]) * 0.5
    interpolated_quats = interpolate_quats(instances_quats[t-1], instances_quats[t+1])

平移取算术平均，旋转做四元数插值，而且只在前后两帧都有效时才用。所以在标准评测协议下，测试帧的车辆位姿是被邻居插出来的。这个协议在时间插值下很合理，但如果你要做的是留出整条相机的外推评测，这条路径就得重新想——第四课细说。

2.3 一个容易看错的细节：球谐算在世界系

车的高斯存在规范空间，但它的颜色是按世界系的观察方向算的：

world_means = self.transform_means(self._means)          # 先搬到世界系
viewdirs = world_means.detach() - cam.camtoworlds[..., :3, 3]
rgbs = spherical_harmonics(n, viewdirs, colors)           # 再按世界方向求值

意思是：同一个高斯，车头朝东和车头朝北的时候，即使你站在车的同一侧看，喂给球谐的方向也不一样。这不是 bug，是一个取舍——世界系球谐让模型可以把「车开到树荫下变暗」这种环境光变化吸收进颜色里。代价是车自身的高光不再跟着车走。Street Gaussians 原论文用的是另一条路：4D 球谐，把每个球谐系数换成一组傅里叶系数、按时间步反变换出来。知道有这回事——DriveStudio 的重实现没有包含 4D 球谐这一项，别把论文里的写法当成你手上代码的写法。

2.4 轨迹平滑正则

位姿可学就意味着它可能被光度损失带跑偏，比如一帧一抖。所以有一项二阶差分惩罚：

权重 0.01，每步随机抽一个间隔 \(k\)。读法：惩罚轨迹的「弯折」，但不惩罚匀速运动（匀速时二阶差分正好是零）。只对该帧和前后 \(k\) 帧都有效的车生效。

谁算「会动的车」

数据集给了所有车的标注框，但不是每个框都会变成一个刚体节点。判据在 datasets/driving_dataset.py 里，只有一句话：

# 只在这辆车出现的那些帧上算
valid_trans = instances_trans[frame_info]
traj_length = torch.norm(valid_trans[1:] - valid_trans[:-1], dim=-1).sum()
if traj_length > traj_length_thres:      # streetgs / omnire 都是 1.0 米
    new_instance_dict[k] = v              # 才给它开一个节点

翻译：把这辆车逐帧位移的长度加起来，超过 1 米才算「会动」。注意是累计弧长，不是首尾直线距离——所以一辆原地不动但跟踪框在抖的车，抖够 1 米也会被判成动的。KITTI 的默认阈值被专门调到 5.0 米，注释里写明就是为了滤掉这种噪声轨迹。

初始化：LiDAR 撒点

原版 3DGS 用 SfM 点云初始化。街景不行：路面和天空没纹理，SfM 在这些地方几乎给不出点，而这恰好是画面的大部分。好在驾驶数据自带 LiDAR。

streetgs.yaml 的背景初始化是三部分拼起来的：

两组随机点各自先按 3 倍数量采，再用 check_pts_visibility() 筛掉任何训练相机都看不见的，最后剩下的才留。far_randoms 的采样方式值得留意：在 \(1/r\) 上均匀而不是在 \(r\) 上均匀，等价于把大量点堆在近处、少量点撒到很远——这符合透视下「远处占的像素少」的事实。

最后一步是把落在动态车辆框内的点剔掉（filter_pts_in_boxes），免得同一块表面同时被背景和车节点表示。§3 说过，这一步只对通过了运动判据的车生效。

4.1 LiDAR 点的颜色是从图像投过来的

LiDAR 只给几何，不给颜色。所以初始化时要把点投影到图像上取色：

# datasets/driving_dataset.py · project_lidar_pts_on_images()
for cam in self.pixel_source.camera_data.values():     # ← 遍历所有相机
    for frame_idx in range(len(cam)):
        ...
        points_color = cam.images[frame_idx][v.long(), u.long()]
        self.lidar_source.colors[visible_indices] = points_color

顺带一提，这个函数还有个副作用：它同时把每个 LiDAR 点是否被任何相机看见记进 visible_masks，末尾 delete_invisible_pts() 会把没被看见的点整个删掉。所以留出相机同时还影响了哪些点会被保留，不只是颜色。

LiDAR 深度监督

光度损失在前向行驶下管不住深度——这是你整个 v3 方案的出发点，第一课 §3 那个雅可比也从解析上说明了原因。LiDAR 深度监督就是用来补这个洞的，虽然补得很轻。

做法：把每帧的 LiDAR 点投到图像上，命中哪个像素就在那个像素写下深度，其余全是 0：

depth_map = torch.zeros(cam.HEIGHT, cam.WIDTH)
depth_map[v.long(), u.long()] = depth        # 只有命中的像素有值

然后拿它跟渲染深度算 L1。渲染深度用的是「期望深度」，也就是 gsplat 的 render_mode="RGB+ED"：

注意分母是不透明度 \(O\)，不是 1。所以它是沿这条光线的加权平均深度，不是累积深度。半透明的区域也能给出一个有意义的深度值。

损失本身很朴素，配置全在 losses.depth：

天空、曝光、相机位姿

三个不产生高斯、但每一项都在影响你读到的数字的模块。

6.1 天空：一张可优化的环境立方体贴图

天空在无穷远，用高斯表示会退化。DriveStudio 用一张立方体贴图：六个面、每面 1024×1024、每像素 RGB，全部初始化为 0.5，学习率 0.01。查表方式是拿每个像素的观察方向去采样：

# models/modules.py · EnvLight.forward()
l = image_infos["viewdirs"] @ self.to_opengl.T
light = dr.texture(self.base[None], l, filter_mode='linear', boundary_mode='cube')

合成方式就是第一课讲过的那条：\(C = C_{\mathcal G} + (1-O)\,C_{\text{sky}}\)。高斯没盖住的地方漏出天空。

另外有一项掩码损失把这件事钉住：渲染出的不透明度 \(O\) 要跟数据集给的「非天空掩码」对齐，用二元交叉熵，权重 0.05。它在两个方向上都起作用——不让高斯长到天上去，也不让本该实心的地方漏出天空。

6.2 曝光：逐图像的仿射色彩变换

这一节你要格外仔细看，因为它是你外推评测里最大的一个混淆项。

六个相机的自动曝光各跑各的，同一面墙在不同相机、不同时刻拍出来亮度就是不一样。如果不管，模型只能把这个差异编进几何或颜色里。DriveStudio 的做法是给每一张图配一个 4 维嵌入，过一个两层 MLP 输出 12 个数，reshape 成 3×4 的仿射矩阵：

整个模块零初始化，所以训练一开始它就是恒等变换，只学偏离恒等的那部分。这也是为什么还有一项 affine 正则（权重 1e−5）把它往恒等拉。

注意 §1 图里的顺序：仿射是作用在已经合成完天空之后的图上的。

outputs["rgb"] = self.affine_transformation(
    outputs["rgb_gaussians"] + outputs["rgb_sky"] * (1.0 - outputs["opacity"]), image_infos
)

现在是关键的那一句。测试时怎么办？测试图没有训练过的嵌入。代码的选择是用所有训练图嵌入的平均值：

# models/modules.py · AffineTransform.forward()
if "img_idx" in image_infos and not self.in_test_set:
    embedding = self.embedding(image_infos["img_idx"])
else:
    # use mean appearance embedding
    embedding = ones(...) * self.embedding.weight.mean(dim=0)

所以测试帧拿到的是一个「平均曝光」，而不是它自己该有的曝光。这中间的残差全部计入 PSNR，跟你的重建质量没有任何关系。P2GS 那条教训——评测前必须对每帧后拟合一个全局仿射——说的就是这件事。下面这台仪器把这个代价量出来：

6.3 相机位姿也是参数

标定和里程计给的位姿有误差，几毫米的偏差在 30 米外就是好几个像素。CameraOptModule 给每张图学 9 个数：3 个平移增量 + 6D 表示的旋转增量，零初始化，学习率 1e−5、权重衰减 1e−6。

这里同样有个评测上的坑：渲染新视角时这个模块要被旁路掉。代码里 forward() 有个 novel_view 开关就是干这个的——新视角没有对应的图像索引，也就没有它的位姿修正量。

训练集和测试集怎么切

这一节短，但它是第四课的引子，也是你整个课题争论的起点。

# datasets/driving_dataset.py · split_train_test()
test_timesteps = np.arange(test_image_stride, num_img_timesteps, test_image_stride)
train_timesteps = [i for i in range(num_img_timesteps) if i not in test_timesteps]

关键是它切的是 timestep（时间步），不是单张图片。一个时间步被划进测试集，这一刻所有相机的图都进测试集。

拿你的基线配置算一遍：150 帧、3 相机、test_image_stride=10：

408 这个数你应该眼熟——你八月做背景渲染缓存时缓存的就是这 408 个训练视角。

逐行读 streetgs.yaml

到这里 streetgs.yaml 里已经没有你不认识的段落了。整理成一张表收尾：

回到你自己的实验

这一课里有四条直接落在你手上的实验里。

为什么八个示例场景里有四个的车完全没动

因为 traj_length_thres = 1.0 把它们全滤掉了，它们的 LiDAR 点留在了背景里。你 09-02 那晚的 scan_motion.py 测到的就是这件事。后果是：你八月关于「动态节点」的那批结论，有一半跑在根本没有动态节点的场景上，包括 vehicle_psnr 那一列。新筛的场景 21（100 米）和 22（196 米）才是真正有动态内容的。

为什么背景渲染缓存会掉分，靠软合成才补回来

因为 §1.1：正常路径是所有节点拼成一个数组做一次光栅化，遮挡关系在同一次 alpha 合成里自然解决。缓存背景等于把它拆成两层事后叠加，接触带的硬切换 \(\mathbb{1}[d_{\text{dyn}} \le d_{\text{bg}}]\) 会产生脏梯度。你换成软混合是对症的，但根子上这是一个「绕过了联合光栅化」的代价。

为什么留出相机的未观测区数字要打折扣

§4.1。LiDAR 上色遍历所有相机，留出相机的像素颜色照样漏进初始化点云，而且还影响了哪些点会被保留。这就是你 09-03 早上记下的待办①。

为什么深度权重开到 10 倍几乎没反应

§5。被监督的像素本来就只是稀疏扫描线，权重又只有 0.01，而且是全局统一的标量。放大十倍仍然是均匀地放大，没有把信息送到最需要它的方向上。你 v3 的 M2（按相机 Fisher 的最弱方向加权 LiDAR）针对的正是这个结构性缺陷，而不是权重大小。

❧

自查清单

• 说出场景图的四类高斯节点，以及它们最后是怎么进入光栅化的。
• 写出刚体节点从规范空间到世界系的变换公式，说明 point_ids 的作用。
• 说出「会动的车」的判据是什么，不达标的车去了哪里。
• 说出测试帧上车辆位姿是怎么来的。
• 说出曝光仿射是逐什么的，测试时用什么值，为什么评测前要后拟合。
• 说出标准协议切的是时间步还是图片，以及这意味着测的是插值还是外推。

场景图 scene graph

把场景拆成若干节点，每个节点有自己的坐标系和随时间变化的位姿。渲染时统一变换到世界系。

规范空间 canonical space

物体自己的坐标系，原点在物体中心。物体的高斯参数存在这里，不随时间变。

刚体节点 rigid node

形状不变、只做整体平移旋转的节点，用来表示车辆。

帧有效性 frame validity

instances_fv，记录每一帧每个实例在不在场。不在场时它的高斯不透明度被乘 0。

期望深度 expected depth

\(\sum_i w_i z_i / \sum_i w_i\)，沿光线的加权平均深度。gsplat 的 ED 模式。

环境立方体贴图 environment cube map

六个面的纹理，按观察方向查表得到天空颜色。这里是可优化参数，不是固定贴图。

曝光仿射 affine appearance transform

逐图像的 3×4 色彩变换，用来吸收相机自动曝光造成的亮度差异。测试时退化为所有训练图嵌入的平均。

累计弧长 trajectory arc length

逐帧位移长度之和。判断一个实例是否「会动」的依据，注意它不等于首尾直线距离。