2.3 网格体素与多面表示

2.3 网格体素与多面表示

本节摘要：三维信息的四大记录簿——点云、深度图、体素、三角网格——各有表达力与成本曲线。本节梳理它们之间的转换路线与信息损耗，为第四章成图选路。

踏勘最后一站定记录格式。点云是最原始的"碎碎念"，成图交付需要更规整的载体：网格适合渲染与打印，体素适合机器学习输入，深度图适合实时流水线。四者之间的转换不是无损的，选错路线会在第四章付出代价。

四种记录簿的分工

点云：最接近传感器原生输出，表达自由曲面无参数化偏见，但没有表面连接关系，渲染要靠 splat。
深度图：图像形态的深度，保留有序网格，邻域查询零成本，是实时 SLAM 的中间货币；缺点是单视角、有遮挡空洞。
体素栅格：三维像素阵列，卷积网络可以直接吃，规则性好；缺点是内存随分辨率三次方暴涨—— voxels at 512 cubed exceed memory of most GPUs（以中文记：五一二立方的布尔体素就要一点三四亿格）。
三角网格：顶点加三角面片，显卡的原生语言，渲染、打印、几何计算的工业标准；缺点是拓扑维护复杂，动态变形困难。

内存账本：体素分辨率的指数陷阱

体素的成本随分辨率三次方增长，这是它在高精度场景让工程师却步的根本原因。算一笔账：边长十米的场景，五厘米体素需要每轴两百格，共八百万格布尔位，压缩后勉强可存；分辨率提到一厘米，格子数暴涨一百二十五倍。点云没有这个惩罚——点只落在表面上，表面是二维流形，规模近似平方增长。神经辐射场等方法走红的技术背景，正是绕开显式体素的这种三次方诅咒。

# 体素内存账本（numpy 模拟）
for res in [100, 200, 400, 800]:
    grid = np.zeros((res, res, res), dtype=bool)   # 布尔体素
    mb = grid.nbytes / 1024 / 1024
    print(f'分辨率 {res}^3: {mb:8.1f} MB, 格子数 {res**3:,}')
# 输出:
# 分辨率 100^3:      1.0 MB, 格子数 1,000,000
# 分辨率 200^3:      7.6 MB, 格子数 8,000,000
# 分辨率 400^3:     61.0 MB, 格子数 64,000,000
# 分辨率 800^3:    488.3 MB, 格子数 512,000,000
​

分辨率翻倍，内存翻八倍。若改用八叉树只存表面层，稀疏场景可省下一个数量级——上一节的结构优势在这里兑现。

转换路线与信息损耗

四条常用路线要心里有账：深度图与点云互转基本无损（第一章的反投影代码）；点云到体素是有损压缩，细节被分辨率封顶；点云到网格是第四章表面重建的主战场，法向质量决定成败；体素到网格走经典的 Marching Cubes 等值面提取，损失由体素分辨率决定。

⚠️ 常见坑：管线一上来就把点云转成网格再处理。网格的拓扑一旦错了（法向朝内、面片翻转），后面的滤波配准全都失真。纪律是：处理阶段保持点云，交付阶段才成网格。

💡 关键直觉：点云记录"哪里有东西"，体素记录"每个格子有没有东西"，网格记录"表面在哪里、怎么连"。同一座山的三张地图，服务不同的下游。

实战演练：一次有损往返

背景：验证"体素化封顶细节"不是空话。操作：把兔子点云体素化再转回点云，对比点数与包围盒。

pcd = o3d.geometry.PointCloud()
pcd.points = o3d.utility.Vector3dVector(np.asarray(o3d.data.BunnyMesh().vertices))
print('原始点数:', len(pcd.points))                 # 输出: 原始点数: 35947
for vox in [0.01, 0.005]:
    down = pcd.voxel_down_sample(vox)
    print(f'体素 {vox*1000:.0f} 毫米 -> 点数 {len(down.points)}')
# 输出:
# 体素 10 毫米 -> 点数 3427     # 细节大量合并
# 体素 5 毫米 -> 点数 10652    # 保留约三成
​

结果解读：体素化是"每个格子留一个代表点"的有损压缩，十毫米粒度下点数只剩不到一成，微小起伏被抹平；但点云整体形状与法向趋势仍然可辨——这正是第三章下采样预处理的合理性来源。变式：先体素化再配准是标准套路，点数降一个量级、配准速度升数倍，精度损失通常可忽略。

表示选择的三个追问

追问一：下游要渲染还是计算？ 渲染与三维打印直接用网格；碰撞检测与规划用体素或占据八叉树；深度学习模型输入看架构——点云网络吃点，体素网络吃栅格，两者都有的混合架构正在成为主流。

追问二：数据要压缩归档还是实时处理？ 归档优先八叉树压缩，稀疏场景能把存储压下一个数量级；实时处理优先保持深度图形态，网格化这种重活留到交付阶段。

追问三：场景会不会动态变化？ 会变的场景避免早期转网格——网格的拓扑更新代价高，点云与体素的增量更新便宜得多。这也是第五章在线建图全部选择点云或栅格载体的根本原因：地图是活物，载体必须长得动。

三个追问答完，表示方案基本就定了。表示层的决策影响深远，值得在管线设计之初多花半小时，省掉后期整个模块的重写。再补一个容易被忽略的细节：转换的实现要保留可追溯性——体素化时记下分辨率、点转网格时保留原始点云的索引映射，这样下游发现网格有洞或翻转面时，能顺着索引回到原始点云排查，而不是对着一张"孤儿网格"无从下手。团队协作里，这条约定比任何算法技巧都更常救命。顺带一提，四种表示在文件格式层面也有亲疏：点云通用格式是 PLY 与 PCD，网格是 PLY 与 OBJ，体素很少直接落盘（通常即用即建），深度图就存图像格式——交换数据时先确认对方要的是哪一种记录簿，格式转换虽小，搞错一次就要重跑半天管线。

本节要点回顾

• 四大表示各有分工：点云采集、深度图实时、体素学习、网格交付；
• 体素内存随分辨率三次方暴涨，稀疏结构是对冲手段；
• 转换有损原则：生产管线尽量晚做有损转换，处理期保持点云；
• 体素下采样是兼顾速度与精度的标准预处理；
• 第四章的表面重建与第五章的占据建图，分别消费网格与体素两种载体。

踏勘结束，毛料入库。下一章进入外业整理：把带噪、重叠、杂乱的点云洗成能用的整体。