In one paragraph
A CAD kernel is the geometry engine underneath a design application — the code that represents shapes, intersects them, and combines them. It is the hardest and riskiest component of any CAD product, and the decision to build, licence, or extend one shapes your architecture, your pricing, and your timeline.
If you are planning a design, engineering, or manufacturing product, you will meet this decision early, usually before you fully understand it. This guide is written for founders and product leads who need to make it well without becoming computational geometers first.
What a kernel actually does
Think of the kernel as the part of your product that answers geometric questions. Everything the user sees — the sketcher, the feature tree, the viewport — sits on top of it.
| What the user does | What the kernel is asked |
|---|---|
| Draws a rectangle and extrudes it | Create a solid from a closed profile along a direction |
| Cuts a hole through a part | Subtract one solid from another and produce valid topology |
| Adds a fillet to an edge | Construct a blend surface and re-stitch adjacent faces |
| Rotates the model | Tessellate the surfaces into triangles for display |
| Opens a supplier's STEP file | Reconstruct topology from an exchange format, and heal what is broken |
| Exports for machining | Provide accurate surface evaluation for downstream toolpaths |
Every one of those is a hard problem with well-documented failure modes. That is the whole point of this article: the kernel is where CAD products break.
Geometry and topology are different things
This distinction confuses most newcomers and matters enormously to your architecture.
Geometry
- The actual shapes: curves, surfaces, points
- "This face is a cylinder of radius 12mm"
- Continuous mathematics
- Usually NURBS or analytic forms
Topology
- How pieces connect: faces, edges, vertices
- "This face borders that face along this edge"
- Discrete relationships
- Usually a boundary-representation graph
A solid model is topology referencing geometry. Losing either makes the model useless — and most import failures are topology failures, not geometry failures. The surfaces arrive fine; the information about how they join does not.
Why kernels are hard
The short answer is floating-point arithmetic meeting geometric decisions.
- Exact answers from inexact numbers "Do these two surfaces touch?" must produce a yes or no. Floating-point maths produces approximately-zero, and choosing a tolerance turns a mathematical question into an engineering judgement that can be wrong.
- Degenerate cases are the normal case Tangent faces, coincident edges, zero-area slivers. These arise constantly in real models — and naive implementations handle only the clean cases they were tested on.
- Errors compound silently A slightly wrong intersection produces a slightly invalid solid, which produces a badly wrong result three operations later. The user sees the failure far from its cause.
- Imported geometry is hostile Files from other systems arrive with gaps, mismatched tolerances and invalid topology, and your kernel must cope rather than refuse.
This is why robustness cannot be retrofitted. It is determined by the numerical foundations chosen on day one — the predicates, the tolerance model, the topology representation. Teams who plan to "add robustness later" generally end up rewriting instead.
Your three real options
| Option | Cost shape | Best when | Main risk |
|---|---|---|---|
| Licence a commercial kernel | Royalty per seat/deployment | You need broad, proven modelling coverage | Royalties conflict with your pricing |
| Build on Open CASCADE | Engineering time, no royalty | Budget matters and coverage is adequate | Robustness gaps you must fix yourself |
| Build a custom kernel | Large one-time engineering | Narrow, specialised geometry needs | Underestimating the depth of the problem |
The pragmatic middle path most products should take: build on Open CASCADE, but budget explicitly for a hardening layer — wrapping the API, fixing boolean failures on your customers' actual geometry, and adding the operations your domain needs. That gets you most of the way at a fraction of custom-kernel cost.
When a custom kernel is genuinely justified
- Your geometry domain is narrow. A kernel handling only sheet-metal unfolds or only 2.5D profiles is a vastly smaller problem than a general modeller — and entirely tractable.
- Royalties break your business model. A per-seat royalty can be fatal for a low-priced or high-volume product.
- You cannot ship a third-party kernel. Embedded deployment, air-gapped environments, or licence terms that prohibit your distribution shape.
- You need behaviour no kernel offers. Domain-specific operations that would be bolted awkwardly onto a general kernel.
The question is never "can we build a kernel?" It is "how narrow can we make the geometry problem before we start?" Narrowing it is where the real engineering judgement lies.
Questions to answer before you commit
- What geometry do you truly need? 2D profiles only? 2.5D prismatic? Full freeform surfacing? Each step up multiplies the difficulty.
- Whose files must you open? If you must import STEP from arbitrary systems, you inherit healing and tolerance problems regardless of which kernel you use.
- What is your pricing model? This determines whether royalty-based licensing is survivable.
- Where will it run? Desktop, server, browser via WebAssembly, or embedded — each constrains your options.
- What happens when an operation fails? Design the failure path early. Your users will meet it.
A sensible sequence
Prototype on Open CASCADE to validate your product concept without committing to kernel economics. Once you have real users and real geometry, you will know whether robustness gaps, licensing terms, or missing operations are your actual constraint — and only then is a custom kernel a decision you can make on evidence rather than on fear.
Weighing this up for a product? Tell us what geometry you need — we will give you an honest read, including when licensing is clearly the right answer. See our CAD kernel development service.