Before the roadmap, the honest caveat: most products should not build a kernel. Licence Parasolid or ACIS, or build on Open CASCADE. This article is for the minority whose geometry domain is narrow enough, or whose licensing constraints are hard enough, that building is genuinely the right call — and it is written to show how much work that is.

Stage 0 — Narrow the problem

The single most valuable engineering decision happens before any code. Answer precisely:

  • What geometry do you actually need? 2D profiles? 2.5D prismatic? Freeform surfaces? Each step multiplies difficulty.
  • Whose files must you open? Arbitrary STEP import brings tolerance and healing problems regardless of anything else.
  • Which operations are essential? Extrude and boolean, or full filleting and shelling?
  • What precision does your industry require?

Every honest kernel roadmap begins by deleting requirements. A kernel that does three operations perfectly is achievable; one that does thirty adequately is not.

Stage 1 — Foundations

Nothing above this layer can be more robust than this layer. Build it first and test it exhaustively.

  1. Geometric predicates — orientation and in-circle tests using exact or adaptive-precision arithmetic. These are the decisions everything depends on.
  2. Tolerance model — decide now whether tolerance is global or per-entity. Per-entity is harder and survives imported data; global is simpler and fails on it. Changing later is a rewrite.
  3. Basic types — points, vectors, transforms, with consistent conventions.
  4. Curve and surface evaluation — NURBS evaluation, derivatives, and analytic forms kept analytic.

Stage 2 — Topology and validity

Before any operation that creates geometry, build the structure that holds it and the code that checks it:

  • B-Rep data structure — half-edge or winged-edge, with vertices, edges, loops, faces, shells, solids.
  • Validity checking — manifoldness, consistent orientation, closure, no duplicate or dangling entities.
  • Construction primitives — box, cylinder, sphere, built directly and verified valid.

Write the validity checker before the first operation. It is the instrument you will use for the rest of the project. Every operation ends by asserting its output is valid, so corruption is caught where it happens rather than three operations downstream — which is the difference between a debuggable kernel and an inscrutable one.

Stage 3 — Intersection

The hardest single component, and the foundation of booleans:

  1. Analytic-analytic intersections first — plane/plane, plane/cylinder. These are exact, common, and give you a robust base.
  2. Analytic-NURBS — numerically solved but well behaved.
  3. NURBS-NURBS — marching or subdivision methods, with tolerance-aware curve output.
  4. Degenerate case handling — tangency, coincidence, and zero-length results detected explicitly rather than emerging from the general algorithm.

Stage 4 — Boolean operations

Only now, with predicates, validity checking and intersection in place. Expect this stage to take longer than you plan, because it is where all the earlier foundations get tested against reality.

  • Split faces along intersection curves.
  • Classify resulting pieces as inside or outside.
  • Assemble and stitch the kept pieces.
  • Validate the result before returning it.
  • Handle failure gracefully — report, do not corrupt.

Stage 5 — Tessellation and interoperability

  • Adaptive tessellation with controllable chord tolerance, and crack-free across shared edges.
  • STEP and IGES import with a healing pipeline — stitching, gap repair, tolerance reconciliation.
  • Export in the formats your users exchange.

Stage 6 — Higher-level operations

Filleting, chamfering, shelling, offsetting, drafting. These are built on booleans and intersection and are where the long tail of edge cases lives. Filleting in particular is deceptively hard — the blend surface must be constructed and re-stitched, and variable-radius and corner cases multiply quickly.

Testing, throughout rather than after

Test typeCatches
Unit tests on predicatesNumerical foundation errors
Validity assertion after every operationCorruption at its source
Fuzz testing near degeneracyThe failures clean tests never find
Real customer geometry corpusWhat actually breaks in production
Mass property comparisonSilently wrong results

The fuzz testing point deserves emphasis: perturb geometry by nanometres and microradians around degenerate configurations. Clean models pass trivially and prove nothing.

Realistic scope by ambition

ScopeRealistic effortFeasible?
2D profile kernel4–8 monthsYes
2.5D prismatic solids9–18 monthsYes, with focus
General B-Rep with freeformMulti-yearRarely justified
Commercial-parity kernelMany yearsNo

Considering a kernel and want an honest scoping conversation? Tell us the geometry you actually need — narrowing it is usually where the value is. See our CAD kernel service, why booleans are hard, and the kernel comparison.

Frequently asked questions

A narrow kernel for a restricted geometry domain — 2D profiles, or prismatic solids only — is realistically 9–18 months to production quality. A general-purpose kernel competitive with commercial offerings is a multi-year programme, which is why almost nobody should attempt one.
Building operations before building validation. Teams implement booleans, get them working on clean test models, and discover months later that they fail on real geometry with no framework for diagnosing why. Validity checking should exist before the first boolean is written.
Almost always 2D, even if you need 3D eventually. A 2D kernel exercises the same foundations — predicates, tolerance handling, topology validity — at a fraction of the difficulty, and the lessons transfer directly. Teams who start in 3D usually rebuild their foundations later.