★ FEATURED ARTICLE 第一次听说OCCTOpen CASCADE Technology的人十有八九会把它当成一个CAD软件。我带新人时经常有人问这东西装好之后能直接画图吗其实它没这么简单OCCT不是软件而是一套C类库准确点说是一套开源的三维几何建模内核。像FreeCAD、FreeCAD衍生出的好多工具还有一些商业CAD/CAE软件底层做几何运算的部分都受益于这类内核。你在项目里集成它就能拥有读取STEP/IGES模型、做布尔运算、生成网格、显示三维模型这些能力。这篇文章是我们OCCT入门系列的第二篇上一篇聊了选型思路和整体架构这一篇专门讲怎么把开发环境从零搭起来。我会以Windows和Linux两条主线讲解覆盖依赖准备、CMake配置、编译安装、样例验证最后把新人最容易踩的坑一次性列清楚。适合刚接触OCCT、想在自己电脑上把第一行代码跑起来的C开发者参考。1. 动手之前先拆开OCCT看看它到底是什么1.1 一个开源几何内核的基本盘OCCT的源码包体量不小刚解压出来很多人看着一堆文件夹会发懵其实它的模块划分非常清晰可以粗略归成几组。最底层是基础模块包括TKernel和TKMath。TKernel相当于系统库中的系统库提供内存管理、集合容器、资源文件访问、异常处理等基础设施听起来不性感但上层全靠它撑着。TKMath则处理向量、矩阵、曲线曲面的数学表达是几何计算的地基。再往上是造型数据模块代表人物是TKBRep和TKGeomBase。BRep是Boundary Representation边界表示的缩写这是OCCT最核心的数据结构一个三维实体不是用一堆点云或者网格来近似而是用面、边、顶点以及它们之间的拓扑关系精确描述。你加载一个STEP文件进来得到的TopoDS_Shape就是BRep数据。造型算法模块包括TKGeomAlgo、TKTopAlgo、TKMesh这些。布尔运算、倒角、拉伸、旋转、扫掠以及把几何模型离散成网格都是这些库干的活。我们平时调用的BRepPrimAPI_MakeBox、BRepAlgoAPI_Fuse这类类就在这个层次。再往上是数据交换模块TKSTEP负责读写STEP文件TKIGES负责IGES还有TKCDF等CAF相关的类。很多项目引入OCCT的初衷就是为了不自己折腾STEP/IGES解析器直接白嫖一套经过多年工业场景验证的文件读写能力。最后是可选的可视化和测试工具模块比如DRAW Test Harness这是一个类似命令行的小工作台不依赖图形界面就能执行很多建模命令。它适合做调试和功能验证但对大多数应用程序开发者来说不是必选项。1.2 为什么推荐自己编译而不是直接用现成包可能有人会问为什么不用系统包管理器直接安装?比如Linux下用apt搜索occt确实有现成包Windows下用vcpkg也能装。但我的建议是入门阶段一定要自己从源码编译一遍。原因有三。第一OCCT是动态演进的项目GitHub仓库里始终在修bug、加特性发行版仓库里的包版本更新滞后而且编译选项不一定符合你的需求。第二你需要调试符号。自己做应用后面肯定会遇到几何算法崩溃、计算结果不对这类问题这时候需要用gdb或者Visual Studio直接钻进OCCT源码里看如果跑的是别人编好的Release包这一层基本是黑盒。第三编译过程中你会被迫理解很多CMake选项的含义而编辑器配置、链接库列表这些经验恰好是之后写正式项目最需要的东西。不过自己编译也有代价整体编译一个小时是家常便饭机器内存建议至少8GBWindows和Linux的依赖处理都得自己来。但这些都是入门环节里最值得花的成本。2. 工具链准备不同平台的依赖清单2.1 WindowsVisual Studio Git CMakeWindows下我推荐Visual Studio 2022社区版选组件时勾选使用C的桌面开发。这套VS自带的MSVC编译器是OCCT在Windows上支持最好、测试最充分的工具链。除了VS还需要安装Git for Windows和CMake。CMake建议用3.24以上的版本太老的CMake可能不认识VS2022的生成器。OCCT的源码从GitHub仓库拉取就行git clone --branch OCCT-7_8_0 https://github.com/Open-Cascade-SAS/OCCT.git要注意两点。第一仓库用的不是master分支而是形如OCCT-7_8_0、OCCT-7_9_0这样的分版本分支不要随手clone默认分支否则可能拉到最新的开发中代码。第二Windows上安装路径不要带中文和空格我习惯放在D:\dev\OCCT这一条对后面所有C项目都适用不只是OCCT。如果你想构建DRAW Test Harness还需要Tcl/Tk。但由于DRAW本身不是必须的入门阶段干脆关掉TCL相关选项能省掉一大笔在Windows上找预编译依赖的时间。2.2 Linux一条命令装齐GCC全家桶Linux的环境准备比Windows简单直接。以Ubuntu 22.04为例先更新软件源然后一口气装齐编译器、CMake、Git和几个关键依赖库sudo apt update sudo apt install -y build-essential cmake git libfreetype6-dev libgl1-mesa-dev libx11-dev libxi-dev libxmu-dev这里面libfreetype6-dev是FreeType字体库的开发头文件OCCT做文字显示和字体轮廓时会用到libgl1-mesa-dev和几个libx开头的包是OpenGL和相关X11窗口库的开发头文件。就算你的应用不打算画三维窗口OCCT的某些模块在编译期也会引用这些头文件所以先装上最省事。后面我会提到为了最快跑通核心功能可以临时关闭VTK和TBB但上面的X11和OpenGL依赖最好不要省因为OCCT默认是带可视化模块一起编译的。如果你确定用不到任何可视化相关功能也可以不装这些但初学者这么折腾容易出幺蛾子不如先把依赖装全。2.3 macOSClang环境够用macOS上先安装Xcode Command Line Tools再通过Homebrew安装CMake和依赖xcode-select --install brew install cmake freetype tbbmacOS的编译流程和Linux几乎一模一样唯一的坑是如果你的Apple Silicon机器上源码里有些老代码对ARM适配还不太好建议直接把OCCT版本提到7.8以上。再就是新系统对动态库签名有严格要求编译出来后如果遇到运行时加载库报签名错误需要配置一下本地的codesign认证。这个文章不展开遇到具体报错去搜索引擎查一下就有解法。3. 核心环节CMake配置里的选项逐个说清楚3.1 必填项安装目录和构建类型拿到源码后先建立一个独立的build目录这是CMake流程的标准动作目的是不让编译垃圾污染源码目录。mkdir build cd build然后运行cmake最基础的两个参数是CMAKE_BUILD_TYPE和INSTALL_DIR。CMAKE_BUILD_TYPE选Release因为Debug模式下OCCT的几何算法会慢好几个数量级很多新手Debug编译之后跑个布尔运算等好几秒然后误以为库有问题其实只是开错了模式。INSTALL_DIR指定最终安装路径也就是头文件、库文件、资源文件被统一拷贝到的目录。Windows下用Visual Studio生成器的写法是cmake .. -G Visual Studio 17 2022 -A x64 -DCMAKE_BUILD_TYPERelease -DINSTALL_DIRD:\dev\OCCT-installLinux下直接用Unix Makefiles或Ninja生成器命令形式为cmake .. -DCMAKE_BUILD_TYPERelease -DINSTALL_DIR/opt/occtCMake在配置阶段会打印一堆模块检测信息比如是否找到TBB、是否找到FreeType。看到有红色的WARNING不用太慌先看是不是你不需要的模块。3.2 可选第三方库开关每个选项对应什么功能OCCT的CMake配置里有大量USE_开头的开关它们决定编译时是否集成某个第三方库。下面这五个是我认为最常碰到的。USE_TBB控制是否启用Intel TBB做并行计算。OCCT里不少网格化和几何算法支持多线程加速开启后性能提升明显。Linux下通过libtbb-dev安装很容易Windows下需要单独下载预编译的TBB包并指定路径。如果你第一次编译想快速跑通可以先关闭。USE_VTK控制是否集成VTK可视化库。OCCT自带一套基于OpenGL的可视化模块但如果你想在Qt或独立窗口里更方便地显示三维模型很多人会选择接VTK。这个选项会引入一大波VTK依赖不是入门阶段的必选项。USE_FREEIMAGE控制是否使用FreeImage库处理图像主要影响纹理贴图相关功能一般应用用不到。USE_RAPIDJSON控制是否集成RapidJSON库主要用于新版OCCT读取IFC等基于JSON的文件格式。如果用不到IFC可以关掉。USE_TCL控制是否构建Tcl绑定和DRAW Test Harness。前面说过这个可以关尤其是Windows上能省掉配置Tcl预编译库的麻烦。这些开关之间的关系可以这样理解关闭它们不会让OCCT的几何建模和数据交换能力打折扣只是去掉了一些可选的加速或配套功能。所以第一次编译我的建议就是一个字--省。3.3 我日常使用的三套配置方案给不同场景推荐三套配置组合方便你按需求选择。第一套是基础快速版用来在最快时间内验证环境是否可用。关闭所有可选第三方库cmake .. -DCMAKE_BUILD_TYPERelease \ -DINSTALL_DIR/opt/occt \ -DUSE_TCLOFF \ -DUSE_TBBOFF \ -DUSE_VTKOFF \ -DUSE_FREEIMAGEOFF \ -DUSE_RAPIDJSONOFF第二套是完整功能版适合正式做应用开发。开启TBB加速其他可选库关闭FreeType保持开启cmake .. -DCMAKE_BUILD_TYPERelease \ -DINSTALL_DIR/opt/occt \ -DUSE_TCLOFF \ -DUSE_TBBON \ -DUSE_VTKOFF \ -DUSE_FREEIMAGEOFF第三套是可视化集成版这里把VTK也打开适合需要做高级可视化界面的场景。VTK不是OCCT编译的硬性依赖但如果你计划用VTK做OpenGL渲染的替代方案这一步就需要提前把VTK装好并且在CMake里指定VTK_DIR路径。提示不管哪套方案编译完成后我都会先看一下CMAKE_BUILD_TYPE是不是Release很多奇怪问题都是构建类型不对引起的。4. 实际编译从源码到可用开发包的全流程4.1 Windows命令行编译过程实录Windows下配置完成后用cmake --build启动编译cmake --build . --config Release -j 8这里的-j参数是并行编译的线程数。不要无脑填最大一般填你CPU物理核心数或者略小一点。我见过一上来填32的机器直接内存爆掉编译失败。首次编译OCCT以7.8版本为例大概需要20到40分钟具体看机器性能。期间控制台会滚动大量编译日志偶尔冒几行warning只要不是error就继续跑完。编译结束后执行安装cmake --install .这一步会把头文件、库文件、DLL和资源文件复制到之前指定的INSTALL_DIR目录。安装完成后我们可以打开D:\dev\OCCT-install确认一下目录结构。我记得自己第一次编译时最困惑的是DLL跑哪儿去了。Windows下OCCT的动态库默认输出到构建目录的bin文件夹安装之后会复制到安装目录的bin文件夹。如果后面你运行demo时提示找不到TKernel.dll这类错误多半是没把bin目录加到PATH或者没把DLL拷到exe旁边。4.2 Linux编译过程实录Linux下编译命令几乎一样只是并行度参数用自己算出来的核心数nproc cmake --build . -j$(nproc) cmake --install .这里有个小经验如果编译过程中途失败了重新执行cmake --build会从失败点继续不会全部重编。所以看到error先别慌根据报错信息修依赖或者改参数然后再跑一次构建即可。整个编译过程的磁盘占用大约在3到5GB如果空间紧张编译完安装后可以删除build目录只保留安装出来的/opt/occt。安装完成后的目录长这样/opt/occt/ ├── include/opencascade/ # 头文件 ├── lib/ # 动态库 .so 文件 ├── bin/ # 可执行工具和部分脚本 ├── resources/ # 资源文件比如单位定义 ├── cmake/ # CMake package 配置文件 └── share/ # 文档和样例Linux下需要注意lib目录里会生成几十个libTK*.so文件这些就是OCCT的模块化动态库。这也解释了为什么OCCT以模块化为傲你的应用只需要链接其中几个库而不是把几GB的库整体搬走。4.3 安装后的目录结构长什么样很多人编译完就觉得大功告成其实检查安装结果同样重要。OCCT安装完成后的核心目录我用一个表格整理清楚目录内容作用include/opencascade全部头文件写代码时包含头文件libLinux下.soWindows下.lib链接时使用binWindows下.dll可执行程序运行时加载resources单位、材质等资源定义运行时读取cmakeOpenCASCADEConfig.cmake等CMake find_package使用share/doc文档和样例代码查阅参考判断安装是否成功除了看目录文件是否存在还有一个更稳妥的方法就是去看cmake目录下有没有OpenCASCADEConfig.cmake文件。这个文件的存在意味着之后我们的工程可以直接用find_package(OpenCASCADE)来引用OCCT后面第五节的示例工程就依赖它。5. 用最小程序验证环境读入STEP模型并导出5.1 最小可用的CMakeLists.txt写法环境搭建是否成功光看编译输出是不够的必须写一个能链接OCCT库并实际运行的小程序来验证。这一步也是很多人卡住的地方因为OCCT的CMake集成方式和其他库不太一样。OCCT安装后会提供OpenCASCADEConfig.cmake所以我们在自己的工程里可以直接写cmake_minimum_required(VERSION 3.16) project(OCCTDemo LANGUAGES CXX) find_package(OpenCASCADE REQUIRED) add_executable(demo main.cpp) target_link_libraries(demo PRIVATE OCCT::TKernel OCCT::TKBRep OCCT::TKSTEP )这里OCCT::TKernel、OCCT::TKBRep、OCCT::TKSTEP是OCCT提供的CMake target分别对应对应模块的库。如果你安装的OCCT版本较老可能找不到这些target那就需要退回传统方式手动用include_directories和link_directories指向安装目录。不过7.8之后的版本都支持现代CMake target写法从入门角度直接用这种方式就好。find_package找不到OCCT时可以手动指定OpenCASCADE_DIR指向安装目录里的cmake子目录cmake .. -DOpenCASCADE_DIR/opt/occt/lib/cmake/opencascade5.2 一个读取STEP并统计面数的demo现在写一个真正干活的demo读取一个STEP模型文件统计它有多少个面并计算体积。这个程序虽然是验证用途但已经是很多CAD应用的基础操作了。#include STEPControl_Reader.hxx #include TopoDS_Shape.hxx #include TopExp_Explorer.hxx #include TopAbs_ShapeEnum.hxx #include BRepGProp.hxx #include GProp_GProps.hxx #include iostream int main(int argc, char* argv[]) { if (argc 2) { std::cout Usage: demo step_file std::endl; return 1; } STEPControl_Reader reader; IFSelect_ReturnStatus status reader.ReadFile(argv[1]); if (status ! IFSelect_RetDone) { std::cerr Failed to read file: argv[1] std::endl; return 1; } reader.TransferRoots(); TopoDS_Shape shape reader.OneShape(); if (shape.IsNull()) { std::cerr Shape is null. std::endl; return 1; } int faceCount 0; for (TopExp_Explorer exp(shape, TopAbs_FACE); exp.More(); exp.Next()) { faceCount; } GProp_GProps props; BRepGProp::VolumeProperties(shape, props); std::cout Face count: faceCount std::endl; std::cout Volume: props.Mass() std::endl; return 0; }这段代码的逻辑很直白STEPControl_Reader负责解析STEP文件TransferRoots把数据转换成OCCT的内部BRep表达TopExp_Explorer是一个遍历器专门用来在一堆拓扑结构里找出你关心的面或者边BRepGProp则根据BRep数据计算体积、表面积这些物理属性。编译并运行cmake .. -DOpenCASCADE_DIR/opt/occt/lib/cmake/opencascade cmake --build . -j4 ./demo model.step如果你的模型文件没问题程序会输出类似这样的结果Face count: 6 Volume: 125这表示环境已经通了你写的代码成功调用了OCCT库并拿到了计算结果。5.3 链接不上时的排查套路链接阶段最常见的报错是无法打开文件TKernel.lib或者cannot find -lTKSTEP。遇到这类问题我的排查顺序固定是这样。第一步确认find_package是否真正找到了OCCT。在CMakeLists里加一行message(STATUS OpenCASCADE_DIR: ${OpenCASCADE_DIR})把实际路径打出来看看是否指向了正确的安装目录。第二步确认target链接名字是否正确。不同OCCT版本对CMake target的命名存在细微差异有的版本用OCCT::TKernel有的用OCCT::TKernel但旧版本可能没有带OCCT::前缀的别名。去看安装目录里cmake下的OpenCASCADEConfig.cmake搜索add_library关键字能看到这个版本所有可用的库别名。第三步确认库文件本身存在。Windows下到安装目录的lib文件夹里看有没有TKernel.libLinux下到lib文件夹里看有没有libTKernel.so。如果文件不存在说明当时的编译选择了静态库或命名规则不同返回到编译配置里调整。链接问题其实并不可怕多数是路径和命名认知不一致把上面三步走完基本能解决。6. 新手最容易踩的坑经验与避坑清单6.1 编译期问题内存、组件和第三方库在我带过的新人里编译期遇到的问题高度集中在这几个地方。内存不足是最常见的一个。OCCT在Windows上用多个并行编译任务时每个MSVC编译器进程都会吃大量内存动辄几个GB。之前有个同事的笔记本只有8GB内存硬要开8个并行任务结果编译到一半系统卡死直接蓝屏。解决方法是把并行线程数降到2到3或者把Visual Studio的编译器并发开关改小。CMake版本太老也会导致配置阶段就报错比如不认Visual Studio 17 2022生成器。这不是OCCT的问题纯粹是CMake和VS版本匹配问题。把CMake升级到3.24以上即可。第三方库路径配置错误是第三个重灾区。Windows上如果用TBB或Tcl需要把对应库的安装目录通过3RDPARTY_TBB_DIR、3RDPARTY_TCL_DIR等变量显式告诉CMake。很多新手把这些变量漏了或写错CMake输出信息里会有一条找不到XXX的警告但配置过程不会直接中止到了编译链接阶段才连环报错。所以每次配置完先花半分钟把CMake输出的Summary部分看一遍里面有每个第三方库的found状态。6.2 运行期问题找不到DLL和.so编译安装都没问题第一个hello world却运行不起来这种挫败感我太懂了。Windows下的典型报错是由于找不到TKernel.dll无法继续执行代码。原因是OCCT是动态库安装exe启动时要在PATH环境变量里找DLL。解决办法有两个要么把安装目录的bin文件夹加入系统PATH要么把用到的TK*.dll直接复制到exe所在目录。做正式项目时我一般两者都做省得每次部署都要检查环境变量。Linux下的对应报错是error while loading shared libraries: libTKernel.so。原因是动态链接器默认搜索路径里没有/opt/occt/lib。临时做法是设置LD_LIBRARY_PATHexport LD_LIBRARY_PATH/opt/occt/lib:$LD_LIBRARY_PATH ./demo model.step长期做法是把库路径写进/etc/ld.so.conf.d/occt.conf然后运行ldconfig。两者原理一样都是让系统知道去哪里找动态库。顺便说一句Windows下把DLL加到PATH、Linux下用LD_LIBRARY_PATH这两种操作本质是一种思想就是让动态链接器在默认搜索路径之外找到额外目录。6.3 提高编译速度和日常开发习惯说几个能显著改善开发体验的习惯。尽量使用ccache或sccache缓存编译产物。OCCT这种大规模C项目即使增量编译也要不少时间ccache能把反复编译的开销压到极低。我现在的流程是第一次全量编译半小时之后每次改版本或清理重建基本都在几分钟内完成。Debug和Release分两个build目录不要混用一个。平时写应用用Debug模式方便调试跑完整计算或性能测试用Release。两个目录的CMake参数可以通过CMakePresets.json管理避免每次敲一大串参数。永远保留一份可复现的编译记录。CMakeCache.txt就保存在build目录里如果后续弄不清当初编译时开了哪些选项打开它一目了然。新同学加入项目时拷贝这份文件给对方能省掉一上午的配置时间。另外别忘了把build目录加进.gitignore。源码仓库里出现成百上千个编译中间文件会让Code Review变得非常痛苦也容易把环境相关的东西误提交。这是一个很小但很影响体验的习惯。我个人习惯是在源码根目录建一个scripts目录把整套configure、build、install命令写成shell脚本或PowerShell脚本。好处是换电脑、换系统时不用回忆一遍配置参数直接跑脚本即可。如果你用WindowsPowerShell脚本保存为build.ps1如果是Linux或macOS保存为build.sh。脚本里的每个路径都用变量避免改一处到处改。最后说一个我在实际项目中很受益的做法编译完成后别着急删build目录。OCCT的编译日志会告诉你很多信息比如某个模块的编译时间、哪个功能被裁剪掉了。性能调优时这些信息能帮你判断是几何算法本身慢还是构建配置缺了并行支持。很多东西等到用的时候再回头看才明白当初留着它有多值。
阅读完成 · 觉得有帮助？
