1. 认识Text-to-CAD:从一句描述到三维模型
Text-to-CAD这个方向,说白了就是让模型听懂你嘴里那句“我要一个带法兰边的圆柱形连接件”,然后把对应的三维CAD模型给你生成出来。在过去的建模流程里,你至少得会操作一款建模软件,熟练使用草图、拉伸、旋转、布尔运算这些命令,哪怕是一个简单的支架,从画草图到完全约束再到特征生成,初学者没有半天时间根本下不来。而现在这个方向要做的,就是把这套门槛极高的操作过程压缩成一次文本到模型的映射。
真正让我觉得这个方向值得长期关注的原因,在于它把自然语言处理和几何建模这两个过去几乎不搭界的领域强行拉到了一起。语言模型学会了理解空间关系,几何生成模型学会了把抽象描述具象化。你给它“一个用于管道连接的90度弯头,两端带外螺纹”,它输出的就不再是像素图片,而是可以直接进入CAD软件编辑或者用于后续仿真的几何体。从应用角度讲,设计师早期概念探索、非专业用户的快速原型、机械零部件的初步方案验证,这些都是它切实能发力的场景。
适合看这篇文章的人,我认为有三类。第一类是刚接触AI生成三维模型、想知道底层原理和工具链怎么选的人;第二类是已经在用一些开源生成模型、但跑通之后不知道怎么和后处理流程衔接的人;第三类是做工程应用,想知道这个技术目前到底能不能用、边界在哪里的人。我会把技术原理、实操步骤、踩坑记录放在一起写,尽量让你读完就能自己动手跑一遍。
2. 核心思路与技术脉络
2.1 先理解这条技术路线是怎么长出来的
讨论Text-to-CAD之前,最好先梳理清楚它从哪条技术脉络演化而来。早期三维生成主要依赖GAN,那个时代最有代表性的成果是用2D生成器的思路做3D体素生成,输入一个类别标签,输出一个占满空间的二值体素模型。但GAN做三维有两个软肋:一是体素分辨率受限于显存,通常做到64的三次方就已经很吃力;二是训练不稳定,模式坍塌问题在三维空间中比二维图像更严重,因为生成的每一个体素都要同时满足几何连贯性和语义一致性。
后来VAE和自编码器的思路介入,改进了中间潜空间表达,让模型可以学习一个紧凑的几何编码。再往后,扩散模型在二维图像生成上展示出恐怖的细节还原能力之后,很快被研究者迁移到了三维领域。Point-E、Shap-E这一批模型验证了用扩散模型直接生成点云或隐式场表示的可行性。它们的思路很像:先用文本编码器把描述变成向量,再用扩散模型在这个向量条件下逐步去噪,最后还原出几何信号的分布。
这些工作的进展给了Text-to-CAD项目一个很关键的地基:生成三维几何不再需要手工设计复杂的损失函数,扩散模型的去噪目标天然适合三维信号的空间连续性。所以你能看到很多Text-to-CAD工具背后,骨架还是扩散模型,真正花心思设计的是怎么把CAD的实体几何特征编码进模型里。明白这条脉络,再去看具体工具的实现,就不会觉得功能之间的差异是玄学,本质是它们在几何表达方式上的取舍不同。
2.2 几何表达的路线之争:体素、点云、网格还是隐式场
Text-to-CAD最核心的技术分歧,在于模型输出端的几何表示方式。不同表示方式直接影响你能拿到的模型质量、后续可编辑性,以及和现有CAD工具链的兼容程度。我在实际评估过多个工具之后,把四种主流方式的差异整理成了一个对照表:
| 几何表达 | 优点 | 缺点 | 典型应用 |
|---|---|---|---|
| 体素(Voxel) | 结构简单、容易训练、适合分类任务 | 分辨率受限、表面粗糙、放大后马赛克感严重 | 早期三维生成、医学影像分割 |
| 点云(Point Cloud) | 数据获取容易、表达灵活、采样密度可调 | 没有拓扑关系、需要额外重建表面 | Point-E、部分自动驾驶数据集 |
| 网格(Mesh) | 渲染友好、可导入主流软件、编辑方便 | 拓扑结构复杂、生成模型不易处理 | 大部分游戏资产生成管线 |
| 隐式场(Neural Field) | 分辨率无限、表面光滑、适合复杂拓扑 | 提取网格耗时、训练计算量大 | Shap-E、Text2Mesh、部分Text-to-CAD |
从工程角度讲,你最终做CAD建模,绝大多数情况下希望得到的是带参数化特征的实体模型,而不是一个只能看不能改的网格。所以Text-to-CAD里面最硬核的路线,其实是把输出对齐到B-rep这种CAD原生表达,或者至少输出带语义分割的网格,让后续可以转成参数化特征。但这个目标非常难,因为B-rep表达的是一个连续曲面边界,而不是离散的体素或采样点,让生成模型直接输出这种东西,在数学上就需要一个精心设计的中间表示。
我的建议是,如果你只是做概念验证,体素和点云足够用;如果你要把生成结果导入SolidWorks、Fusion 360这类软件继续加工,请优先选输出网格或者隐式场再提取网格的方案。后面我会详细讲实操时怎么做这个衔接,直接去踩坑是最浪费时间的。
2.3 文本编码器与几何生成模型是怎么配合的
从架构角度看,一个完整的Text-to-CAD系统通常由两部分串联组成。前一部分是文本编码器,负责把你输入的一句话变成高维向量。这个环节可以选用CLIP的文本分支、BERT系列的编码器,或者直接用大语言模型的Embedding层。关键在于文本编码器是否经过多模态对齐训练,因为只有文本向量和几何向量被映射到同一个语义空间里,后续的生成模型才能理解“蓝色”和“圆柱”这类描述对应什么几何特征。
后一部分是几何生成模型,它把文本向量作为条件输入,通过扩散模型或者自回归模型逐步完成几何信号的生成。扩散模型的做法是,在训练阶段对真实几何数据逐步加噪,然后让模型学会反向去噪;推理阶段从一个随机噪声出发,在文本条件的引导下每一轮去噪都让几何向文本描述逼近一点。自回归模型则是把几何离散化成序列,比如用三平面的特征预测下一个局部区域的形状,每一步都参考之前生成的部分,相当于一个“逐笔画图”的3D版。
这两部分的配合质量决定了最终效果。如果文本编码器本身对空间关系理解不足,模型很容易把“在圆柱上方开一个方孔”理解成“圆柱旁边多一个方块”。而如果几何生成模型对文本条件不敏感,就会出现同一个描述生成的结果面目全非、彼此之间差异过大的情况。这也是评估一个Text-to-CAD工具好不好用的两个直接切入点:一是语义理解准不准,二是生成结果的稳定性和一致性怎么样。
3. 实操过程:本地跑通一个Text-to-CAD流程
3.1 环境准备与模型选型
我自己最常跑的一套组合是Zoo发布的Text-to-CAD模型配合Blender做后处理,这套流程既覆盖了从文本到参数化CAD模型的完整链路,又能直观看到生成结果,在社区里也是被验证次数比较多的路径。硬件方面,建议使用NVIDIA显卡,显存至少8GB。如果显存不足,可以退而求其次使用CPU推理,但速度会慢很多,一个中等复杂度的零件可能要等十来分钟,GPU推理通常在几十秒内能出结果。
环境配置顺序我建议这样做:先装Python 3.9以上版本和CUDA工具包,而后用虚拟环境管理依赖。Text-to-CAD项目依赖的PyTorch版本和Transformers库版本有比较严格的匹配关系,直接用pip install -r requirements.txt经常遇到版本冲突。我的做法是先创建一个干净的conda环境,然后手动安装匹配的PyTorch版本,再用pip逐个安装其余依赖,遇到冲突时优先以项目官方Issue区反馈过的版本组合为准。
模型选型上,我建议你区分两种使用场景。如果你只是想快速体验效果,优先用项目提供的预训练权重跑推理,不要自己训练。如果你要做某个特定类型零件的生成,比如法兰、轴承座,那最好在预训练模型基础上做微调,收集几百个同类型模型文件,转换成项目支持的输入格式,用LoRA或者全量微调都可以。微调之后再测试,生成结果的领域一致性会明显好于通用模型。
3.2 推理生成:把文本描述变成几何体
模型部署完成之后,推理阶段最考验的是提示词工程。Text-to-CAD模型对提示词的理解方式跟SD画图不完全一样,它更偏向对精确结构描述的解析。举个例子,你输入“a bracket with two holes”,模型大概率能生成一个带两孔的支架;但如果你输入“一个看起来挺结实的金属支架,最好能固定在墙上”,模型就可能发懵。
实操下来的经验是把描述切成三个部分:主体形状、特征细节、附加约束。主体形状决定了整体轮廓,比如圆柱体、立方体、L型支架;特征细节包括孔、槽、倒角、加强筋这些局部结构;附加约束可以是尺寸比例、方向指向、是否对称。按照这个结构去写提示词,生成成功率会明显提升。一个我经常使用的模板是:[主体形状] with [特征1] and [特征2], [附加约束],类似“a cylinder with a through hole and four mounting holes on a flange, symmetric”这种描述,模型解析起来就非常顺畅。
推理时的另一个关键点是随机种子。同一个提示词,不同种子生成的结果在细节上会有明显差异。我通常的做法是先生成6到8个结果,从中挑选最符合预期的一到两个做后处理,而不是指望一次生成就完美。Diffusion模型天然具有这种随机性,这既是缺点也可以看作优点——你可以通过多个候选快速探索设计空间,这在早期概念设计阶段反而是个好用的特性。
3.3 生成结果的后处理与CAD软件衔接
拿到生成结果之后,你会发现模型输出的通常是一个带拓扑信息的网格文件,常见格式为OBJ或者STL。这类文件可以直接导入Blender、MeshLab做网格修复、减面、光滑处理。但如果你想把网格变成真正的参数化CAD模型,还要过一道关键工序:曲面重建。这个环节常用的工具是Open3D的BPA算法、Poisson重建,或者商业软件Geomagic Wrap。
我自己最常用的一条路径是先导入Blender,检查网格是否有非流形边、孔洞、交叉面这些问题。对于非流形边,可以用Blender的“Select Non-Manifold”功能快速定位,然后用“Merge by Distance”和“Fill Holes”修复大部分轻微问题。做完这一步,再导出为STL,导入Fusion 360进行网格转实体或用B-rep重建。Fusion 360对于不太复杂的网格可以直接使用“Mesh to BRep”功能,但生成结果往往有大量的细小曲面块,后续修改会很痛苦,所以我的经验是优先用“Construct → Section”方式重建主要截面,再用拉伸旋转命令重构主体,这样得到的模型更干净也更易编辑。
如果你对参数化精度要求极高,网格转实体这条路目前还没有完全自动化的方案,仍需要人工介入。但好在Text-to-CAD能帮你把最多的时间花在从无到有的模型建立阶段,后期修整的工作量远小于从草图开始建模。我自己实测过一个带安装底座和散热孔的电机支架,从文本到可用模型大概花了四十分钟,其中大部分时间花在后处理的精修上,而手工建模可能需要大半天。
4. 常见问题与排查技巧
4.1 显存不足与性能瓶颈怎么破
显存不足是所有人跑三维生成模型遇到的第一道坎。Text-to-CAD模型虽然不像大语言模型那样动辄需要几十GB显存,但在推理时同时加载文本编码器和几何生成模型,加上中间要处理高分辨率体素或隐式场,8GB显卡很容易被占满。我的解决思路是先看能不能砍掉文本编码器的体积。一些项目默认使用CLIP的ViT-L/14模型,你可以替换成更轻量的文本编码器,比如DistilBERT,虽然语义理解精度会有轻微损失,但显存占用下降非常明显。
另一个容易被忽视的点是中间特征图的缓存。Diffusion模型在推理的每一轮都需要保存中间激活值用于参数更新,但在纯推理场景下这些值完全不需要保留。检查一下项目代码里是否默认开启了对梯度的跟踪,如果在推理阶段模型参数仍处于可训练状态,PyTorch会为你自动保存中间变量,显存占用会瞬间翻倍。解决办法就是在推理代码前加上torch.no_grad()上下文管理,并且把模型切到eval()模式。
如果以上都做了还是挤不出显存,那就只能走分块推理路线。对于高分辨率几何生成,把空间划分成多个块,分别生成后再进行拼接融合。这个方法需要处理分块边缘的接缝问题,我的经验是让相邻块有至少8个体素宽度的重叠区域,生成结束后取重叠区域的平均值,能在很大程度上消除接缝痕迹。
4.2 为什么生成的模型跟描述对不上
提示词写得没毛病,但生成结果跟预期差了十万八千里,这个问题出现的频率相当高。我先说一个常见的技术原因:文本编码器的分词器对专业术语的覆盖不够。你输入“countersunk hole”(沉头孔)这个词汇,在模型训练语料里如果出现频率低,编码器就会把它拆成“counter”和“sunk”两个词,语义信息直接丢失。解决方法是换成模型更熟悉的同义表达,比如“a conical hole for a flat-head screw”,虽然啰嗦,但模型理解起来更准确。
另一个原因是文本和几何的对齐没有做好。很多开源模型的训练数据来自对三维模型的自动标注,标注质量参差不齐,模型学到的文本-几何映射关系存在偏差。一个典型的例子是模型分不清“在顶部”和“在内部”这两个空间关系,因为训练数据里这两类描述可能同时出现在相似的模型标注中。对这种问题,我建议不要试图通过换新种子解决,而是尝试在提示词中加入空间锚点描述,比如“on the upper surface, centered”,把空间关系说得更加明确。
第三类问题则是模型本身的生成能力上限导致的。Text-to-CAD模型在处理细长结构、薄壁结构时比较容易失败,因为这类结构在分辨率离散化时容易断裂。如果你是这类需求,要么降低生成分辨率要求,接受粗壮版本后再用CAD软件精修,要么更换生成策略,使用隐式场表达来保持几何连续性,避免网格离散化造成的断裂。
4.3 网格文件导入CAD软件报错
这个坑我觉得值得单独拿出来说。模型生成的慢网格在三维查看器里看着没问题,一导入SolidWorks或者Fusion 360就报“非流形实体”错误。原因很简单:生成模型输出的网格只是视觉意义上的面片集合,没有物理实体的闭合性和拓扑正确性。CAD内核要求实体必须有连续的边界、一致的面的法向、没有内部自由边。而生成模型产出的网格经常有自交面、悬边、反向法线。
我的标准排查流程是:先把网格导入MeshLab,运行“Clean”过滤器,勾选“Remove duplicate faces”和“Repair non-manifold edges”选项,这一步能解决70%的拓扑问题。接着用“Invert Faces”修正方向不一致的面,再用“Uniform Mesh Resampling”重新采样,生成一个分布均匀的新网格。最后导出前务必检查“Normals”方向一致性,朝向不一致的面会导致CAD软件在计算体积时直接报错。
还有一点要强调:模型训练时使用的缩放单位和CAD软件的单位不一致,经常会让导入结果大得离谱或者小得看不见。建议在导出网格前就统一单位,确认模型是以毫米为单位生成的,导出设置里也选毫米。这个困扰我很久,后来发现就是在训练数据预处理时各数据集混用了单位,现在都在流程入口强制做一次缩放归一化。
5. 技术边界与后续还可以玩的方向
Text-to-CAD目前的极限大概在哪里,用一句话概括:能处理中等复杂度的结构件,但在高精度装配体、曲面造型、复杂机构面前仍然力不从心。生成结果的精度和可编辑性距离工业级应用还有距离。多位从业者的共识是,这个技术在“创意落地”的前半段很有价值,但后半段的工程精修仍必须依赖人工。所以如果你的目标是全自动化设计,现阶段还不现实,而如果你的目标是提高从概念到初稿的速度,它已经能实打实省下大量时间。
我自己下一步想尝试的方向是把Text-to-CAD跟拓扑优化结合起来。先用语言描述生成一个初版结构,然后运行拓扑优化去掉多余材料,在轻量化和可制造性之间找平衡。另一条线是尝试用更可控的条件生成方式,比如在提示词之外额外输入一个参考模型的形状约束,让生成结果在结构上更接近既有设计,这样它在改型设计场景中会更有价值。
最后分享一个我自己的体会:Text-to-CAD这个工具,最值得投入时间研究的不是模型本身,而是怎么把你的设计意图翻译成模型听得懂的描述。这个过程反而会迫使你把设计需求想得更清楚。跑了几百次生成之后,我发现自己做设计的思路比以前清晰多了,因为每一次生成前的描述,本质上都是一次需求分析。