Honest position

Open CASCADE is capable, genuinely free of royalties, and the right choice for many products. It is not a drop-in replacement for a commercial kernel. Plan for a hardening layer — and know the specific cases where even that is not enough.

We build on OCCT regularly and recommend it often. This article is not an argument against it; it is the honest account of what you take on, so the decision is made with clear eyes rather than on the word "free".

What OCCT does well

  • Complete B-Rep modelling — solids, surfaces, topology, the full stack.
  • STEP and IGES import/export that genuinely works, which alone saves enormous effort.
  • No royalties, which makes SaaS and high-volume products economically viable.
  • Source access, so you can diagnose problems rather than file a ticket and wait.
  • Meshing, visualisation and OCAF included — a lot of surrounding infrastructure you would otherwise build.
  • WebAssembly builds, enabling browser-based CAD without per-user licensing.

Where it fights you

Boolean robustness on real geometry

The defining issue. Operations that work reliably on clean models fail on imported files with tangent faces, sub-tolerance gaps and sliver faces. Your test suite passes; your first serious customer file does not.

API ergonomics

The API is large, verbose, and dated in style. Handle classes, manual downcasting, and exception behaviour that surprises teams accustomed to modern C++. Reading source becomes a routine part of development rather than a last resort.

Performance on large models

Some operations are noticeably slower than commercial equivalents. Usually manageable with caching and by avoiding pathological call patterns, but it needs profiling rather than assuming.

Documentation gaps

Reference documentation exists; guidance on which of several similar classes to use, and why, frequently does not.

The failure mode to avoid: prototyping directly against OCCT, scattering its calls through your codebase, then discovering during production hardening that every failure path needs handling in fifty places. Build the wrapper early, even when it feels like overhead.

The hardening layer that makes it production-grade

  1. A wrapper API in your own vocabulary Your product's operations, not OCCT's classes. This is where you centralise error handling and where a future kernel change becomes survivable.
  2. Input validation and healing before every operation Check shape validity, stitch gaps, remove slivers. A large share of boolean failures are actually invalid-input failures.
  3. Explicit fallback strategies If a boolean fails, retry with adjusted fuzzy tolerance, retry with simplified input, or fall back to a mesh operation and flag reduced precision — anything but silent failure.
  4. Post-operation validation Verify the result is a valid solid before returning it. Catching corruption at source is worth enormous downstream debugging time.
  5. A regression suite of real geometry Every customer file that ever failed becomes a permanent test case. This is the highest-value asset you will build.
  6. Structured logging around geometry operations When a user reports a failure, you need the input shape and parameters, not a stack trace.

The teams who ship successful OCCT products are not the ones who found a magic setting. They are the ones who treated robustness as a feature with a budget.

When OCCT genuinely is not enough

SituationWhy OCCT falls shortAlternative
Robustness is your core differentiatorYou will spend years reaching commercial parityLicence Parasolid or ACIS
Very narrow geometry domainCarrying a general kernel for a small problemCustom narrow kernel
Hard real-time or embedded footprintToo large and not designed for itCustom lightweight engine
LGPL conflicts with your distributionLicence obligations you cannot meetCommercial kernel or custom
Need behaviour deep inside the kernelNot reachable from the public APIFork (costly) or custom

The most overlooked option: narrowing your geometry domain. If your product only handles prismatic parts, or sheet metal, or 2.5D profiles, a purpose-built engine for that domain is far smaller, far more robust, and entirely achievable — while a general kernel is carrying complexity you never use.

A practical sequence

  1. Prototype on OCCT to validate the product concept without committing to royalties.
  2. Collect real customer geometry as early as possible — this is your true test set.
  3. Measure the failure rate on that geometry. This number, not opinion, drives the next decision.
  4. Build the hardening layer and re-measure. Most products stop here, successfully.
  5. Escalate only on evidence — to a commercial kernel if robustness remains the blocker, or to a narrow custom engine if your domain permits.

Running into OCCT robustness limits, or deciding whether to start there? Send us the geometry that fails. See our CAD kernel service, and the kernel comparison.

Frequently asked questions

Yes, with qualification. It ships in real commercial products. But teams that succeed with it invest in a wrapper and robustness layer rather than calling it directly, and they budget for fixing boolean failures on customer geometry. Treating it as drop-in is where projects get into trouble.
Boolean operations failing on geometry that looks perfectly reasonable — typically imported models with tangencies, tiny gaps, or sliver faces. The second most common is memory and exception handling behaviour that surprises teams used to modern C++.
Wrap it first. A wrapper gives you a clean API, centralised error handling and a place to add fallbacks, without inheriting merge pain from upstream. Fork only when you need to change internal behaviour you cannot reach from outside, and expect to maintain that fork indefinitely.