tangency-labs/solidcraft：使用纯 Rust 构建的开源参数化 3D CAD 应用

tangency-labs

13.2k

1.7k 5.3k

Apache License 2.0

技术解读

以下内容由 GitRead 中文社区编辑团队基于项目 README 与官方资料整理，结合中文开发者的常见使用场景补充技术选型建议。具体以项目官方文档为准。

SolidCraft：用纯 Rust 重写参数化 CAD 的一次认真尝试

项目背景与痛点

参数化 CAD 的门槛从来不在界面，而在几何内核。SolidWorks、Fusion 360、NX 用的都是 Parasolid 或 ACIS 这类商业内核，Onshape 则把 Parasolid 搬到云端；开源阵营里 FreeCAD 依赖 OpenCASCADE（OCCT），但 OCCT 是一套年龄超过二十年的 C++ 代码库，API 冗长、内存模型古老，想编译到 WASM 几乎是一场灾难。

于是问题变成了三个具体的痛点：

第一，内核与平台强绑定。传统 CAD 的几何内核、渲染、UI 往往是三套技术栈，桌面能跑，浏览器就跑不动，云化只能靠远程串流，体验和成本都不划算。

第二，脚本化与自动化能力薄弱。设计师想做批量参数化零件、想用程序生成配置器，通常只能依赖厂商的私有 API 或宏语言，生态封闭。

第三，AI 无法真正操作几何。大模型能写代码，却没法直接"打开一个零件、改个参数、加个圆角"。缺少一个标准化的工具协议层。

SolidCraft 的定位正是冲着这三点来的：纯 Rust、桌面与 Web 同源、通过 MCP 暴露自动化接口。这不是又一个"网页版 CAD 玩具"，而是一次从内核到交互层的全栈重构尝试。

核心技术揭秘

从项目定位可以推断出它的分层架构：底层是几何内核，中层是参数化特征模型，上层是渲染与交互，再外挂一个 MCP 服务层。

graph TD A[用户编辑参数或脚本] --> B[文档模型-特征依赖 DAG] B --> C{"依赖链是否失效?"} C -->|"是"| D[拓扑排序-增量重建] C -->|"否"| E[复用几何缓存] D --> F[2D 草图约束求解] F --> G[B-rep 几何内核] G --> H[布尔运算与三角化] H --> I[wgpu 渲染抽象层] I --> J[桌面端-winit] I --> K[Web 端-WASM 与 WebGPU] L[MCP Server] --> M[工具调用-特征与参数] M --> B

特征树本质上是一张有向无环图。 每个草图、拉伸、圆角都是图上的节点，参数变更后从变更点向下游传播 dirty 标记，按拓扑序做增量重建。真正难的不是遍历，而是拓扑命名问题：用户对"某个面的某条边"做圆角，重建后几何拓扑结构变了，这条边的内部索引就失效了。成熟 CAD 的做法是给几何元素分配持久 ID，重建时做几何指纹匹配。纯 Rust 项目从零实现这套机制，工作量不小，但一旦做成，就是核心壁垒。

草图约束求解是第二道硬骨头。 2D 草图中的水平、垂直、相切、距离约束构成非线性方程组，通常用 Levenberg-Marquardt 迭代配合稀疏线性代数求解。工程难点在于诊断：欠约束时要把剩余自由度反馈给用户，过约束时要指出冲突的约束集合，这需要秩分析和残差归因。

渲染层用 wgpu 是顺势之举。 同一套渲染代码，桌面走原生 GPU 后端，Web 走 WebGPU（不支持时降级 WebGL），几何三角化结果直接喂给 GPU。相比"服务端渲染 + 视频流"的云 CAD 方案，这是真正的浏览器原生。

MCP 层的设计取舍最见功力。 工具粒度太细，模型要调用几十次才能建一个零件；粒度太粗，就失去了组合灵活性。合理的做法是把"创建草图、添加约束、拉伸、修改参数、导出"作为原子工具，并提供一个读取当前场景图与参数状态的查询工具，让模型先理解再操作。