尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

三维点云语义分割:从PointNet到Transformer的完整技术路线与实战指南

三维点云语义分割:从PointNet到Transformer的完整技术路线与实战指南 第一次接触三维点云语义分割时我最大的感受是前两年还在二维图像里做分割换到三维数据后连最基本的“相邻关系”都不成立。当时团队要做一个道路沿线的自动标注项目目标是给行人和护栏打标签二维分割结果一帧一帧重投影到激光点云上经常错位最后被逼着直接对点云做逐点分类。从那以后我才把三维点云语义分割当成正经事来研究。简单说点云语义分割就是在三维空间中把成千上万个离散点逐个判断它属于哪个类比如地面、车辆、行人、建筑、植被。听起来不复杂但它几乎是所有三维场景理解任务的地基。往下可以支撑自动驾驶感知决策往上可以服务三维重建、数字孪生、智慧城市和机器人操作。二维语义分割领域已经有DeepLabV3这类成熟网络可一旦换到三维数据从规则网格变成无序点集很多图像上的经验都得推翻重写。这篇文章我会完整梳理三维点云语义分割的概念边界、主流数据集和评价指标、四类方法路线最后给出一套最小可复现的实验流程和排坑清单。适合刚入门三维视觉的研究生也适合准备把点云分割用到实际项目的工程师。1. 点云语义分割在解决什么问题和2D图像分割差在哪1.1 数据形态差异从规则网格到无序点集要理解点云语义分割得先明白点云和图像的底层差异。二维图像是一个规则网格每个像素有固定坐标像素之间的邻域关系天然存在你用卷积核滑动窗口本质上是在利用这个规则的网格结构。三维点云完全不同它是一堆在空间中自由分布的坐标点点与点之间没有固定间距同一个物体在不同距离下扫描点密度可能差好几倍远处一堵墙可能只有几十个点近处一辆车可能有好几万个点。这种无序、稀疏、密度不均的特性直接导致卷积神经网络那一套不能照搬。你没法定义一个规则窗口去滑动除非先把点云转换成规则结构。所以“点云怎么喂给网络”本身就是这个领域的核心命题之一。除了无序性点云还没有拓扑关系。你不知道哪些点属于同一根柱子、同一个窗户必须靠算法去“猜测”点与点之间的关联。这就是为什么PointNet这类模型要特意设计对称函数来聚合全局特征也是为什么下图里的很多分割结果比二维分割更容易出现碎片化噪声。对比来看维度二维图像三维点云数据结构H x W 规则网格N x 3 无序坐标集合邻域关系像素相邻天然定义需要KNN或半径搜索密度均匀随距离/遮挡剧烈变化语义信息颜色、纹理、边缘几何结构、法线、高程卷积方式2D卷积直接可用需投影/体素化/特殊算子做项目时还有一个很直观的体感二维图像分割的“错”通常是边缘不整齐点云分割的“错”往往是把一个完整物体切得稀碎或者把两类几何特征接近的东西混在一起。原因就在于点云没有纹理信息可参考只能靠几何结构判断。1.2 任务边界语义分割、实例分割、全景分割别搞混很多刚接触“点云分割”的人会把几类任务混在一起说实际上这是三件事。语义分割是最基础的给每个点分配一个类别标签比如“这堆点全部是车辆”。难点在于类别判断不区分同一类里的不同物体。实例分割要在语义分割基础上进一步区分“这是第1辆车、第2辆车、第3辆车”需要做聚类或预测实例中心。全景分割则是语义分割实例分割的合体对“stuff”类别如地面、墙面做语义分割对“thing”类别如行人、车做实例分割最终给每个点输出类别实例编号。任务输出粒度典型难度常见思路语义分割每个点一个类别类别特征区分PointNet、稀疏卷积实例分割每个点类别实例ID同一类物体粘连聚类语义分支、Embeding学习全景分割类别实例/区域归属类别与实例混合语义实例双分支联合实际项目里这三个任务经常被统称“点云分割”但选型差别巨大。语义分割可以直接用分类网络加逐点预测头实例分割往往需要先做语义分割再用聚类算法如DBSCAN把同类别点分开或者训练一个“点嵌入”让同一实例的点在特征空间里靠在一起。做自动驾驶相关需求时特别容易被“分割”这个词绕晕。车道线扫描出来的点云要分的是“可行驶区域、路沿、护栏”这是语义分割远光灯下要数清前面有几辆车这是实例分割。明确任务边界能帮你少走至少一半弯路。1.3 高价值应用场景与相邻任务点云语义分割的应用场景比想象中广远不止自动驾驶。自动驾驶是最常见的落地场景。激光雷达点云分割出地面、车辆、行人、骑行者等类别后续决策模块才敢放心规划路径。还有团队会直接把语义分割结果叠加到动态点云地图上让地图里包含“车道线、路沿、交通标识”等结构化信息便于后续配准和定位。三维GIS和数字孪生是另一个大方向。智慧城市项目里航拍或车载激光扫描得到的城市点云需要自动分出建筑、植被、路灯、地面等类别然后再把每类点云单独建模、切片。现在很多GIS平台都在做“二三维联动”二维地图叠加三维分割结果用于电力巡线、城管部件管理、园林普查等工作。机器人操作场景也很典型。机械臂抓取之前需要先分清桌面、目标物体、背景墙体点云语义分割能提供位置和边界再配合位姿估计实现抓取。和语义分割经常一起出现的相邻任务是三维目标检测。简单理解目标检测是“定位分类”输出一个3D包围框语义分割是“逐点分类”输出每个点的类别。两者互补很多方案会共享一个backbone一个头做检测一个头做分割。另一个相关的任务是地形点云配准多帧扫描点云要先对齐分割结果才能叠加和差分分析工业三维测量领域也常把扫描结构件做语义分类后用于逆向建模。2. 绕不开的数据集、评价指标与标注细节2.1 常用的三类场景数据集选数据集基本决定了你的模型能在什么场景下工作。点云语义分割领域目前没有“放之四海而皆准”的通用数据集主流数据集按场景大致分三类自动驾驶道路场景、室内场景、大型户外静态场景。自动驾驶场景用得最多的是SemanticKITTI和nuScenes。SemanticKITTI基于KITTI视觉数据集用64线激光雷达采集包含21个训练序列28个类别覆盖城市道路、住宅区、高速公路等场景还有逐帧标注。nuScenes则提供了1000个场景传感器套件更全包含6个摄像头、5个毫米波雷达和1个32线激光雷达类别数量约23个。室内场景的主流选择是ScanNet和S3DIS。ScanNet v2包含1513个室内扫描覆盖办公室、卧室、卫生间等场景标注了20个常见类别加背景S3DIS来自斯坦福包含6个区域的271个房间13个类别是很多论文里对比时必跑的数据集。这些室内数据集点云密度高、物体种类丰富适合做算法研究。大型户外静态场景的代表是Semantic3D用地面激光扫描仪采集场景主要是广场、教堂、街道等数据量能达到数亿级点云类别有8类包括地面、建筑、植被、电线杆等。这类数据集的难点是规模大、类别极不平衡很适合测试模型的工程化能力。数据集场景传感器类别数是否有时序SemanticKITTI户外道路64线激光雷达28有nuScenes户外道路多传感器融合23有ScanNet室内RGB-D深度相机20背景有连续扫描S3DIS室内结构光/Matterport13无Semantic3D户外静态大场景地面激光扫描仪8无一个建议如果你想快速验证算法可行性先跑室内ScanNet或S3DIS数据量适中类别均衡一些如果你最终目标是自动驾驶直接跑SemanticKITTI但要做好类别不平衡和点云规模大的心理准备。2.2 mIoU和OA怎么选结果才靠谱评价指标是很多人忽略、但实际特别关键的一环。点云语义分割最常用的指标有三个OA、mIoU和mAcc。OA是整体准确率就是分类正确的点数占总点数的比例。看起来直观但在类别不平衡时特别坑。比如户外场景里地面和植被占了80%的点你只要把这两类全分对OA就能到80%以上但车辆、行人、电线杆这类小目标全错也看不出来。mIoU是平均交并比逐类别计算预测结果和真值之间的IoU再对所有类别取平均。它对每个类别的表现“一视同仁”不会因为某个类点少就被稀释掉。所以论文和竞赛里基本都以mIoU为主要指标。mAcc是平均类别准确率逐类别算分类准确率再取平均和mIoU类似但比mIoU更宽松一些因为它不惩罚多预测出来的假阳性点。举一个直观例子。假设场景只有三类地面、建筑、植被某模型预测结果里地面IoU0.78建筑IoU0.62植被IoU0.55那么mIoU(0.780.620.55)/30.65。如果你只看OA可能这个模型有0.82的OA但类别间差距被掩盖了。实际看论文时建议你同时看mIoU和OA两个指标。有些方法mIoU很高但OA偏低说明模型在小类别上做得好但整体稳定输出差一点mIoU和OA都高才是真正可靠。另外还要留意数据集的具体类别划分不同论文的类别集合可能不一样直接横比mIoU数字没有意义。2.3 点云格式、坐标变换与数据集制作流程想上手实操先得搞懂点云文件长什么样。最常用的格式是PCD、PLY、TXT和LAS。PCD是PCL库的官方格式头部会记录点数、字段类型、宽度高度PLY既支持ASCII也支持二进制还支持顶点颜色TXT通常是一行一个点每行存x y z r g b label简单直接但占用空间大LAS是LiDAR数据通用格式常用于测绘和GIS领域。查看PCD或PLY文件推荐CloudCompare免费开源加载百万级点云也不卡。它还能做点云转三维模型的前期处理比如裁剪、降采样、法线计算和Mesh重建很多项目组拿它当数据标注和预览工具。PCL本身也自带pcl_viewer命令适合快速查看。自己写工具的话Python里用Open3D一行就能读进来。点云的坐标变换也是绕不开的。激光雷达扫描得到的点云通常位于传感器坐标系多帧拼接要转到世界坐标系这会涉及旋转矩阵和欧拉角。比如绕Z轴旋转θ的旋转矩阵R [[cosθ, -sinθ, 0], [sinθ, cosθ, 0], [0, 0, 1]]三维坐标变换公式为 P R * P t。看到这里别紧张日常实验里你只要知道欧拉角是按一定顺序绕X、Y、Z轴旋转旋转矩阵负责把点云的朝向对齐平移矩阵负责位置对齐。很多人一搜“旋转矩阵欧拉角公式表如何表达三维坐标”就被绕晕实际使用中直接用现成库就行PCL的Eigen模块、Open3D的get_rotation_matrix_from_xyz都能帮你算不需要手推。如果你需要自己制作语义分割数据集流程大致是用扫描设备采集点云或者从开源数据里导出原始PCD/PLY。用CloudCompare打开先做裁剪和降采样去掉无关区域。对每个点或区域打类别标签CloudCompare可以按标签标色方便检查。将标签导出成TXT或PLY保持x y z r g b label的格式。划分训练集、验证集、测试集注意避免同一区域的数据同时出现在训练和验证集里。标注是公认的耗时环节。一个10万点的房间人工逐点标注可能要一个下午。实际项目中可以先用预训练模型做一轮自动分割人工只修正错误区域效率会高很多。这也算是“用模型标数据再用数据训模型”的半自动化闭环。3. 方法总结从PointNet到Transformer的四条路线现在进入重头戏方法总结。点云语义分割的方法论大致可以分成四条路线选型时不用贪多理解每一条的核心思路和适用场景就行。3.1 基于原始点的PointNet/PointNet路线这条路线直接对原始点云坐标做处理不对数据进行投影或体素化代表工作就是PointNet和PointNet。PointNet的核心思想是解决点云的无序性。它用共享MLP对每个点做特征提取然后用最大池化把所有点的特征聚合成一个全局特征最后再逐点判断类别。最大池化就是一种对称函数不管点云顺序怎么打乱输出都一样这一点保证了网络对点序不敏感。当年的T-Net还要额外学习一个空间变换矩阵让网络在输入和特征层面都具备旋转鲁棒性这个设计后来也沿用到了很多空间变换网络里。PointNet的问题很明显它对每个点是单独处理的感受野只有全局池化带来的那一点“整体意识”缺少局部几何结构的建模能力。一堵墙和一本书在局部区域可能看起来很像单靠全局特征很难分清楚。PointNet针对这个问题做了改进思路是“分层抽象”先对点云做最远点采样选出一些中心点每个中心点周围划一个局部区域用局部MLP提取特征然后逐层扩大感受野类似图像里的卷积层堆叠。这个设计叫多尺度局部聚合让网络既能看局部细节又能看整体结构。这代方法的优点是原理清楚、部署简单在小规模数据上效果不错ScanNet这种室内场景基本是PointNet的turn场。缺点是每层都要做邻域搜索点云规模大了以后计算量增长非常快SemanticKITTI这种几十万点的大场景要控制采样点数。3.2 体素化路线与稀疏三维卷积体素化是最直观的思路把三维空间切成一格一格的小立方体每个格子里的点取平均或者做统计这样就得到了一个规则的三维网格可以直接用三维卷积去处理。听起来很完美但算力开销是灾难级的。假设一个房间10米x10米x3米如果体素大小是0.05米那么网格是200x200x60总共240万个格子。用普通三维卷积对每个格子都做计算显存直接爆炸。所以早期体素方法只能用在很小的场景或很粗糙的体素分辨率上。真正让体素化路线重新流行的是稀疏卷积。体素化后你会发现绝大多数格子是空的只有被点云占用的格子才有值那为什么不只对占用格子做卷积呢稀疏卷积正是这个思路。它用一个哈希表记录非空格子只对这些格子做特征传播和聚合计算量只和点云实际分布有关和场景大小无关。MinkowskiEngine、TorchSparse这些库都实现了高效稀疏卷积。这代方法的优点非常明显卷积操作在规则格网上做理论扎实工程上对大规模户外点云特别友好SemanticKITTI榜单上长期占据靠前位置的方法几乎都是稀疏卷积或混合方案。缺点则是体素大小需要人工设置太小会增加格子数量和显存太大会丢失几何细节。另外多个点落进同一格子时会损失局部精度边界比较粗糙。如果你要处理的是自动驾驶点云我建议优先考虑体素化稀疏卷积这是目前工程可行性最高的一条路线。3.3 投影法路线借助2D语义分割网络处理雷达距离图投影法听起来有点“绕”既然三维直接算很难那我把点云投影到二维平面用现成的2D语义分割网络来处理处理完再映射回三维。最常见的投影方式有两种前视图投影和Range View投影。前视图投影就是把三维点云像拍照一样投影到正前方平面适合单帧窄视场的点云Range View是球形投影模拟激光雷达扫描的方式把每个点映射到一个二维距离图上横轴是水平角度纵轴是垂直角度像素值是该点的距离或反射强度。Range View方案在自动驾驶里非常流行。因为64线激光雷达本身扫出来的就是一个有序的距离图像直接把这个图像输入给DeepLabV3这类成熟2D分割网络等于把2D语义分割的所有经验全部迁移过来预训练权重现成、训练速度快、推理也快。SqueezeSeg、RangeNet就是这类方法的代表早期的RangeNet在SemanticKITTI上效果一度不错。投影法的硬伤在于信息损失。投影过程必然会产生遮挡一个像素只能保留最近的一个点的信息多个物体在投影后重叠远端的点就会被遮掉后面的分割就要靠猜。此外把3D分割结果映射回原始点云时边界会出现锯齿和空洞。所以投影法适合对速度要求高、对精度要求相对宽松的场景比如实时嵌入式设备上的初筛。但如果你做的是高精标注或复杂城市场景单靠投影法大概率不够。3.4 Transformer与自监督预训练方向Transformer进入三维点云领域是比较近的事。点云本身是无序点集而Transformer的自注意力机制天然不依赖顺序所以并不违和。Point Transformer、Point Transformer V2、Point-MAE等一系列工作直接把注意力计算套到点云上让每个点根据全局上下文去聚合信息。这类方法的优势是感受野极大能捕捉长距离依赖。举个例子一根电线杆在点云里可能只占很小区域但“线路走向”这个上下文分布在几十米外普通局部卷积根本摸不到注意力机制却可以跨越空间去关联。Point Transformer在S3DIS和ScanNet上的mIoU普遍比PointNet高3到5个点差距还是很明显的。代价是计算量和显存开销非常夸张。全局注意力对N个点要计算N x N的注意力矩阵百万级点云根本扛不住所以实际使用时会加窗限制注意力范围或者先用稀疏卷积做降采样再在高层特征上做Transformer。另外值得一提的还有自监督预训练方向。三维数据标注太贵很多团队在尝试用无标注点云做掩码自重建预训练思路类似语言模型里的掩码预测随机遮掉一些点让网络根据上下文预测被遮掉的几何结构训练完再去下游语义分割任务上微调。Point-BERT、Point-MAE是这类方法的代表。虽然目前自监督带来的收益在不同数据集上还不稳定但这确实是降本增效的潜力方向。3.5 方法横向对比方法路线代表模型输入形式核心优势主要短板适用场景原始点法PointNet、PointNet、DGCNN原始坐标法线结构清晰、容易调试大数据量时邻域搜索慢小规模室内点云体素法SparseConvNet、MinkowskiNet体素网格规模可扩展、适合大场景体素大小需调试、细节有损户外道路、大场景投影法RangeNet、SqueezeSegV2距离图/前视图可复用2D网络、推理快信息损失、边界锯齿实时自动驾驶TransformerPoint Transformer、Point-MAE原始点特征序列全局上下文、精度上限高显存开销大、训练慢精度要求高的离线分析需要说明的是这些路线的mIoU比较不能脱离数据集。SemanticKITTI上优秀模型mIoU大约在65-70之间ScanNet上能达到70S3DIS上75但这些都是特定设定下的结果参考意义大于绝对比较。4. 最小可复现实验从一段PLY点到一张分割结果理论讲再多不如跑一次赛跑。下面给你一套最小可复现的实验流程数据随便找一段PLY点云目标就是训练一个能对逐点类别做预测的模型。4.1 工具链怎么配各干各的活我的习惯是Python为主、C为辅。Python负责数据加载、模型定义、训练推理C和PCL负责后续工程化和性能优化。如果你不是要部署到嵌入式设备完全可以用Python打通整个流程。具体工具分工如下Open3D负责点云读写、可视化和简单预处理。加载PLY/PCD一行代码显示点云也很快适合原型验证。PyTorch训练语义分割网络动态图和自动微分让调试成本低很多。PCL如果想做更底层的点滤波、配准、法线估计、体素网格构建PCL是最全的库。虽然C写起来繁琐但接口丰富很多复杂算法不用自己实现。很多入门资料都推荐《点云库PCL从入门到精通》的PDF我的建议是别只收藏PDF动手装一次PCL、跑通官方example比看十遍书都管用。CloudCompare数据查看、人工标注、Mesh构建特别是点云转三维模型的前处理经常用。ROS/Rviz如果你在自动驾驶或机器人团队Rviz可视化点云是最顺手的工具PCL点云消息直接订阅显示。环境安装没什么好说的用conda建一个Python 3.9环境然后pip install open3d torch numpy就行。PCL如果是纯用Python调试可以先用open3d替代正式工程化再编译C版PCL。4.2 预处理与坐标标准化可能比网络结构更重要很多人一上来就搭模型结果训练出来分割结果很惨最后排查发现是预处理出了问题。点云预处理里我认为有四步是必做的降采样、去离群点、法线计算、坐标标准化。降采样通常用体素下采样Open3D一行代码import open3d as o3d import numpy as np pcd o3d.io.read_point_cloud(scene.ply) pcd pcd.voxel_down_sample(voxel_size0.02) # 统计离群点去除 pcd, _ pcd.remove_statistical_outlier(nb_neighbors20, std_ratio2.0) # 坐标标准化移到质心缩放到[-1, 1] xyz np.asarray(pcd.points) centroid xyz.mean(axis0) xyz xyz - centroid scale np.abs(xyz).max() xyz xyz / scale # 计算法线后面作为输入特征 pcd.estimate_normals(search_paramo3d.geometry.KDTreeSearchParamHybrid(radius0.05, max_nn30)) normals np.asarray(pcd.normals)体素大小0.02米适合室内小场景如果是户外道路点云可以放宽到0.1-0.2米。统计离群点去除的参数nb_neighbors和std_ratio需要根据点密度调节std_ratio设2.0通常能去掉大部分飞点。坐标标准化特别容易被忽略。不同扫描仪得到的点云尺度差异很大有的点坐标是米有的是毫米如果不缩放到统一尺度网络训练会极不稳定。我见过一组实验只做了坐标标准化mIoU就涨了4个点。旋转矩阵和欧拉角在这时候也要注意如果你的数据集是多个传感器拼接的每个点云的朝向不统一训练前应该先做一次粗略对齐。虽然很多网络声称有旋转鲁棒性但实际效果远不如你把数据强行转到统一朝向来得稳。4.3 模型选择、训练超参与Loss设置最小实验里我不会第一时间上稀疏卷积或Transformer先用PointNet或DGCNN这种轻量模型打通流程。这类模型代码短、调试容易能快速判断数据是否正常。关键超参数可以这样设置参数推荐值说明每帧采样点数16384太大显存不够太小丢细节Batch Size8根据显存调整优化器AdamW比SGD收敛稳初始学习率1e-3配合余弦衰减Epochs100-150小规模数据集够用输入特征xyz 法线比纯xyz高几个点损失函数CrossEntropy 类别权重必须处理类别不平衡Loss设置是重点。点云语义分割的类别不平衡问题比图像分割更严重户外场景里“道路”可能占了一半点“行人”连1%都不到。直接拿CrossEntropy训练模型会倾向于把所有点预测成大类。解决方法是给损失函数加类别权重权重与类别点数量的倒数成正比。# 计算每个类别的权重按点数量反比 counts np.bincount(all_labels, minlengthnum_classes) weights 1.0 / (counts 1e-6) # 归一化权重 weights weights / weights.sum() * num_classes criterion nn.CrossEntropyLoss(weighttorch.tensor(weights, dtypetorch.float32).cuda())训练循环本身不复杂model.train() for xyz, labels in dataloader: xyz xyz.cuda() labels labels.cuda() optimizer.zero_grad() logits model(xyz) # (B, num_classes, N) loss criterion(logits, labels) loss.backward() optimizer.step()要注意的是每个epoch用到的点必须是随机采样的不能每次都拿同一批16384个点。因为一个场景可能有几十万点每次只采样一部分如果固定采样点模型只见过局部信息。可以在每次epoch前重新随机采样。4.4 可视化推理和结果诊断训练完一定要可视化验证不能只看loss数字。我习惯在验证集上跑几次推理把预测结果存成带颜色的PLY用CloudCompare打开和Ground Truth做并排对比。具体做法就是把每个点的预测类别映射成RGB然后保存colors np.zeros_like(xyz) for cls in range(num_classes): mask pred cls colors[mask] np.array(class_color_map[cls]) / 255.0 pcd_pred o3d.geometry.PointCloud() pcd_pred.points o3d.utility.Vector3dVector(xyz) pcd_pred.colors o3d.utility.Vector3dVector(colors) o3d.io.write_point_cloud(pred_result.ply, pcd_pred)如果你用的是机器人或自动驾驶系统RViz可视化点云也很方便发布一个PointCloud2消息、一个Color消息订阅端直接叠加显示。诊断阶段我会做两件事。第一件是输出混淆矩阵看模型到底把哪两类搞混了。常见的规律是“路灯误分为树干”“矮墙误分为路沿”因为它们在局部几何上确实接近。第二件是逐点可视化错误样本把预测错误但是置信度高的点单独标红往往能发现标注噪声问题。很多所谓“分割不准”其实是标注本身有错误模型学得比标签还准。如果你处理的是多帧时序数据还得考虑点云配准。不同帧的点云如果没对齐直接分割再叠加结果会出现重影和错位。雷达扫描时序数据通常先做ICP或NDT配准再进入分割流程。地形点云配准是典型场景地面特征少、重复结构多ICP容易陷入局部最优建议用NDT先粗对齐、ICP再精对齐的组合。4.5 工程化落地与三维GIS扩展实验能跑了下一步就是工程化落地。这里说几个常见落地方向以及各自的坑。如果你要把分割网络部署到C环境最常见的做法是PyTorch训练完导出TorchScript或者转成ONNX再交给TensorRT推理。原始点法和体素法都可以转但要注意点云预处理部分下采样、法线估计必须在C里重新实现这步容易因为两套代码不一致导致线上效果变差。我踩过最深的坑就是Python里用了Open3D的下采样C工程里换成了PCL由于体素大小语义不完全一致模型输出直接崩了一大截。如果你做的是三维GIS或数字孪生分割后通常会分类别导出点云再做Mesh重建和纹理映射。现在很多平台要求把处理好的三维模型切片成.b3dm这类瓦片数据网上已经有不少“.b3dm批量三维模型瓦片”工具和脚本。等模型切完片还能利用AI生成贴图和提示词批量出效果图这偏向资产生产流程不涉及分割算法本身但项目交付时经常遇到值得了解。另外如果要在Qt里写自己的点云工具VTKPCL是常见组合Qt负责界面和按钮VTK负责三维渲染。很多时候需要自己绘制三维曲线、坐标轴和测量线这块逻辑可以独立封装成一个三维控件。5. 常见问题与自查清单全是踩过的坑5.1 高频问题速查表现象可能原因解决方案mIoU极低类别严重偏向大类类别不平衡没处理加类别权重、Focal Loss、对小类别过采样训练Loss下降但分割结果又碎又乱局部上下文不足增大邻域搜索半径或用体素分支显存OOM采样点数太多或体素太密采样点数降到8192/4096或改用稀疏卷积帧与帧之间分割结果跳变点云未做配准对齐先用NDT粗配准再用ICP精配准训练集效果很好验证集很差数据重叠泄露或过拟合按场景拆分数据保证同一区域不跨集合户外场景远处目标识别差点云密度随距离下降给模型输入更多特征高度、强度、法线或做距离分箱投影法结果边界有锯齿投影后映射丢失信息后处理加条件随机场或换点级/体素方法这里特别想说一下数据集泄露问题。很多人标注时图省事把同一个房间或同一条路的点云既扔进训练集又扔进验证集导致验证集mIoU虚高。点云的“场景连续性”很强一个房间前后几帧之间高度重合这样切分数据很容易让模型“记下来”而不是“学出来”。正确做法是按场景或按坐标区域分块训练集不再包含验证集的空间范围。5.2 几点独家实操心得最后分享几条我自己的实操经验就当止损建议。第一先从公开数据集的官方baseline跑起来再谈魔改。很多人一上来就自己造数据集、自己改网络最后模型不收敛都不知道怪谁。我的习惯是先跑通SemanticKITTI或ScanNet的官方模板确认环境、预处理、评价指标全部正确再切到自己的业务数据上。第二特征工程还没过时。PointNet这类模型只吃xyz坐标但很多业务场景加一个“高度”“反射强度”“法线”会让mIoU明显上升。尤其是道路场景地面高度基本恒定高度特征在“地面/非地面”分离上帮助巨大。有些团队还会用几何特征描述子比如FPFH或std点云描述子做传统分割和配准虽然深度学习已经能自动学特征但在数据量不足时传统描述子仍然是有效补充。第三类别权重一定要加而且要根据实际训练集的点比例来算不能拍脑袋。室内场景还好户外自动驾驶点云里“道路”和“行人”的点数可能差100倍不加权重你的网络大概率学成一个“道路分类器”。第四可视化永远比数值指标更能发现问题。我看一个模型好不好第一件事是把结果和GT叠在一起看而不是只看mIoU数字。很多模型mIoU挺高但错误集中在小物体边界或者某些特定角度这些东西只有可视化才暴露得出来。第五不要迷信排行榜。同样是SemanticKITTI不同方法用的采样策略、类别权重、配准前处理都不一样mIoU高2个点不代表算法更好。拿到自己数据上复现一下可能结果完全反过来了。我见过好几个“榜单第一”方案在自己的业务场景里还不如一个简单PointNet。三维点云语义分割这几年发展很快从PointNet到稀疏卷积再到Transformer方法论迭代速度远超预期。但对实际做项目的人来说最重要的是找到适合自己数据规模和场景约束的方案。数据量小、场景单一用原始点法就够了数据量大、实时性要求高体素稀疏卷积更靠谱如果是极速推论投影法也完全可以考虑。没有银弹只有合适的工具和足够的调试耐心。
返回列表