跳到主要内容

系统架构

CadFlow 有意收窄应用代码与 OpenCascade 之间的边界。Python 表达建模意图和结构化工作流；稳定 C ABI 进入拥有精确几何的 C++17 Session。

Python 应用 / CAD 智能体
Model · Shape · Graph
稳定 C ABI
C++ Session / ShapeHandle
内核 · IO · Runtime · Physics
OpenCascade 几何与拓扑
领域工作流草图 · 装配 · 检查 · Scene · 序列化 · 语义STEP · STL · GLB · 报告 · Scene 归档
应用层只依赖公共 Python 接口；精确几何所有权留在原生 Session 中。

依赖方向​

Python 前端 → 稳定 C ABI → C++ Session / ShapeHandle → OpenCascade

现代前端不直接导入 OCC。它只看到不透明的 Session Token 和 Shape ID，而不是 TopoDS_Shape，因此应用代码无需承担 OpenCascade 类型和所有权规则。

原生所有权​

每个 Model 拥有一个 Session，Session 拥有该 Model 创建的所有 Shape。

Model
Session Token
Shape ID 1
TopoDS_Shape
Shape ID 2
TopoDS_Shape
Shape ID 3
TopoDS_Shape
句柄只能引用创建它的 Session 所拥有的几何。

句柄不能跨 Session 使用；Model 关闭后其中的句柄全部失效。高成本构造、布尔运算、拓扑、三角化、测量和交换调用停留在 OpenCascade 附近，不会逐对象跨越 Python 边界。

Python 前端​

前端承担两类职责：

  1. Model、Shape 和 Graph 提供精简的句柄式原生 API。
  2. 公共领域 Facade 提供草图、装配、语义、序列化、检查、Scene 归档、标准件和求解器中性交接结构。

领域模块有意保持为内置完整功能层之上的轻量公共 Facade。这样即使几何密集型路径在内部迁移，对外 Import 布局仍可保持稳定。

原生运行时​

原生源码遵循以下依赖方向：

c_api.cpp → runtime / io / kernel / physics → core
  • core 负责 Shape 存储和共享类型，不放置建模算法。
  • kernel 负责精确几何构造与检查。
  • io 负责几何交换与序列化格式。
  • runtime 解析并执行原生 Graph 批次。
  • physics 测量精确 Face 证据和降阶 Connector 响应。
  • c_api.cpp 是唯一安装的 ABI 边界。

内部 OCCT 类型和模块头文件不是公共 API。

为什么部分工作保留在 Python​

表达式、单位、约束系统、装配、语义标签、Model JSON、Scene Schema 和 Translator Policy 主要是结构化数据编排。把它们搬过 ABI 会增加复杂度，却不能消除几何瓶颈。

因此架构原则不是“所有代码都进 C++”，而是“几何密集型工作在 C++，策略和结构化工作流在 Python”。

交付路径​

精确 BREP 始终是事实来源，网格与 GLB 预览只是派生视图：

Python 程序
精确 BREP
同一事实来源产生多个交付视图
测量 + 验证
JSON 证据
STEP
STL
三角化
GLB 预览
检查、工程格式和浏览器预览都回溯到同一份精确几何。

这让工程格式和预览都可以与同一份底层几何进行对比。