★ FEATURED ARTICLE 做工业软件或者三维应用开发的朋友大概率都经历过这么一个阶段界面搭得有模有样菜单、工具栏、属性面板一应俱全结果一到“真正生成一个实体”这一步就卡住了最后发现绕不过去的东西叫几何内核。OpenCascade圈内一般简称 OCC正式名称是 Open CASCADE Technology就是这块领域里少数开源、且允许商用的一套完整内核。我这几年做设备建模、模型轻量化、在线报价这类活前后被它折腾过好几轮也翻烂了能找到的所有 OpenCascade 中文教程和零散的博客笔记。这篇东西不打算给你背文档。我想做的是把“一个中文教程应该讲清楚但经常讲不清楚的东西”串起来OCC 到底处在技术栈的哪一层、环境怎么搭才不白折腾三天、几个核心概念为什么这么设计、以及从一个空白工程到导出一个能用的 STEP 文件中间每一步的真实操作和真实坑点。适合已经会 C、想用 OCC 做实际功能的人也适合刚接手一个用了 OCC 的老项目、需要快速摸清底细的人。零基础也能看但我不会从“什么是类”开始讲。1. 先搞清楚 OCC 到底是个什么层级的工具1.1 它提供的是一套几何能力不是一个 CAD 软件很多人第一次接触 OCC是听说“这是个开源的 CAD 内核”然后下意识地以为装完就有个能画图的软件。不是的。OCC 给的是一堆类和算法边界表示BRep的拓扑结构、NURBS 曲线曲面、布尔运算、倒角抽壳、网格离散、STEP/IGES/STL 读写、以及一层包在 OpenGL 外面的可视化框架。它不提供用户界面、不提供参数化特征树、不提供草图约束求解、不提供工程图和刀路。我一般这么跟人解释这个分工OCC 相当于一台完整的发动机总成曲轴、缸体、配气机构全给你了但车壳、方向盘、仪表盘、变速箱匹配得你自己造。所以正确的心智模型是“我在做自己的 CAD 类应用几何这部分外包给 OCC”而不是“我在用一个现成的 CAD 软件”。这个定位直接决定了学习重点。你要花力气的地方不是界面是拓扑结构怎么组织、布尔运算为什么会失败、容差怎么控制、大模型怎么加速。这三件事搞不定界面做得再漂亮都是空壳。1.2 中文资料稀缺是真实痛点但稀缺里藏着机会官方文档是用注释工具自动生成的类说明每个类都有但只有“这个函数干什么”没有“什么时候该用哪个类、几个类怎么配合”。比如BRepOffsetAPI_MakeThickSolid文档会告诉你它的参数是什么意思但不会告诉你抽壳失败的九成原因是原模型曲率半径小于壁厚也不会告诉你失败之后该怎么降级处理。网上能找到的中文材料大致分三类一是十几年前的翻译版笔记代码停留在 6.x 时代Handle_Geom_Curve这种老写法在 7.x 之后已经不推荐二是零散的博客某篇文章解决了一个具体问题但没有上下文你照着抄完还是不知道整体怎么串三是把官方示例翻译一遍的“教程”跑得通但学完不会用自己的模型。所以一份有价值的中文教程核心不是把英文翻成中文而是做三件事标出版本差异哪些 API 在 7.x 之后改了写法、按使用场景组织类建一个实体要用哪几个类、按什么顺序调、把踩坑经验写进去什么情况下会失败、失败了怎么办。这三点才是英文文档里最难直接拿到的部分。1.3 学到什么程度算够用我按目标把学习深度分成三档你可以对号入座。第一档是调包档能加载 STEP 文件、遍历里面的实体、读取基本信息、做个简单的缩放或位置调整、再导出去。这一档大概一两周就能拿下核心是STEPControl_Reader、TopExp_Explorer、BRepBuilderAPI_Transform这几个类。第二档是构造档能用基本体、拉伸、旋转、扫掠造出想要的形状能做布尔、倒角、抽壳能检查模型有效性能把体积、面积、包围盒算出来。这一档要一个月左右难点全在布尔运算的稳定性上。第三档是算法档能处理容差传播、能自己做法向和曲率分析、能针对失败案例设计降级策略、能做批量模型的自动化处理。这一档是长期活靠项目喂。绝大多数工业软件二次开发、报价系统、模型转换工具停在第二档就完全够用了。别一上来就钻第三档容易劝退。2. 搭环境这一步九成的坑都埋在开头2.1 三条路线怎么选别凭感觉环境这件事选错路线浪费的时间比后面写代码多得多。我见过有人为了“纯净”硬啃源码编译折腾了四天最后发现只是想要个能读 STEP 的小工具。路线适合什么情况优势主要代价与坑源码 CMake 编译要改内核、要控制模块裁剪、要特定运行时完全可控能只编需要的模块依赖多一次编译一到三小时首次配置容易报错包管理器vcpkg 一类快速验证想法、写 Demo一条命令搞定依赖版本被钉死Debug 与 Release 必须用同一条链路装预编译二进制包只在上层做业务最快当天就能写代码二进制和你的编译器版本、运行库必须严格匹配我的建议很直接第一次接触一律走预编译包或者包管理器先跑通一个最小程序确认整条链路是活的再考虑要不要源码编译。先把“它能用”这件事验证了后面的耐心才撑得住。2.2 Windows 下源码编译的完整实操假设你选源码编译下面是我实测下来最稳的一套流程。准备阶段装好带 C 桌面开发工作负载的编译环境、CMake建议 3.20 以上、以及可选的并行计算库和字体库。源码解压路径绝对不要有中文和空格这一条能省掉你后面百分之三十的报错。配置阶段CMake 关键参数我一般这么给cmake -S . -B build -G Visual Studio 17 2022 -A x64 \ -DCMAKE_INSTALL_PREFIXD:/occ/install \ -DBUILD_MODULE_VisualizationON \ -DBUILD_MODULE_DrawOFF \ -DBUILD_MODULE_DataExchangeON \ -DUSE_FREETYPEON \ -DUSE_TKOFF \ -DUSE_TBBOFF逐条说下为什么这么选。BUILD_MODULE_DrawOFF是因为 Draw Test Harness 依赖 Tcl/Tk纯粹是给内核自己测试用的做业务根本用不上关掉能省一大截时间和一堆依赖问题。USE_TBBOFF是因为并行支持会引入版本匹配问题你先关掉等跑起来再开。USE_FREETYPEON是为了三维场景里能显示文字标注做可视化基本都要。编译阶段生成解决方案之后不要在默认的 ALL_BUILD 上直接编去编INSTALL这个目标它会把头文件、库文件、资源文件按CMAKE_INSTALL_PREFIX整理到同一个目录后面配置工程的时候只填一个路径就行。注意Debug 和 Release 各编一次。OCC 的库文件带调试后缀如TKD3Dd.dll只编一种另一种模式下链接必然失败这个报错看起来像“找不到库”实际是模式不匹配很容易被误导。时间预期四核机器只开必要模块单模式大概一个半小时到两个半小时。八核会快一些但不会线性增长因为最后的链接阶段是串行的。2.3 Linux 或者包管理器路线Linux 下思路一样只是把生成器换掉cmake -S . -B build -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIX/opt/occ \ -DBUILD_MODULE_DrawOFF -DUSE_TKOFF cmake --build build -j$(nproc) cmake --install build包管理器路线就一句vcpkg install opencascade:x64-windows但有个必须记住的规矩你后面配置工程时用的三元组triplet必须和装库时选的一致。如果库是 x64-windows 装的而你的工程用 x64-windows-static 去链会得到一堆玄学链接错误。Debug 和 Release 同理要么两条都装要么统一只用一种。2.4 用二十行代码验证整条链路是活的环境搭完别急着写业务先跑一个最小验证。这个程序干三件事造一个长方体、算它的体积、打印出来。如果体积对得上说明头文件、库、运行时全都通了。#include BRepPrimAPI_MakeBox.hxx #include GProp_GProps.hxx #include BRepGProp.hxx #include gp_Pnt.hxx #include iostream int main() { TopoDS_Shape box BRepPrimAPI_MakeBox(gp_Pnt(0, 0, 0), 100.0, 50.0, 20.0); GProp_GProps props; BRepGProp::VolumeProperties(box, props); std::cout volume props.Mass() std::endl; return 0; }对应的CMakeLists.txt关键几行find_package(OpenCASCADE REQUIRED) target_include_directories(demo PRIVATE ${OpenCASCADE_INCLUDE_DIR}) target_link_libraries(demo PRIVATE ${OpenCASCADE_LIBRARIES})预期输出是100000。如果出来了但这个数不对说明单位或者参数理解错了如果编译期就找不到OpenCASCADE_INCLUDE_DIR八成是OpenCASCADE_DIR没指到安装目录下那个cmake文件夹。提示第一次跑起来之后把 Debug 和 Release 各跑一遍。这一步花两分钟能省掉后面几天“为什么我这边好好的那边一运行就崩”的扯皮。3. 核心概念拆解OCC 的世界观3.1 几何和拓扑是两套东西别混着用这是 OCC 里最重要的一条分界线理解了这条后面大半的困惑自动消失。几何Geom_开头的类回答的是“这个形状在数学上是什么”一条Geom_Line是无限长直线一个Geom_Surface是数学意义上的曲面它们是参数方程没有起点终点也没有边界。拓扑TopoDS_开头的类回答的是“谁和谁连着”顶点、边、环、面、壳、实体、复合体。边是在几何曲线的基础上加了参数范围面是在几何曲面的基础上加了裁剪边界。打个生活化的比方几何是一张无限大的纸和纸上的所有曲线拓扑是你用剪刀剪出来的那一块带边界的形状以及这块形状上的每个角、每条边。你建模的时候操作对象几乎永远是拓扑几何只是拓扑背后挂着的数学定义。遍历一个实体看里面有什么用TopExp_Explorerfor (TopExp_Explorer ex(shape, TopAbs_FACE); ex.More(); ex.Next()) { TopoDS_Face face TopoDS::Face(ex.Current()); // 处理每个面 }这里的TopAbs_FACE是类型过滤器。实际写的时候你会发现面经常被重复访问因为一个面可能被多个壳引用所以严谨的做法是配合索引或者去重集合。这个细节绝大多数入门材料都不提但做面积统计的时候不算重会直接导致结果错得离谱。3.2 句柄机制与内存崩得最多的就是这里OCC 里的对象分两类管理方式完全不一样混了就出事。一类是继承自Standard_Transient的类用Handle(Xxx)这种引用计数的智能指针包起来比如Handle(Geom_Curve)、Handle(AIS_Shape)。这类对象你new出来交给 Handle 就行绝对不要自己 delete引用计数归零会自动回收。另一类是TopoDS_Shape以及它衍生的各种形状类它们本身就是轻量的“值”内部靠一层共享的底层数据结构实现拷贝廉价。也就是说你可以放心地把TopoDS_Shape拷贝来拷贝去、塞进容器、作为返回值开销很小。它也没有对应的 Handle 版本。真正的坑在这里TopoDS_Shape拷贝廉价不代表底层数据不占内存。做批量处理的时候每处理一个模型都应该显式清理不再需要的底层数据否则内存曲线会一直往上爬。我遇到过一次跑两万个零件跑到一千多个的时候内存直接爆掉查了半天发现是没清理缓存。3.3 容差所有诡异问题的总根源OCC 是基于容差的内核不是精确算术。每个顶点、边、面都带一个容差值默认精度常量是 1e-7。布尔运算能不能成功很大程度上取决于参与运算的几何体之间的容差关系对不对得上。我总结了两条实用原则都是从翻车里总结出来的。第一条单位统一用毫米尺寸控制在一毫米到一米这个量级。不要造一个尺寸 1e6 量级的模型也不要做 1e-3 以下的东西。原因很直白容差是绝对值模型尺寸越大相对精度越差模型越小1e-7 的容差就变得过大布尔运算会误判两个面是重合的。第二条布尔失败先查容差别急着改算法。可以先用BRepCheck_Analyzer检查参与运算的实体是否有效再用BRepAlgoAPI_*的SetFuzzyValue适当放宽一点点容差通常能救回来。放宽的标准是模型最小特征尺寸的千分之一以内放太多会引入破面。3.4 建模算法链按构造、布尔、修饰三段走用熟了你会发现 OCC 的建模类命名非常规整基本可以按前缀分类。构造类以BRepPrimAPI_和BRepBuilderAPI_为主MakeBox、MakeCylinder、MakeSphere、MakePrism拉伸、MakeRevolution旋转、MakePipe扫掠。输入几何、输出形状基本都是构造函数里完成拿.Shape()取结果。布尔类以BRepAlgoAPI_为主Fuse并、Cut差、Common交。这里有个性能技巧必须提如果你要连续减去十个孔不要写十次 Cut 串起来用一次 Cut把主体放在Arguments()、十个孔全塞进Tools()速度差别在大模型上是几倍的量级。修饰类以BRepFilletAPI_和BRepOffsetAPI_为主MakeFillet圆角、MakeChamfer倒角、MakeThickSolid抽壳。不管用哪一段结果都要验BRepCheck_Analyzer analyzer(resultShape); if (!analyzer.IsValid()) { // 处理失败分支别硬往下走 }这句判断看起来啰嗦但省的是后面调试的时间。很多问题往下传三层才崩崩的地方跟真正的错误点八竿子打不着。3.5 可视化框架的组成关系可视线这部分初学时最容易晕因为类名一堆而且互相嵌套。实际结构是一条链V3d_Viewer管渲染器和灯光OpenGl_GraphicDriver是具体的渲染后端V3d_View表示一个视口AIS_InteractiveContext管场景里所有可交互对象AIS_Shape把你的TopoDS_Shape包一层挂进场景。初始化的顺序不能乱先建 driver用 driver 建 viewerviewer 建 viewview 设置窗口和视口尺寸最后建 context。有一处顺序错了表现通常是编译通过、运行黑屏然后你花半天怀疑显卡驱动。注意在无桌面环境下做模型预览或者批量出图必须走离屏渲染路径并显式指定像素尺寸别指望它能自动弹出一个窗口。这一点在服务端部署时尤其关键。4. 从零做一个参数化法兰一次完整走通光看概念没用这里用一个实际零件把整条链路串一遍。选法兰是因为它的结构简单、参数关系清楚、还天然包含“多个孔”这种批量布尔的场景特别适合当第一个完整练习。4.1 需求拆解与建模思路需求是这样给一组参数自动生成一个法兰盘并导出成 STEP 文件。参数包括外径、内径、厚度、螺栓孔数量、分布圆直径、孔直径。建模思路按顺序走造外圆柱 → 造内圆柱 → 相减得到带中心孔的盘 → 循环在每个孔位造小圆柱 → 一次性全部减掉 → 校验 → 导出。为什么不边造边减因为十个独立的小圆柱丢进一次布尔比十次单次布尔快得多而且失败时的可回退性更好——你可以先把所有孔都造出来检查一下有没有互相干涉再统一执行。4.2 参数取值与结构验算我给一组具体数值后面代码里都用这组参数符号取值约束说明外径D120 mm必须大于分布圆直径加两倍孔径内径d60 mm必须小于分布圆直径减两倍孔径厚度t16 mm壁厚与内径的比值影响强度这里不展开螺栓孔数n6数量太多会导致孔间壁厚过薄分布圆直径D195 mm决定孔的径向位置孔直径d111 mm常规规格先做约束验算这一步是很多人跳过的但如果不校验参数一改就造出废件。外缘裕量 (120 - 95)/2 - 5.5 7 mm正数外缘有余量。内缘裕量 (95 - 60)/2 - 5.5 12 mm也够。相邻孔中心角是 60 度弦长 2 × 47.5 × sin(30°) 47.5 mm远大于孔径 11 mm不会干涉。体积的理论值盘体 (π/4)×(120² - 60²)×16 ≈ 135716.8 mm³六个孔 π/4 × 11² × 16 × 6 ≈ 9123.2 mm³净体积约126593.6 mm³。这个数记下来后面用来验算。4.3 代码实现核心部分不长关键是圆柱的轴向定位。默认的圆柱是从原点沿 Z 轴正方向长我习惯把它居中这样后面装配和对称操作都方便。#include BRepPrimAPI_MakeCylinder.hxx #include BRepAlgoAPI_Cut.hxx #include BRepCheck_Analyzer.hxx #include GProp_GProps.hxx #include BRepGProp.hxx #include TopTools_ListOfShape.hxx #include cmath TopoDS_Shape MakeFlange(double D, double d, double t, int n, double D1, double d1) { double halfT t / 2.0; // 外圆柱轴向居中 TopoDS_Shape outer BRepPrimAPI_MakeCylinder( gp_Ax2(gp_Pnt(0, 0, -halfT), gp_Dir(0, 0, 1)), D / 2.0, t); // 内孔 TopoDS_Shape inner BRepPrimAPI_MakeCylinder( gp_Ax2(gp_Pnt(0, 0, -halfT - 1.0), gp_Dir(0, 0, 1)), d / 2.0, t 2.0); BRepAlgoAPI_Cut cutInner(outer, inner); TopoDS_Shape body cutInner.Shape(); // 一次减掉所有孔body 当参数孔全部进工具列表 TopTools_ListOfShape arguments, tools; arguments.Append(body); for (int i 0; i n; i) { double angle 2.0 * M_PI * i / n; gp_Pnt center(D1 / 2.0 * std::cos(angle), D1 / 2.0 * std::sin(angle), -halfT - 1.0); tools.Append(BRepPrimAPI_MakeCylinder( gp_Ax2(center, gp_Dir(0, 0, 1)), d1 / 2.0, t 2.0)); } BRepAlgoAPI_Cut cutAll; cutAll.SetArguments(arguments); cutAll.SetTools(tools); cutAll.Build(); if (!cutAll.IsDone()) return TopoDS_Shape(); TopoDS_Shape result cutAll.Shape(); BRepCheck_Analyzer analyzer(result); return analyzer.IsValid() ? result : TopoDS_Shape(); }几个细节值得单独说。内孔和螺栓孔的圆柱高度都做成t 2.0并且起点往负方向偏 1 mm这叫“过切”目的是让刀具完全穿透上下表面避免因浮点误差在表面留一层薄膜。这层薄膜用肉眼看几乎不存在但会导致布尔结果显示成一个带内部空腔的实体体积报告直接错掉是最隐蔽的一类错误。另外注意SetArguments和SetTools的用法与构造函数版本的差别构造函数版本是两两运算列表版本才是批量处理。4.4 校验与导出生成完先算体积跟理论值 126593.6 对一下GProp_GProps props; BRepGProp::VolumeProperties(result, props); double v props.Mass(); // 期望 126593.6 左右 double err std::fabs(v - 126593.6) / 126593.6; // 实测下来误差在 1e-6 量级属于正常超过 1e-3 就要查实测结果一般会落在 126593.58 到 126593.62 之间相对误差远小于千分之一说明几何是对的。如果体积差得明显八成是某个孔没减穿或者两个孔的位置重叠了。导出 STEP#include STEPControl_Writer.hxx #include Interface_Static.hxx Interface_Static::SetCval(write.step.unit, MM); Interface_Static::SetIVal(write.step.schema, 5); // 按需选协议版本 STEPControl_Writer writer; writer.Transfer(result, STEPControl_AsIs); writer.Write(flange.step);单位和协议版本这两行必须显式设置否则默认值可能和你的预期不一致别人打开模型发现比例差了一千倍就是这一步漏了。导出之后一定要用另一个工具打开看一眼别只相信自己写的代码这是我在项目里反复强调的习惯。5. 常见问题与排查实录5.1 编译和链接阶段的问题链接报找不到符号按顺序查三件事库列表是不是漏了某个模块不同功能分在不同TK前缀的库里做可视化要额外链可视化那几个做 STEP 读写要额外链数据交换那几个配置目录是不是指到了安装目录下的cmake子目录Debug 与 Release 是不是混了。第三条最难查因为报错信息看起来跟普通缺库一模一样。配置阶段报找不到包通常是把OpenCASCADE_DIR写成了安装根目录。它要的是包含配置文件的那一层通常是根目录下的cmake文件夹。这一条我至少踩过三次。还有一个隐蔽的编译器版本和二进制包不匹配。运行时库版本对不上编译能过运行到某个特定功能才崩而且崩的位置每次都不同。遇到这种“随机崩”第一反应就应该是检查 ABI 一致性。5.2 运行时的崩溃与逻辑错误句柄相关的崩溃特征通常是崩在析构阶段。原因基本是把局部对象里new出来的Standard_Transient派生对象直接delete了或者对一个已经被回收的 Handle 继续访问。记住那句话给 Handle 的对象永远不要手动释放。形状相关的错误更隐蔽。TopoDS_Shape有个IsNull()但IsNull()为假不代表形状是有效的。空壳、无效的环、方向错误的面的组合IsNull()都返回假。所以判断有效性的正确姿势永远是BRepCheck_Analyzer不是IsNull()。可视化黑屏如果编译链接都正常先查初始化顺序再查渲染后端有没有正确创建最后才怀疑显卡。顺序这一条占了黑屏原因的绝大多数。5.3 布尔运算失败的典型场景布尔失败是 OCC 使用中最常见的拦路虎我把遇到的归成几类现象大概率原因处理办法相减后结果为空两个体根本没有相交或者被完全切掉检查包围盒和坐标是否在同一个空间里结果里出现多余碎片参与运算的几何共面或相切稍微错开一点位置或放宽容差倒角直接失败圆角半径超过相邻边的一半减小半径或改成分段倒角抽壳失败模型局部曲率半径小于壁厚减薄壁厚或先局部圆角过渡报错但形状看着没问题拓扑有效但底层有微小破面用有效性检查确认必要时重建共面这种情况特别常见你要在一个已经有一个面的位置再造一个面两者完全重合内核无法判断该保留哪一侧。做法是在建模阶段就让两者错开一点点比如过切 1 mm比事后补救省事得多。5.4 一份可以贴在显示器边上的速查表症状第一步查什么第二步查什么编译找不到头文件包含目录是否指向安装目录的 include模块是否在编译时被关掉了链接找不到符号Debug/Release 是否一致模块对应的库是否全部链上运行随机崩溃二进制与编译器是否匹配句柄对象是否被手动释放布尔结果不对参与运算的体是否都有效容差是否合理、是否共面导出的模型比例不对单位设置读取方的单位设置内存持续增长每轮处理是否清理了缓存场景对象是否没移除就重复添加6. 学习路径安排与资料取舍心得6.1 中文教程的正确用法拿到一份中文教程别从头抄到尾。我的用法是把它当索引用先扫一遍目录找到自己要做的那个功能对应哪几个类然后带着这几个类名去翻官方类说明看具体的参数意义最后再回来看教程里的示例把示例改造成自己的参数。这个顺序很重要。先看示例会导致你只会照着改数字一换场景就不会了先看类说明又太枯燥容易放弃。索引、说明、示例三步走效率最高。还有一点遇到版本差异以自己实际装的版本为准。教程里的代码跑不通先别怀疑自己去查一下这个类在你这个版本里有没有被标记为过时、有没有新的替代类。OCC 在 7.x 系列里做过不小的调整很多老代码需要改写法才能编译。6.2 分阶段目标与练习清单我给自己的练习清单是这么排的你也可以照这个顺序走。第一阶段一周内跑通基础体构造、打印体积和包围盒、用遍历器统计面数和边数。目标是建立起“形状是数据结构不是黑盒”的感觉。第二阶段一个月内做拉伸、旋转、扫掠各一个做一次成功的布尔并、差、交做一次圆角和倒角做一次抽壳。每一个都要跑有效性检查失败的要记录失败原因。第三阶段一到两个月完整走一遍导入 STEP、遍历实体、识别某个特征、修改参数、导出 STEP。这一步做完你已经能做实际的业务功能了。第四阶段持续做容差实验——同一组布尔运算把SetFuzzyValue从 0 调到 1e-3观察成功率和结果的差异。这个实验做完你对内核的理解会上一个台阶。6.3 我踩过的三个认知误区第一个误区以为 OCC 有参数化能力。它没有。你给它的是具体的几何参数不是“这个孔跟着那个尺寸走”的约束关系。要做参数化特征树得自己在外面搭一层把特征、参数、依赖关系、重建顺序全自己管。很多人一开始就想着做参数化 CAD结果在这一层耗光了热情。第二个误区忽略容差把它当成“高级话题”往后放。容差不是高级话题是日常话题。你第一天做布尔就会遇到它。早点建立“所有几何运算都在容差范围内进行”的意识能少走很多弯路。第三个误区想着把所有模块都编译上、所有功能都用上。实际上百分之八十的项目只用到构造、布尔、数据交换这三块可视化都可能不需要。模块开得越多依赖冲突的概率越高编译时间越长。6.4 关于“免费”这件事的几句实话开源许可允许商业使用这一点是可以确认的但条款细节值得自己读一遍原文尤其是动态链接和静态链接的要求不一样改动了内核源码之后的分发义务也不一样。我的做法是把许可原文打印出来贴在工位上遇到不确定的地方就翻。这不是小题大做商业项目上因为许可问题返工的成本比读一遍文档高几个数量级。至于学习成本说实话不低。但投入一两个月换一个能长期复用的几何内核能力对做工业软件这条线的人来说账是划算的。我个人在实际项目里最深的一条体会是别把 OCC 当成一个需要“学会”的库把它当成一个需要“摸清脾气”的同事。它的文档能告诉你每个接口叫什么但告诉不了你它在什么情况下会闹别扭。那些闹别扭的场合,基本都集中在容差、布尔、句柄这三件事上把这三件事的规律摸出来剩下的就是查手册的体力活。我到现在还会偶尔翻自己早几年记的失败案例笔记那些笔记的价值比任何教程都高——建议你从第一个项目开始就记记下每次失败的输入参数和最终解决办法一年之后这份笔记就是你自己的中文教程。
阅读完成 · 觉得有帮助？
