CGAL 提取中心线遇点离散，把 Codex Base URL 改到 TaoToken 后排查

用 CGAL::extract_mean_curvature_flow_skeleton 提取中心线时我遇到的症状是点突然离散。这次排障我打算让 Codex 跟着读代码先把 Codex 接到 TaoToken再去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 拿 Key工具里统一填 https://taotoken.net/api 。这个现象不是整体偏移而是血管中心线跑到半截会出现一小段乱跳。输入几何本身是血管表面走完 vtkCleanPolyData、vtkTriangleFilter、vtkvmtkCapPolyData 封口STL2OFF 写成 tmp.off再由 Polyhedron 读入结果 CGAL 细化出来的点找不到稳定的邻接关系。我一度怀疑是封口失败后来怀疑 OFF 面索引错位但拿不准所以决定用 Codex 做一次逐段走查先看 tmp.off再检查代码里骨架图的输出方式。1. 从报错现场说起离散点出在 CGAL 输出还是 vtkPoints 写入1.1 我原来的预处理管线使用 CGAL 提取中心线先决条件是输入必须是封闭三角网格。VTK 管线的做法是先清理并三角化然后用 vtkvmtkCapPolyData 将血管开口封住。封口之后为了不让 cap 上的三角形影响后续处理我习惯再 clean 一次、再三角化一次才把 polydata 交给 STL2OFF。我按原始函数结构整理过的流程如下省去了判空和分支处理只留主链路vtkNewvtkCleanPolyData cleaner; cleaner-SetInputData(surface); cleaner-Update(); vtkNewvtkTriangleFilter tri; tri-SetInputConnection(cleaner-GetOutputPort()); tri-PassLinesOff(); tri-PassVertsOff(); tri-Update(); vtkNewvtkvmtkCapPolyData capper; capper-SetInputConnection(tri-GetOutputPort()); capper-SetDisplacement(0); capper-SetInPlaneDisplacement(0); capper-Update(); // 封口后再清理、再三角化 cleaner-SetInputData(capper-GetOutput()); cleaner-Update(); tri-SetInputConnection(cleaner-GetOutputPort()); tri-Update(); STL2OFF(tmp.off, tri-GetOutput()); Polyhedron tmesh; std::ifstream input(tmp.off); input tmesh; if (!CGAL::is_triangle_mesh(tmesh)) { std::cerr not triangle mesh std::endl; return tri-GetOutput(); } Skeleton skeleton; CGAL::extract_mean_curvature_flow_skeleton(tmesh, skeleton); vtkNewvtkPoints pts; vtkNewvtkCellArray verts; for (quint32 i 0; i boost::num_edges(skeleton); i) { pts-InsertNextPoint(skeleton[i].point[0], skeleton[i].point[1], skeleton[i].point[2]); verts-InsertNextCell(1); verts-InsertCellPoint(i); }这个流程能跑通但中心线输出的点序和原始面片并没有约定所以一旦 CGAL 的骨架图被直接转成 vtkPoints就会丢失空间连续性。尤其要注意的是CGAL 的 mean curvature flow skeleton 输出的是一个图不是一段按顺序排列的折线。它由顶点和边构成边表示拓扑连接顶点坐标才是空间位置。你想得到的是“沿着血管走向的骨架线”而不是“图中所有顶点的集合”。1.2 先排查“点索引”和“边拓扑”混淆查看代码中的这个循环for (quint32 i 0; i boost::num_edges(skeleton); i) { pts-InsertNextPoint(skeleton[i].point[0], skeleton[i].point[1], skeleton[i].point[2]); verts-InsertNextCell(1); verts-InsertCellPoint(i); }这段代码的意图看起来是想遍历骨架图的每条边把边上的点压入 vtkPoints。但skeleton的类型通常是boost::adjacency_list它并没有operator[]的重载支持“第 i 条边”这种随机访问。你真正想取的是顶点描述符对应的坐标却把它当成数组下标访问。即使编译侥幸通过拿到的也不是按管腔走向排列的顶点。CGAL 的骨架细化不会保证顶点的存储顺序和中心线方向一致这也是“离散”现象的天然来源。更稳妥的遍历方式是使用 Boost.Graph 的迭代器for (auto v : vertices_range(skeleton)) { const auto pt skeleton[v].point; pts-InsertNextPoint(pt[0], pt[1], pt[2]); }但这样仍然只是把图里的顶点倒进 vtkPoints缺少按边序重新组织的步骤。后面 3.3 节会展开。1.3 封口带来的“假封闭”让细化过程跑偏另一个隐患在vtkvmtkCapPolyData。该滤波器虽然能把开口边界补成一个个三角形但它生成的 cap 只有几何没有法线方向保证。如果 cap 三角形法线和血管表面不一致CGAL 在收缩网格时会把开口误判成凹陷区域。实测起来就像是中心线从某个端口突然折出去或者从某段开始点与点互相翻转。这个原因和索引无关需要单独验证 tmp.off 是否真的水密。判断方法很简单统计 tmp.off 的边界边数量。如果边界边不为 0说明封口后的网格在 CGAL 眼里仍是“漏的”骨架自然跑偏。is_triangle_mesh只能判断面是不是三角形不能判断网格是否封闭这属于两个不同层面的检查。2. 把 Codex 接到 TaoTokenKey、Base URL 和模型 ID2.1 在控制台创建 Key并从模型广场取模型 ID为了让 Codex 能读 tmp.off 和检查 C 代码我先把它的 API 端点切到 TaoToken。注册、登录、创建 API Key 都在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 完成。模型 ID 以当时模型广场列表为准不要在网上随便抄一个“latest”或“gpt-5”字符串。收藏夹里的 Key 复制出来之后暂时叫它YOUR_API_KEY后续不会再从正文里出现第二个真实 Key。这里要特别区分两个地址网页控制台是带utm_sourcetaotoken_aicg_blog_end的落地页Codex 填入的 Base URL 是https://taotoken.net/api末尾不能带/v1也不能带任何 UTM 参数。UTM 参数只用于网页端追踪接口地址保持纯 URL。2.2 Codex 的 config.toml 怎么写打开~/.codex/config.toml如果之前配置过别的 provider先备份。把 provider 指向 TaoTokenmodel YOUR_MODEL_ID # 以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场为准 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key CODEX_API_KEY wire_api chat不要直接把YOUR_API_KEY写进 config.toml而是通过环境变量CODEX_API_KEY注入这样文件就算被同步到仓库也不会泄漏 Keyexport CODEX_API_KEYYOUR_API_KEY如果之前设置过OPENAI_API_KEY注意CODEX_API_KEY的优先级不一定覆盖它最稳妥的做法是在终端里unset OPENAI_API_KEY只留CODEX_API_KEY再运行 codex。这样可以避免 Codex 误连到官方端点导致 Base URL 改了却不生效。还要确认wire_api的值。TaoToken 的兼容通道默认是 chat completions 风格所以我写chat。如果 Codex 报unsupported endpoint说明模型消费的是 responses 风格再把它改成responses试试模型 ID 同样以模型广场为准。2.3 先用文件检查验证接入是否成功配置完不要急着排查先让 Codex 做一些轻量验证你现在能不能读取当前目录下的 tmp.off读取后告诉我 1. 文件头部的顶点数、面数是多少 2. 面索引的取值是否都在顶点数范围内 3. 用你理解的 OFF 格式检查这个网格是否能被 CGAL 正确解析。这一步能同时验证 Key、Base URL、模型 ID 三个变量。如果 TaoToken 的调用记录里能看见这条消息说明链路是通的。后续所有排查都建立在这个链路之上。3. 让 Codex 沿着 RefinementComputingCenterLines 逐段走查3.1 surface_cleaner → surface_triangulator → surface_capper 的管线顺序现在把原始 C 函数RefinementComputingCenterLines粘给 Codex要求它按阶段输出意见。Codex 会先注意到第二次cleaner-SetInputData(capper-GetOutput())重复清点。此时 capper 的输出已经被重新编号cleaner 再跑一次会再次合并并压缩点数量。如果 capper 内部生成了非流形边cleaner 可能直接移除一部分点面索引仍然有效但原本沿血管方向排列的顶点被抽稀中心线自然出现跳跃。另一个值得检查的点是vtkTriangleFilter的PassVertsOff()/PassLinesOff()。这两个方法确保输出里只有 polys不混入顶点或线单元。如果 capper 输出里带了一些孤立点三角化会直接丢弃它们但丢弃的点不影响面索引人眼很难察觉。你可以在两次三角化之间加一段调试打印std::cerr after clean: cleaner-GetOutput()-GetNumberOfPoints() points, cleaner-GetOutput()-GetNumberOfPolys() polys\n; std::cerr after tri: tri-GetOutput()-GetNumberOfPoints() points, tri-GetOutput()-GetNumberOfPolys() polys\n;把这两个数字贴给 Codex它可以判断点序是否在 clean 阶段被大幅重排。如果点数没变但顺序变了问题通常在写入阶段如果点数本身就少了说明 clean 合并了重复点可能吞掉了窄边上的顶点。3.2 STL2OFF 的顶点/面索引是否错位STL2OFF 的责任是把 vtkPolyData 写成 OFF 文本。OFF 的点块先写面块后写面块里的数字必须对应点块的位置。代码本身没问题但你要注意传入的vtkPolyData是不是被其他过滤器继续改写。之前的写法里centerline_input_surface surface_triangulator-GetOutput()然后再做其他处理结果该 polydata 又被后续 filter 修改导致 STL2OFF 拿到的和预期不一致。Codex 建议在 STL2OFF 前用vtkPolyData::DeepCopy固化快照。也就是把surface_triangulator的输出深拷贝给一个专门用于写文件的变量vtkSmartPointervtkPolyData off_snapshot vtkSmartPointervtkPolyData::New(); off_snapshot-DeepCopy(surface_triangulator-GetOutput()); STL2OFF(tmp.off, off_snapshot);这样后续任何过滤都不会污染 off 文件。如果出问题至少可以先排除“写文件时 polydata 已经变了”的干扰。3.3 CGAL 与 VTK 对骨架边的输出差异中心线问题的核心在这里。VTK 的经典思路是“最大内接球沿管腔滚动”采样得到的点是空间连续轨迹。CGAL 的 mean curvature flow skeleton 不一样它先把输入网格表示为带权曲面再用曲率流逐步收缩收缩到最后边缘塌陷成一张图。所以输出的不是有序点列而是一个由顶点和边组成的图结构。因此把骨架图丢给 vtkPoints 前必须先做拓扑排序。正确做法是从骨架图任意顶点出发做 BFS/DFS把连通的边按访问顺序拆成若干条 polyline再把 polyline 上每个点写入 vtkPoints同时用 vtkCellArray 保存线段连接关系。如果只是把图里的顶点随机塞进 vtkPoints那得到的就只是一堆互不连续的点正是“点会突然离散”的画面。Codex 给的排序思路类似这样std::vectorPoint ordered_points; std::mapVertex_desc, bool visited; for (auto vit vertices(skeleton).first; vit ! vertices(skeleton).second; vit) { Vertex_desc v *vit; if (visited[v]) continue; std::queueVertex_desc q; q.push(v); visited[v] true; while (!q.empty()) { Vertex_desc cur q.front(); q.pop(); ordered_points.push_back(skeleton[cur].point); for (auto e : out_edges(cur, skeleton)) { Vertex_desc nb target(e, skeleton); if (!visited[nb]) { visited[nb] true; q.push(nb); } } } }这个排序至少保证相邻访问的顶点在拓扑图上连通。如果顶点散落再去结合 tmp.off 的边界检查基本能定位问题源头。4. 打印 skeleton 顶点并对照 vtkPoints定位离散段4.1 添加显式打印为了把离散点位置钉死我在本地加了这两段日志。注意程序还是在你的机器上跑Codex 只负责读你贴回去的日志和代码上下文。std::cerr CGAL skeleton vertices: boost::num_vertices(skeleton) \n; std::cerr CGAL skeleton edges: boost::num_edges(skeleton) \n; auto v_range vertices(skeleton); for (auto vit v_range.first; vit ! v_range.second; vit) { auto v *vit; const auto p skeleton[v].point; std::cerr p[0] p[1] p[2] \n; } std::cerr vtkPoints count: pts-GetNumberOfPoints() \n; if (pts-GetNumberOfPoints() 0) { double p0[3]; pts-GetPoint(0, p0); std::cerr first point: p0[0] p0[1] p0[2] \n; }把 stdout 之外的 stderr 收集到文件./build/centerline_test 2 skeleton.log然后把 skeleton.log 贴回给 Codex。它可以从 tmp.off 的网格封闭与点序问题出发对比 CGAL 骨架顶点列表和 vtkPoints 写入阶段帮你定位离散点是出现在 CGAL 输出还是写入阶段。4.2 从日志判断离散发生在哪一侧拿到skeleton.log后分三种情况对照如果 CGAL 相邻顶点的坐标差超过血管直径说明问题在网格封口或细化参数先回头查vtkvmtkCapPolyData和is_triangle_mesh。如果 CGAL 顶点本身连续但 vtkPoints 里点的数量和顺序对不上说明边索引和顶点索引混用重点检查那个 for 循环。如果num_edges(skeleton)和num_vertices(skeleton)统计结果差异很大说明你在遍历边却在按顶点取点离散是必然的。这次我跑下来的结果是CGAL 顶点数量正常但 vtkPoints 里多出了一些重复点且顺序和图的 DFS 顺序完全不一致。Codex 顺着 tmp.off 的边界边索引发现vtkCleanPolyData在封口后把端盖上的几个顶点合并到了相邻三角形的顶点位导致 OFF 点表和面索引对不上。修法是 3.2 里的DeepCopy快照以及在写 OFF 前对点索引做一次范围校验。5. 排查完回控制台对一下账5.1 看记录排障结束回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 控制台检查这次对话产生的调用次数和 token 消耗确认CODEX_API_KEY下的用量不是零。然后顺手测一下别的模型是否也走同一个 Base URL避免以后切换模型时才发现配置只对当前模型生效。控制台里能看到每次请求的模型、时间、输入输出 token。如果某个请求突然没有记录优先查CODEX_API_KEY是否对应到正确账户以及 config.toml 里的model_provider是否真的被 Codex 使用。可以运行codex --version或对应调试命令确认加载的是~/.codex/config.toml而不是别的路径。5.2 后续建议如果你接下来要反复调这个 CGAL 管线建议把“读取 tmp.off、检查边界边、核对 point order”这类问题做成固定提示词放进本地项目文件这样下次复用当前 Context。若需要换模型先到 TaoToken 模型对话 里用同一把 Key 发一条测试消息确认模型 ID 和 Base URL 没填错。若担心长期排障消耗过大可以打开 Coding Plan 看套餐是否够用Key 在 控制台 API Keys 创建。要是哪天把执行端换到 Claude Code环境变量对应关系见 接入文档。