FreeCAD网格修复源码疑问：删除退化面片时两种不同处理逻辑的原因探究

阿华AIGC实验室

2026-4-30

关于FreeCAD网格修复中两种退化面片删除逻辑的解释

这是个非常细致的观察！咱们来拆解FreeCAD网格修复模块里这两种不同删除逻辑的设计原因，先对应代码里的两种退化场景来看：

1. 第一种场景：顶点重合的退化面片

代码里第一个循环处理的是拓扑/几何意义上顶点重合的面片——这类面片的三个顶点中至少有两个完全重合，相当于这个面已经“坍缩”成了一条线甚至一个点，它的邻接关系本身就是无效的。

对应的核心代码：

// 重合顶点（拓扑或几何意义上）
for (int i=0; i<3; i++) {
    // ...
    // 隔离面片并删除
    rFace._aulNeighbours[0] = ULONG_MAX;
    rFace._aulNeighbours[1] = ULONG_MAX;
    rFace._aulNeighbours[2] = ULONG_MAX;
    _rclMesh.DeleteFacet(index); // *** 删除前面片已被隔离
    return;
    // ...
}

为什么先隔离再删除？

顶点重合的面片，它的邻接标记本身就是错误的：因为重合的顶点对应的边长度为0，周围的面片根本没有和它共享有效的边，这些邻接关系是退化产生的冗余数据。
如果不先隔离，DeleteFacet里的邻接更新逻辑会尝试去处理这些错误的邻接引用，不仅做无用功，还可能触发异常或者产生新的无效状态。
先隔离（把邻接标记全设为ULONG_MAX）再删除，相当于告诉DeleteFacet：“这个面片没有有效邻接，直接删就行”，跳过无意义的邻接更新步骤。

2. 第二种场景：顶点共线的退化面片

第二个循环处理的是顶点共线的退化面片（代码里的示意图：P0、P1、P2三点在一条直线上）——这类面片的三个顶点是独立的，但构成的面是“扁平”的，它的邻接关系是真实有效的：它确实和周围的面片共享了合法的边。

对应的核心代码：

// 面片形式如下
// P0 +----+------+P2
//     P1
for (int j=0; j<3; j++) {
    // ...
    else _rclMesh.DeleteFacet(index); // *** 删除前面片未被隔离
    return;
    // ...
}

为什么直接删除？

这类面片的邻接标记是正确的，所以必须依赖DeleteFacet内部的逻辑来更新邻接关系：

bool MeshKernel::DeleteFacet (const MeshFacetIterator &rclIter) {
    // ...
    // 使当前面片的邻接面片的索引失效
    for (i = 0; i < 3; i++) {
        ulNFacet = rclIter._clIter->_aulNeighbours[i];
        if (ulNFacet != ULONG_MAX) {
            for (j = 0; j < 3; j++) {
                if (_aclFacetArray[ulNFacet]._aulNeighbours[j] == ulInd) {
                    _aclFacetArray[ulNFacet]._aulNeighbours[j] = ULONG_MAX;
                    break;
                }
            }
        }
    }
    // ...
}