Open CASCADE Technology (OCCT): a C++ platform for 3D modeling, exchange and visualization

What OCCT is for, and who ends up using it

The README describes OCCT as a software development platform providing services for 3D surface and solid modeling, CAD data exchange and visualization, and states that most of its functionality is available as C++ libraries. That sentence defines the audience. OCCT is not a CAD program you open and draw in. It is the layer underneath one. If you are building an application that must construct solids, read and write CAD formats, or display a model with selection and camera control, OCCT is the kind of dependency you would reach for.

The README names three application areas: 3D modeling (CAD), manufacturing and measuring (CAM), and numerical simulation (CAE). Those are different workloads sharing one geometry kernel. A CAM tool cares about reliable offsets and toolpath-relevant topology. A CAE preprocessor cares about exporting a clean solid into a mesher. A CAD editor cares about interactive editing and persistent shape history. OCCT serves all three from the same library set, which is why the API surface is broad and why the learning curve is not shallow.

The repository layout reflects that breadth: src/ holds the libraries, samples/ holds example code, tests/ holds the test suite, adm/ holds CMake and build support, and dox/ holds the documentation sources. The presence of samples/README.md as a top-level example file is a useful signal for a first-time integrator: there is example code shipped with the source tree rather than only in a wiki.

How the platform is put together: libraries, packages and data exchange

OCCT is organised as C++ libraries, and the README's packaging section is the clearest description of how the pieces reach you. Three package forms exist. A snapshot of the Git repository contains the C++ headers and sources, documentation sources, build scripts and CMake project files. A complete source archive adds generated HTML and PDF documentation plus ready-to-use projects for building on all officially supported platforms. A binary package adds, on top of the complete source archive, binaries of OCCT and of third-party libraries built on one platform, which the README says allows using OCCT immediately after installation.

That third form is the one that matters for evaluation speed. The first form is what you get from the GitHub repository itself, and it does not include third-party binaries, so a build pulls in the dependency chain yourself. The distinction is easy to miss when you clone the default branch and expect a drop-in library.

On the functional side, the README groups the services into surface and solid modeling, CAD data exchange, and visualization. Data exchange is the service that most integrators touch first, because it is the reason to bring in a kernel at all: you have a file from another system and you need geometry out of it. Visualization is the second common entry point, since a viewer is usually the first thing a prototype shows. Modeling is the part that takes longest to learn, because it is where the topology and geometry API lives.

One structural detail worth knowing early: the current version is not written into the README prose. It lives in adm/cmake/version.cmake. If you script anything around version detection, that file is the source of truth the README points to.

Building OCCT from source and generating its documentation

The README is direct that in most cases you need to rebuild OCCT on your platform before using it in your project, to ensure binary compatibility. It points to dox/build/build_occt/building_occt.md and to the Building OCCT wiki page for instructions. The repository's top level contains CMakeLists.txt, and the build support lives in adm/, which is where the CMake modules and the version file sit. The README does not print a canonical configure command line, so read dox/build/build_occt/building_occt.md for the platform-specific steps rather than assuming a flag set.

Documentation is a separate build concern, and here the README does give concrete entry points. If HTML documentation is not available in your package, you can generate it from sources with Tcl and Doxygen 1.8.4 or above on your PATH, using the batch file adm/gendoc.bat on Windows or the Bash script adm/gendoc on Linux or OS X:

adm/gendoc

Alternatively the README describes generating documentation together with the sources through CMake, by enabling the BUILD_DOC_Overview parameter and setting the path to the Doxygen executable in 3RDPARTY_DOXYGEN_EXECUTABLE, then building ALL or only Overview. It also notes that the documentation exists as plain Markdown in the dox subfolder and on the GitHub wiki, which is the cheapest route for a first evaluation before you commit to a full build.

Where OCCT stops being the right answer

The most concrete limitation is stated by the project itself: OCCT is provided on an AS IS basis, without warranty of any kind, and the entire risk related to any use of the code and materials is on you. That is boilerplate in one sense, but it has practical weight for a geometry kernel, because a defect in a boolean operation or a tessellation can surface as a bad mesh or a failed export rather than a crash, and the licence text places that risk on the integrator.

The second limitation is the build model. The README says you will usually need to rebuild OCCT on your platform for binary compatibility. That is a real cost in a CI pipeline and in a team where developers run different toolchains. It also means the binary package, which the README says lets you use OCCT immediately after installation, is the exception rather than the default path, and it is tied to one platform.

The third is scope. If your problem is reading a mesh format and drawing triangles, a full B-Rep kernel is more machinery than you need, and you will pay for it in build time and in the amount of API you must learn before the first useful result. OCCT earns its place when you need solids, surfaces and CAD exchange together. For a viewer-only or mesh-only task, a smaller rendering or mesh library is the more proportionate choice.

Finally, the README warns that third-party packages and pre-installed system versions can differ in packaging and functionality from certified releases, and that you should consult the documentation accompanying your version. That is a quiet but important caveat: if you install OCCT from a distribution package, the version you get may not match the documentation or the release you were reading about.

OCCT versus a mesh-first geometry library

The meaningful alternative is not another CAD kernel with the same architecture. It is a mesh-first or rendering-first library, where geometry is triangles and the operations you get are transforms, intersections and display rather than solid modeling. The difference in approach is where the truth of a shape lives. In OCCT, according to the README's description of its services, the core is surface and solid modeling with CAD data exchange on top: a shape is a boundary representation with topology and geometry, and a mesh is something you derive when you need to display or export it. In a mesh-first library, the triangle set is the model, and there is no separate topological layer to reason about.

That choice propagates. A B-Rep kernel can answer questions a mesh cannot, such as whether two solids are valid and how they intersect as solids, and it can round-trip CAD exchange formats with the structure intact. A mesh-first library is smaller to build, faster to start with, and sufficient for visualization, simulation meshes and 3D printing pipelines where the mesh is the deliverable. If your pipeline ends in a mesh, introducing a B-Rep kernel adds a conversion step and a dependency you may not need. If your pipeline starts with a CAD file and involves editing, the mesh-first route forces you to reconstruct information the file already contained.

The honest framing is that these are different layers, not competitors at the same layer. Teams sometimes start mesh-first for a prototype and then discover they need solid operations, at which point the mesh representation becomes the thing they must migrate away from. Deciding which layer you actually need is more useful than comparing feature lists.

Licence terms and what maintenance actually costs you

OCCT is free software under the GNU Lesser General Public License version 2.1 as published by the Free Software Foundation, with a special exception defined in OCCT_LGPL_EXCEPTION.txt. Both files ship in the repository: LICENSE_LGPL_21.txt holds the full licence text, and OCCT_LGPL_EXCEPTION.txt holds the exception. The README also states that OCCT may alternatively be used under the Open CASCADE commercial license or a contractual agreement.

For an integrator the practical question is which of those two routes fits your distribution model, and that is a question for your own legal review, not something a README can settle. What the material does establish is that both files are present in the source tree and that the exception is a named, separate document rather than an informal note. Read OCCT_LGPL_EXCEPTION.txt before you decide the LGPL alone describes your obligations.

On maintenance, the observable facts are these: the repository is not archived, and the last push was on 2026-09-05. Recent releases are V8.0.1 on 2026-07-30, V8_0_0_p1 on 2026-06-17 and V8_0_0 on 2026-05-07. That is a steady release cadence across the last few months, including a patch release after the 8.0.0 line. Whether that cadence continues is not something the README promises.

Upgrade cost is dominated by the rebuild requirement and by API change across major versions. The README's own documentation links are split between the latest version and the 8.0 documentation, which suggests the docs are versioned alongside releases. If you pin to a certified release and read the documentation for that same version, you avoid the mismatch the README warns about with third-party packages. Budget for the fact that a kernel upgrade can change geometry results, so regression tests on real models matter more than on a typical library upgrade.

Editorial conclusion

Adopt OCCT if you are writing C++ software that needs B-Rep solid and surface modeling, CAD data exchange or a 3D viewer, and you can absorb a CMake build and a large library surface. Do not adopt it if you want a finished CAD application or a scripting-first modelling stack: OCCT is a set of libraries, and the README describes most functionality as C++ libraries. Before committing, verify the LGPL 2.1 plus OCCT_LGPL_EXCEPTION.txt terms against your own distribution model, confirm that the certified release you pick matches your compiler and OS, and check whether the documentation in your package is the HTML build or the Markdown sources in dox.

Frequently asked questions

Official sources

1. License: LGPL-2.1
2. Open-Cascade-SAS/OCCT on GitHub
3. Project website
4. README
5. Releases