The CAD Engine You Can't See: Why the Geometry Kernel Matters

When you use CAD software, you normally think about the things you can see.

The drawing tools.

The menus.

The commands.

The 3D viewport.

The rendering.

The file formats.

The features that make one CAD program feel easier or faster than another.

But underneath all of this is something most CAD users rarely think about: the geometry kernel.

The geometry kernel is the mathematical and computational engine responsible for creating, modifying, calculating and maintaining much of the actual geometry in a CAD system.

It is one of the reasons that two CAD programs can appear superficially similar yet behave very differently when you start doing difficult things with real-world geometry.

And it is also one reason that CAD software can sometimes behave perfectly for years, until you encounter one particular model, import one particular file, or perform one particular operation — and suddenly things become complicated.

So what exactly is a geometry kernel, who makes them, and why should a CAD user care?

What is a geometry kernel?

At its simplest, a geometry kernel is a collection of mathematical data structures and algorithms used to represent and manipulate geometric objects.

In a modern 3D modeller, that can include things such as:

• points
• lines
• arcs
• curves
• surfaces
• solids
• edges
• faces
• vertices
• topology
• intersections
• offsets
• fillets and chamfers
• Boolean operations
• surface trimming
• shelling
• healing and repair
• tessellation and faceting
• transformations
• geometric calculations

A CAD application provides the user interface and the higher-level design environment.

The kernel performs much of the underlying geometric work.

For example, when you subtract a cylinder from a block to create a hole, the CAD program needs more than simply displaying a cylinder disappearing from the screen.

It needs to calculate where the two objects intersect, determine which portions of the surfaces remain, create new edges and faces, establish their relationships, and produce a geometrically valid result.

That is kernel work.

Why should a CAD user care?

You don't need to understand the mathematics of a geometry kernel to use CAD.

In much the same way, you don't need to understand how a car's engine works to drive to work.

But the underlying technology becomes important when the software is pushed hard.

Consider some familiar CAD operations:

Fillet an edge.

What happens if the adjoining surfaces are complex?

Offset a surface.

What happens if portions of the offset intersect themselves?

Subtract one solid from another.

What happens when the two solids only touch at an edge or a point?

Import a STEP model.

What happens when the imported geometry contains tiny gaps or tolerance problems?

Modify a complicated model.

What happens to all the dependent geometry when something near the beginning of the modelling process changes?

These aren't primarily interface problems.

They are geometry problems.

And the quality of the underlying geometric algorithms can have a substantial effect on what happens next.

A CAD model is more than what you see

One of the most important concepts in modern solid modelling is Boundary Representation, usually called B-rep.

A B-rep model doesn't simply say:

"This is a box."

It describes the boundary of the object using geometric entities and their relationships.

A simplified example might contain:

• six faces
• twelve edges
• eight vertices

But the important part isn't simply the number of objects.

It is the topological relationships between them.

Which edges bound which faces?

Which vertices belong to which edges?

Which faces form a particular shell?

Which direction does each surface face?

Where does one surface meet another?

The geometry describes the shape.

The topology describes how the pieces of that shape are connected.

That distinction becomes extremely important when a model is modified.

A good modelling kernel therefore has to deal not only with geometric calculations but also with the consistency of the topological structure surrounding those calculations.

Open CASCADE, for example, explicitly separates geometry from topology and provides data structures for vertices, edges, wires, faces, shells and solids, together with algorithms for Boolean operations, fillets, offsets, sewing and shape healing.

Boolean operations are a good test

Boolean operations are among the best ways to demonstrate what a geometry engine actually does.

Suppose you have a rectangular block and a cylinder.

You subtract the cylinder from the block.

Conceptually, that is simple:

Block − Cylinder = Block with a hole

But mathematically, the operation can involve:

1. finding intersections between surfaces
2. determining where those intersections occur
3. splitting surfaces
4. creating new edges
5. determining which pieces belong to the resulting solid
6. rebuilding topology
7. checking whether the resulting model is valid

   Things become considerably more difficult when surfaces are curved, nearly coincident, extremely small, tangent, self-intersecting or affected by numerical tolerances.

   This is one reason that a CAD system can appear extremely fast when drawing simple geometry but behave very differently when performing complicated Boolean operations.

Fillets, offsets and shells are even more revealing

Fillets are another good example.

A simple fillet between two planar faces is relatively straightforward.

But imagine a complicated edge where several curved surfaces meet.

The software needs to determine how the new rounded surface should be constructed and how it interacts with the surrounding geometry.

Offsets create another class of problems.

If you offset a surface, the resulting surface can intersect itself or neighbouring surfaces. Small features can disappear. Edges can collapse. Different portions of the model can collide.

Shelling a solid introduces yet another set of relationships.

The result isn't simply "make everything thinner".

The software has to construct a new set of surfaces while maintaining a valid connected model.

This is where differences in geometric algorithms, tolerances and robustness can become visible to users.

So, who actually makes CAD geometry kernels?

This is where the subject becomes particularly interesting.

There isn't one universal CAD kernel.

There are several major commercial kernels, proprietary technologies developed by individual CAD companies, open-source modelling systems, specialist geometry engines and newer approaches that don't fit neatly into the traditional definition of a kernel.

And they aren't all directly comparable.

Parasolid

Parasolid, developed by Siemens Digital Industries Software, is one of the best-known commercial geometric modelling kernels.

It is licensed to many independent software developers and is used across a wide range of CAD, CAM, CAE and related applications.

Siemens describes Parasolid as a 3D geometric modeller used by more than 200 independent software vendors.

Its capabilities include solid and surface modelling, direct editing, feature-related operations, geometry checking and more.

Parasolid has therefore become one of the major pieces of infrastructure in the CAD industry.

ACIS

ACIS is another major commercial modelling kernel.

It was originally developed by Spatial and is now part of Dassault Systèmes.

ACIS provides a general-purpose 3D modelling foundation covering solid, surface and wireframe geometry and is used by a range of engineering and CAD applications.

ACIS and Parasolid are often mentioned together because they occupy broadly similar territory: both are mature, general-purpose commercial geometric modelling technologies.

That doesn't mean that two CAD applications using different kernels will necessarily behave differently in every respect — nor that two applications using the same kernel will necessarily behave the same way.

The application built around the kernel matters enormously.

Other commercial and proprietary kernels

The CAD kernel landscape is considerably larger than ACIS and Parasolid.

Some of the other names encountered in the industry include:

CGM — Convergence Geometric Modeler

Developed by Dassault Systèmes, CGM is the geometric modelling technology associated with the Dassault Systèmes ecosystem.

It is particularly relevant when looking at the underlying technology behind high-end Dassault applications.

Granite

Granite is PTC's proprietary geometric modelling technology associated with Creo and the broader PTC product development environment.

ShapeManager

ShapeManager is Autodesk's geometric modelling technology.

It originated from ACIS technology and subsequently became Autodesk's own modelling foundation.

C3D Modeler

C3D Modeler, developed by C3D Labs, is another commercial 3D geometric modelling kernel.

It provides functionality for solid, surface and wireframe modelling and is used as a development component as well as in CAD products.

SMLib

SMLib, from Solid Modeling Solutions, is an independent commercial geometric modelling library used in engineering and CAD-related applications.

KCM

KCM is another commercial modelling technology associated with Kubotek.

K3

K3, from Center GeoS, is another example of an independent geometric modelling technology.

DGM

DGM is a geometric modelling technology associated with Chinese CAD development, including CrownCAD-related technology.

There are also numerous proprietary modelling systems developed internally by CAD vendors which aren't necessarily marketed as independent kernels at all.

That is an important distinction.

A CAD company does not have to buy a kernel from an outside supplier.

It can develop its own.

Open-source changes the picture

Commercial kernels aren't the only option.

The most significant open-source example is probably:

Open CASCADE Technology

Open CASCADE Technology, usually abbreviated to OCCT, is an open-source 3D modelling SDK.

It provides geometry and topology data structures, modelling algorithms, Boolean operations, fillets, offsets, shape healing, data exchange and many other functions required to build CAD/CAM/CAE applications.

It is particularly interesting because it isn't merely a research project or a small geometry library.

It has been used as the foundation for a substantial range of commercial, industrial, scientific and open-source applications.

OCCT is available under the LGPL and provides a genuine alternative development route for organisations that don't want to license a proprietary kernel such as Parasolid or ACIS.

BRL-CAD takes a different approach

Another fascinating open-source project is BRL-CAD.

BRL-CAD has an unusually long history, dating back to the late 1970s, and is an open-source solid modelling system with a strong Constructive Solid Geometry heritage.

Its geometry system supports multiple representations, including CSG primitives, NURBS/B-rep geometry and faceted meshes.

Rather than being simply an open-source clone of a commercial parametric CAD kernel, BRL-CAD represents a somewhat different modelling philosophy.

That makes it a useful reminder that "CAD kernel" does not necessarily mean "Parasolid-like B-rep kernel".

What about CGAL?

CGAL — the Computational Geometry Algorithms Library — is another major open-source project worth knowing about.

CGAL provides a large collection of computational geometry algorithms and data structures.

However, it should not simply be described as an open-source equivalent of Parasolid.

Its scope is broader and different.

It is extremely useful for computational geometry, mesh processing, arrangements, triangulations, spatial searching and many other tasks, but a developer building a complete commercial parametric solid modeller may use it very differently from the way they would use a traditional CAD modelling kernel.

That distinction matters.

And then there is DG Kernel

You may also encounter DG Kernel in discussions about CAD development.

This is an interesting example because the word "kernel" can mean slightly different things in different parts of the software industry.

DG Kernel is a higher-level CAD development framework built around Open CASCADE technology rather than simply being another independent geometric kernel directly comparable with Parasolid or ACIS.

That makes it useful for developers who want a higher-level development environment while still taking advantage of underlying geometric modelling capabilities.

A new generation: Dyndrite

Perhaps one of the most interesting departures from the traditional CAD-kernel model is Dyndrite.

Dyndrite developed a GPU-oriented geometry engine designed particularly around advanced manufacturing and additive manufacturing workflows.

Its technology is designed to work with multiple geometric representations, including B-rep/spline geometry, meshes, implicit geometry, voxels, point clouds and volumetric meshes.

It is also designed to take advantage of CPU and GPU computation.

This is significant because it points towards a possible change in the definition of a geometry engine.

Instead of assuming that everything must ultimately be reduced to one traditional representation, a newer generation of systems can work with several representations simultaneously.

That is increasingly relevant as CAD, scanning, simulation, generative design and additive manufacturing converge.

A useful way to look at the kernel landscape

Rather than thinking of CAD kernels as a simple list, it is more useful to think of them in families.

The table is deliberately described as a broad classification, rather than a ranking.

Some of these technologies are direct competitors in particular development scenarios; others aren't.

The same kernel does not mean the same CAD program

This is one of the most important points to understand.

Suppose two CAD products both use Parasolid.

It does not follow that they will perform identically.

The kernel is only one part of the system.

The application developer decides how the kernel is used.

The CAD application may add:

• its own feature history
• its own constraint system
• its own object model
• its own tolerance strategy
• its own file format
• its own import/export translators
• its own healing routines
• its own regeneration system
• its own graphics system
• its own assembly architecture
• its own memory management
• its own multithreading strategy

The same applies to ACIS, Open CASCADE and other kernels.

A good kernel can make good CAD software possible.

It cannot, by itself, guarantee good CAD software.

Imported models are a particularly good test

Importing geometry from another CAD system is one of the places where the underlying technology can become particularly important.

A STEP or other neutral-format file may contain perfectly legitimate geometry, but that doesn't necessarily mean that the receiving application will be able to use it perfectly.

There can be:

• tiny gaps
• tolerance differences
• coincident surfaces
• imperfect edges
• missing topology
• unusual surface constructions
• very small faces
• self-intersections
• inconsistent geometric data

A receiving CAD system may therefore need to perform healing or repair operations.

This is not necessarily evidence that the original CAD system was "wrong".

Different systems can have different tolerances, representations and modelling assumptions.

The quality of the receiving application's translation and healing process therefore matters just as much as the underlying kernel.

CAD is becoming less purely B-rep

For decades, conventional mechanical CAD has been strongly associated with B-rep solids and surfaces.

But modern design increasingly involves other forms of geometry.

For example:

• point clouds
• scanned meshes
• subdivision surfaces
• topology-optimised forms
• lattice structures
• implicit geometry
• voxel representations
• volumetric meshes
• generative geometry
• additive manufacturing geometry

A modern application may therefore have to deal with several fundamentally different representations.

That creates a new challenge.

How do you edit a traditional B-rep solid and a scanned mesh in the same workflow?

How do you create a lattice inside a solid?

How do you take a mathematically precise CAD model and turn it into something suitable for a 3D printer?

How do you maintain accuracy when moving between representations?

These are not problems that the traditional CAD kernel model was necessarily designed around.

Hybrid geometry may be the future

The idea of a single model representation may increasingly give way to hybrid geometry.

A model might contain:

• precise B-rep surfaces
• NURBS
• polygonal meshes
• implicit geometry
• point clouds
• volumetric representations

and the software may need to operate on several of them without continually converting everything into triangles.

Dyndrite is one example of a geometry engine explicitly designed around this sort of multi-representation approach.

Open CASCADE has also continued developing capabilities around B-rep, mesh and data-exchange workflows.

And commercial kernels such as Parasolid continue to evolve beyond the traditional solid-modelling problems that originally defined them.

The direction is clear even if the eventual architecture is not.

The geometry engine of the future may look rather different from the geometry engine of the past.

What about performance?

When people talk about CAD performance, they often mean the graphics.

"How many frames per second does the viewport display?"

But geometry computation is a different problem.

A CAD program can have an extremely fast graphical display while taking a long time to calculate a difficult Boolean operation.

Conversely, a program can appear visually modest while performing complex geometric calculations efficiently.

There are therefore several different kinds of CAD performance:

Display performance

How quickly can the application draw the model?

Geometric performance

How quickly can the kernel calculate operations?

Regeneration performance

How quickly can the application rebuild the model after a change?

Data-exchange performance

How quickly can it import, translate and heal external geometry?

Assembly performance

How efficiently can it manage large numbers of objects?

Memory performance

How much data can it manipulate without exhausting available resources?

Parallel performance

How effectively can it distribute appropriate calculations across multiple CPU cores or GPUs?

A "fast CAD program" therefore isn't necessarily one that simply produces a high frame rate.

So how should you evaluate CAD software?

If you're choosing CAD software, asking:

"Which kernel does it use?"

is a reasonable question.

But it shouldn't be the only question.

A much better approach is to test the actual work you need to do.

Try:

1. Real-world Boolean operations

   Don't just subtract two cubes.

   Use the sorts of geometry you actually encounter.

2. Difficult fillets

   Test complex edges and changing radii.

3. Offsets and shells

   These can expose geometric limitations surprisingly quickly.

4. Imported models

   Bring in STEP, IGES, SAT, DXF, DWG or whatever formats your business actually receives.

   Then try editing the result.

5. Imperfect geometry

   Real-world models aren't always perfect.

   See what happens when the software encounters gaps, tiny faces or awkward intersections.

6. Changes to existing models

   Don't just create a model.

   Modify it.

   See what happens to everything that depends upon the geometry.

7. Large projects

   Test the size of drawings and assemblies that you actually use.

8. Downstream operations

   A model isn't finished simply because it displays correctly.

   Try dimensioning it, sectioning it, exporting it, rendering it, manufacturing it or sending it to another system.

The kernel is only part of the answer

It is tempting to think of a geometry kernel as the "engine" and the CAD application as little more than the dashboard.

That analogy isn't entirely wrong, but it is incomplete.

A modern CAD application is a complex stack.

At the bottom there may be a geometry engine.

Above that may be topology and data-management systems.

Above that may be feature modelling, constraints and parametric history.

Then come assemblies, drawings, annotations, file management, translation, rendering, simulation and the user interface.

A weakness anywhere in that stack can affect the user.

That's why two products using the same underlying kernel can still provide completely different experiences.

The future may make the kernel even more important

Artificial intelligence is now entering CAD.

So are generative design, automated feature recognition, real-time simulation, increasingly sophisticated manufacturing workflows and increasingly large models.

These technologies all place new demands on the geometry underneath.

An AI system might be able to say:

"Put a 10 mm fillet on these edges."

But somebody still has to calculate the resulting geometry.

An automated design system might generate thousands of alternatives.

Those alternatives still need to be represented, modified, evaluated and exported.

A generative system might produce a complex lattice.

That lattice still has to become usable manufacturing geometry.

AI can change the way we tell CAD software what we want.

It doesn't eliminate the mathematical problem of actually creating the geometry.

In some respects, it could make the underlying geometry engine more important, not less.

The CAD kernel you never see

Most CAD users will never knowingly interact with a geometry kernel.

There will be no "Parasolid" button.

No "ACIS" command.

No "Open CASCADE" menu.

And that is exactly how it should be.

A good geometry engine should largely disappear into the background.

You ask the software to create a shape.

It creates it.

You change the shape.

It rebuilds it.

You import another model.

It opens.

You make a Boolean.

It works.

You apply a fillet.

It succeeds.

You export the result.

It remains usable.

When all of that happens reliably, the kernel is almost invisible.

It is only when something fails that most users discover that there is a remarkably sophisticated mathematical machine underneath their CAD software.

And that is why the geometry kernel matters.

Not because one particular kernel is automatically "the best".

Not because a CAD application's marketing department can put a famous kernel name on a feature list.

But because the quality of the underlying geometry engine, combined with the way the CAD developer uses it, can fundamentally affect what the software is capable of doing.

The real test isn't the name of the kernel.

The real test is what happens when you give the CAD system your hardest work.