做几何建模引擎选型绕不开ACIS、Parasolid、CGM、OpenCascade这四个名字。前阵子帮一家做建筑信息化的公司评审三维内核后台也收到不少类似私信这四个到底该怎么选这个问题真不是一句“有钱选商业、没钱用开源”能打发的。今天不吹不黑把这四个几何建模引擎的家底、能力边界、授权模式、数据交换成本以及一条很多人问过的落地路径——从DWG图纸读到OpenCascade——完整梳理一遍。无论你是CAD平台架构师、机械设计软件的技术负责人还是土木建筑行业打算自研BIM工具的开发者这篇都应该耐心看完。1. 四方格局一个赛道里四种完全不同的活法很多人以为四大内核是互相可替代的同质产品这是最大的误解。它们只是恰好站在同一个赛道各自出身、商业模式、擅长领域差异非常大。决定选型的首要事情是先搞清楚每个内核到底在吃哪碗饭。1.1 商业三巨头Parasolid、ACIS、CGM各守一摊Parasolid出自西门子Digital Industries Software源头可以追溯到Unigraphics/EDS时代现在广泛服务于NX、SolidWorks、Solid Edge这些主流机械CAD软件。机械设计圈子里Parasolid的占有率相当高它的布尔运算、特征建模、容差模型处理都是教科书级别的稳定。很多厂商选它不是因为它最便宜而是因为客户传过来的模型很多是SolidWorks或NX生成的内核一致能省掉大量解析和兼容上的麻烦。ACIS是Spatial公司的产品Spatial后来被达索系统收购但一直维持独立商业内核对外授权的状态。AutoCAD早年用ACIS做过大量几何功能Inventor早期版本和不少中小型CAD/CAM软件都基于ACIS。这个内核的优势是授权方式相对灵活、历史数据积累多、二次开发接口成熟注塑模具设计、CAM刀具路径生成这些场景里非常常见。如果你需要快速拿一个商业内核做自己的垂直产品ACIS往往是谈判空间比较大的那个。CGM是达索自家CATIA产品线的几何底层现在叫Convergence Geometric Modeler。它最强的领域是曲面建模和复杂曲面光顺飞机机身、汽车外板这类A级曲面CATIA那套高精度框架就是建立在这个内核上的。但CGM不像Parasolid和ACIS那样被广泛打包授权给第三方厂商想独立拿CGM做自己的产品商务门槛很高所以它更多活跃在达索生态内部。三家商业内核一个主打机械通用一个主打灵活授权一个主打高端曲面分工非常清楚。1.2 开源独苗OpenCascade免费但绝不廉价OpenCascade圈里习惯叫OCCT来自Open Cascade Technology。它出身于法国CAD/CAM领域1999年前后以开源形式放出几何内核代码目前以LGPL-2.1为主要许可证。LGPL意味着你可以把OCCT作为库用在闭源商业软件里但要注意动态链接、修改部分开源这类义务如果希望更宽松的商业条款也可以找Open Cascade官方购买商业授权和技术支持。OCCT在开源社区里几乎是“几何内核默认选项”。FreeCAD的几何核心是OCCT大量网格转换、STEP处理、三维可视化的开源工具也依赖它。免费、有源码、社区活跃这些都比商业内核友好。但“免费”不等于“省钱”OCCT学习曲线非常陡文档偏数学化示例相对分散曲面光顺和布尔运算在极端情况下需要大量人工干预。真想把OCCT做成商业级产品你需要一支能读懂几何算法、愿意压内核的团队这个隐性成本常常被低估。1.3 为什么“三加一”是这个行业的真实生态刚入行的朋友可能会问为什么这个领域没有八个十个内核因为几何内核研发是门槛极高的工程问题计算几何、拓扑学、数值稳定性、数据交换标准每一项都要持续投入几十年。四大内核都是数学家团队长期迭代的产物不是写几个类、调几个算法就能追上的。商业内核靠授权费养研发形成正循环护城河OCCT作为开源参照系让后来者有了学习和起步的抓手也倒逼商业厂商在服务和授权上更透明。理解了这个生态你就会明白选型不是找一个“最好的内核”而是找一个“与自身业务最匹配的内核”。2. 内核能力和差距决定产品高度的不是功能列表看宣传册四个内核的功能列表大同小异拉伸、旋转、扫掠、布尔、倒角、样条曲面全都支持。真正的差距藏在看不见的地方数据结构、容差处理、曲面光顺、失败率。这一章把最影响实际产品体验的几个维度拆开讲。2.1 共同的地基B-rep、NURBS与拓扑结构主流几何内核都采用边界表示法Boundary Representation简写B-rep。一个实体不是黑盒子而是由体、面、边、顶点组成的分层结构面与面之间的几何形状由NURBS曲面或解析曲面描述。B-rep的优势是信息完备、能精确表达锥面、柱面、自由曲面代价是算法复杂任何一步出错都要做拓扑检查。以OCCT为例你会在API里看到大量BRep前缀的类比如BRepBuilderAPI_MakeEdge、BRepBuilderAPI_MakeFace、BRepAlgoAPI_Fuse分别负责构造边、构造面、布尔融合这些底层动作。这些类名抽象出来和Parasolid里body/face/edge的概念本质相同。四家内核参数体系不同底层都要解决同样三个问题几何求交是否稳定、拓扑重建是否合理、数值精度是否可控。所以一个人如果理解了B-rep和NURBS换内核时心智模型是通用的。2.2 布尔运算内核品牌的分水岭布尔运算也就是并集、交集、差集是CAD建模使用频率最高、也最能拉开差距的功能。两个曲面求交会产出复杂的相交曲线再切割、缝合回拓扑结构任何一步出现悬空面、零厚度、退化边后续操作就可能全盘崩溃。商业内核在交线计算和容差恢复上投入很大能容忍许多“脏输入”OCCT的BRepAlgoAPI_Fuse常规情况下没有问题但面对大量相切面、曲面小角度相交、极小特征时需要更细致的预处理。我经常跟团队强调一句话不要拿参数方块去测内核要拿你们行业里最丑的模型去测。比如对倒圆后的边继续做布尔多个面贴在一起出现零间距这些才是真实生产环境里的“杀手”。Parasolid在容差建模上口碑一直很好ACIS也不差OCCT也能出结果但可能要靠模糊容差来兜底甚至需要先做一堆修复操作。这里没有捷径只能通过POC测试量化失败率。2.3 曲面光顺、容错修复与“脏模型”曲面质量主要看连续性G1是切线连续G2是曲率连续汽车外板、飞机蒙皮这类产品往往还要更高阶的连续性要求。CGM在CATIA体系里对这类曲面做了专门优化配合达索的断面线、云图检验工具生成A级曲面的效率很高。Parasolid的特征建模和圆角过渡同样强悍适合机械零件这类短曲面产品。OCCT也有GeomFill、GeomAPI等工具能够指定连续阶生成曲面但要做到产品级光顺需要封装大量经验性参数。真实世界下载来的模型很少是干净的面片之间有裂缝、边重叠、法向反向、微小碎面。商用内核里普遍内置shape healing和repair能力可以把烂模型修到能继续建模OCCT也有ShapeAnalysis_Edge、ShapeFix_Wire这套修复工具但更像是“手术器械”需要你亲自判断病灶并手动操作。我处理DWG转来的几何时几乎每一步都在做线框清理、闭合轮廓检查、共面小面合并这些脏活是三维内核落地中最容易被低估的部分。2.4 用压测思维理解内核差异如果你在写选型报告千万别只列“支持什么”要设计一组压测用例典型零件、布尔失败模型、超大规模装配、特征与非特征混合模型、第三方格式导入后的原始数据。逐个统计成功率、耗时、人工修复时间然后打分。你会发现四个内核的差距不是平均分布的某个内核在A类模型上几乎零失败在B类模型上却可能输给OpenCascade。选型不是选最强是选与业务分布最匹配。3. 授权模式、数据交换与团队成本选型真正难的地方技术能力只是表层真正让项目卡壳的往往是授权条款、数据流通和团队学习成本。这三点不提前想清楚后面上线每走一步都是雷。3.1 三种授权玩法的对比先看一张总表把四个引擎的基本商务属性放在一起引擎开发商许可证性质典型授权方式主要生态ParasolidSiemens Digital Industries Software商业闭源年费/按开发席位和部署场景谈判NX、SolidWorks、Solid Edge等ACISSpatial达索系统旗下商业闭源年费/项目授权需签署NDA大量中小CAD/CAM、Autodesk系历史产品CGMDassault Systèmes商业闭源深度绑定达索生态商务门槛高通常纳入3DEXPERIENCE合作体系CATIA、DELMIA等OpenCascadeOpen Cascade SAS / 社区开源LGPL-2.1为主可商业闭源使用免费使用技术支持与商业协议另谈FreeCAD、pythonocc-core、大量开源工具链商业内核的授权费用通常不便宜并且会随着部署端点、应用场景上浮。更重要的是合同里常常有“应用领域限制”比如禁止某些垂直行业的再分发或者要求开源衍生模块。这些条款直接决定产品能不能做嵌入式、能不能卖给OEM客户必须请法务逐条审。OCCT看起来没有授权成本但技术人员要清楚LGPL下动态链接和静态链接的区别别等产品快发布了才来改架构。3.2 数据交换模型在不同内核间的旅行CAD软件之间的格式本质上是“某个内核的外壳”。SolidWorks存parasolid格式CATIA存CGM相关格式许多“神奇转换”背后其实是内核对STEP、IGES的读写质量。如果自家软件要长期和主流CAD交换数据商业内核能省下大量麻烦因为对方可以直接导入原厂内核格式不用绕一圈标准格式。OCCT内置STEPControl、IGESControl、RWStl等读写器覆盖常见格式没问题但复杂曲线曲面、装配层级、属性颜色在高版本格式之间仍会丢失信息。做土木BIM时几何会以IFC、Revit导出模型等形式进来OCCT对接IFC几何解析已经成为常见做法之一但每次都要处理单位、坐标系、构件属性映射这些细节。换句话说数据交换不是“能不能读”的问题而是“读完之后丢了多少、还能不能继续建模”的问题。3.3 团队学习曲线和社区资源商业内核的文档严谨但往往需要签NDA才能看到全部细节API稳定遇到问题可以走原厂支持工单响应速度取决于购买的服务等级。OCCT正好相反文档公开、源码可读遇到问题可以去社区提issue。学OCCT有两个捷径一是看pythonocc-core的示例仓库在Python环境里调试比C快得多二是直接读FreeCAD源码它把OCCT很多底层用法封装成了可理解的上层功能。但FreeCAD的代码也说明了一件事用OCCT堆出稳定应用需要大量外围处理问题不在“能不能”而在“谁来做、做多久”。4. 落地演练把DWG图纸一步一步读进OpenCascade最近网上讨论度很高的话题是“dwg图纸读取到opencascade”尤其是土木方向的开发者总在问这条链路到底怎么落地。这个需求非常真实设计院交付的施工图大量是DWG二维图纸墙线、轴线、门窗、道路中心线全放在Line、Polyline、Block里。如果BIM平台放弃DWG等于放弃整个存量市场。所以这一章把我一直在用的完整流程展开讲。4.1 土木BIM场景为什么要走这条路土木行业现状是三维BIM模型尚未全面普及但DWG二维图纸早已是交付标准。把这些二维图形读进OCCT后可以拉伸成三维体块继续做体量计算、碰撞检查、可视化再输出成IFC或原生BIM格式。这条链路几乎是土木信息化团队绕不开的功课。和机械CAD不同土木图纸里的几何实体种类更少但数量极大、块嵌套复杂、图层语义混乱处理起来考验的是工程化能力而不是几何算法本身。4.2 第一步DWG转DXF绕开封闭格式DWG不是公开格式没有官方通道能直接把DWG读进OCCT。稳定的做法是先转成DXF。DXF虽然是AutoCAD的交换格式但结构公开、可读写社区资料非常丰富。转换工具很多可以用AutoCAD或国产CAD自带导出用ODA File Converter做批量转换或者在自己的程序里集成DXF解析库。这里建议如果做内部工具为了速度可以解析二进制DXF如果要长期维护最好统一先把文件转成ASCII DXF R12以上版本再从ASCII解析。还有一个容易忽略的细节是单位。DWG可能用毫米、英寸、米读取头部变量或者通过图层标注推断最终统一缩放成毫米。单位不统一后面拉伸高度和布尔合并会差出一个数量级而且这种错误在画面上很难一眼看出来。4.3 第二步解析DXF关键实体并映射到OCCDXF文件结构分为HEADER、TABLES、BLOCKS、ENTITIES等段。对初版工具来说先把LINE、ARC、CIRCLE、LWPOLYLINE、INSERT解析好就能覆盖大部分建筑图纸。核心映射关系整理如下DXF实体类型几何含义OCCT映射方案LINE直线段两个gp_Pnt构造边BRepBuilderAPI_MakeEdgeCIRCLE完整圆用gp_Circ构造圆再生成边ARC圆弧用gc_ArcOfCircle或gp_Circ配合起点、终点、方向生成LWPOLYLINE二维多段线含直线段和弧段逐段转直线或圆弧再连成BRepBuilderAPI_MakeWireINSERT块引用从BLOCKS段取块内实体应用插入点、比例、旋转矩阵后转换SPLINE样条曲线读取控制点和节点构造Geom_BSplineCurve再MakeEdgeINSERT块可以嵌套所以解析时要写成递归函数设置最大层数。块内部的实体坐标是相对坐标必须先乘上块表里的缩放和旋转矩阵再加上插入点转成世界坐标否则整个图纸会错位。4.4 第三步从二维图形变成三维体闭合的DWG轮廓比如墙体外部线、房间边界可以构造成Wire再通过BRepBuilderAPI_MakeFace生成平面面最后用BRepPrimAPI_MakePrism沿Z轴拉伸成体。不过真正的墙不是简单拉伸要考虑构造层、门窗洞口和连接构件。你需要先做闭合区域识别再做布尔差集挖洞最后分组输出。我的操作习惯是先在二维平面上把所有轮廓统一、删除重复线、合并共线线段再进入三维。否则拉伸后会看到重叠面后续布尔运算也会因为微小重叠而失败。这一步看着繁琐却能省掉后面80%的修模时间。4.5 代码片段Python pythonocc-core 快速验证pythonocc-core是OCCT的Python绑定能够极大降低验证成本。用conda安装pythonocc-core后可以快速跑下面这段简化示例from OCC.Core.gp import gp_Pnt, gp_Vec from OCC.Core.BRepBuilderAPI import BRepBuilderAPI_MakeEdge, BRepBuilderAPI_MakeFace, BRepBuilderAPI_MakeWire from OCC.Core.BRepPrimAPI import BRepPrimAPI_MakePrism def line_to_edge(x1, y1, x2, y2): p1 gp_Pnt(x1, y1, 0.0) p2 gp_Pnt(x2, y2, 0.0) return BRepBuilderAPI_MakeEdge(p1, p2).Edge() def wire_to_prism(points, height): wire_builder BRepBuilderAPI_MakeWire() for i in range(len(points) - 1): wire_builder.Add(line_to_edge(points[i][0], points[i][1], points[i 1][0], points[i 1][1])) # 正式代码需要闭合首尾这里为了示例省略 wire wire_builder.Wire() face BRepBuilderAPI_MakeFace(wire).Face() return BRepPrimAPI_MakePrism(face, gp_Vec(0, 0, height)).Shape()这段代码只演示了“点列表生成线、线生成面、面拉伸成体”的完整逻辑真实场景里还要处理圆弧段、块展开和轮廓闭合。先用Python把数据结构跑通再用C重写性能瓶颈部分是我在团队里比较推荐的做法。4.6 这套流程里我反复踩的坑圆弧方向DXF中圆弧的起始角和终止角按逆时针为正转换前先统一曲线方向否则生成出来的边方向是反的后续Wire构建会失败。块嵌套过深某些图纸INSERT套INSERT可以套五六层递归解析时一定设置深度上限否则会爆栈。重复线与共线线段很多DWG图纸里同一根墙线被画了两遍直接转Wire会多出无效顶点后续拉伸时产生薄片需要用ShapeUpgrade_UnifySameDomain或者自己做拓扑清理。性能问题一个小区施工图可能几万个实体Python逐实体构造会很慢。建议先裁剪目标区域或者用多线程做实体分块解析。图层语义DWG里墙体有时候不画在“墙”图层而画在“0图层”所以不要完全依赖图层名判断构件类别最好结合几何特征和块名一起判断。5. 我的选型倾向与评估清单最后把我在不同项目里形成的选型判断方式分享出来。希望能帮正在纠结的团队把这件事从“经验之争”变成“数据之争”。5.1 用本行业最丑的模型做POC选型决策只用官方演示模型几乎等同于耍流氓。正确做法是去客户那里收集几十个真实模型脱敏后做成压测集。每个模型至少跑一遍完整流程导入、修复、特征识别、布尔、导出STEP然后记录失败点、人工干预时间、CPU时间。不要只统计成功案例更要统计失败模式和可恢复性。我见过一个团队用官方示例测出来两个内核一模一样可真实数据上一半模型都需要手工修商业内核只需两次点击差距立刻显现。这种差异如果不做压测根本发现不了。5.2 精度、容差和单位最容易翻车的三件事几何内核的容差设得太严布尔操作会大量失败设得太松微小特征会被吞掉。OCCT的Precision::Confusion()默认值通常是1e-7对于毫米建模够用但DWG图纸坐标动辄几百万毫米就要单独控制偏差精度。另一个高频问题是单位OCCT内部其实没有单位概念你传多少坐标它就当多少单位。从DWG到OCCT不统一单位模型比例必然错乱。还有模糊容差在相切、共面场景里的使用这个参数没有通用值必须站在业务数据分布上去调。5.3 给不同团队的建议做机械CAD、CAM、产品生命周期系统的团队预算充足时优先评估Parasolid其次是ACIS商业支持的成熟度在长期项目里很重要。做汽车外板、航空曲面、高端工业设计的团队CGM优势明显但必须接受达索生态的商务绑定。做土木建筑、BIM、图形可视化、教学科研、中小型内部工具的团队OCCT完全够用配合ezdxf和pythonocc-core可以快速出原型等产品和商业验证跑通了再回头评估商业内核。创业团队我尤其建议先拿OCCT跑通MVP用真实用户数据验证需求而不是在八字没一撇的时候背上高昂的授权成本。最后说一个我个人的体会我不迷信具体某个内核。几何引擎选型是一个“业务数据分布、团队数学能力、商务约束”共同作用的综合题没有万能答案。如果你也正在做评估建议先花一周时间整理你们最头疼的模型集用OCCT免费跑一遍再用商业内核试用版跑一遍谁更适合数据会说话。希望这篇能帮你少走两步弯路。