How MTK is different from CAD geometric kernels

Most CAD kernels are built to construct geometry. MTK is built to understand it. This subtle difference leads to a very different system - one that’s optimized for analyzing messy CAD files, extracting manufacturing features, and scaling across thousands of parts in quoting workflows.

If you’ve ever worked with Parasolid, ACIS, C3D, or Open CASCADE, you know what a geometric kernel does. It builds geometry. It lets you extrude sketches, create blends, stitch faces, and perform boolean operations. These kernels are the foundation of most CAD authoring systems.

MTK was built for something else entirely. It doesn’t aim to recreate a CAD model. It tries to understand it.

This single shift - from authoring to interpretation - leads to a very different architecture. Different priorities. Different algorithms. And ultimately, a different kind of product.

Let’s go through the differences one by one.

Data structures: kernel-like, analysis-ready  

MTK uses a boundary representation (B-Rep) at its core - just like Parasolid, ACIS, or Open CASCADE.

Faces, edges, loops, and vertices are explicitly modeled. Curves and surfaces are parametrized. Topology follows classical Euler structure.

That’s deliberate.

Many manufacturing tasks - like feature recognition or unfolding - depend on the same kind of clean, topologically-connected geometry that CAD kernels rely on.

So we keep that structure, almost 1:1.

But MTK also accounts for realities beyond B-Rep:

• Many real-world workflows involve triangulated meshes (e.g. STL files for quoting). MTK supports both meshes and B-Rep side by side, with a unified API.
• Persistent IDs are supported throughout - they are critical for tracking faces across feature recognition, DFM checks, and web visualization.
• We try to not degrade topology. We parse as much as possible from the input, just like a geometric kernel would. But we also ensure the data remains analyzable - even if the input is imperfect.

In short: MTK preserves the structure and rigor of a modeling kernel, but makes it usable for analysis at scale, across a wide range of formats and workflows.

Modeling algorithms: building vs understanding  

Traditional kernels are packed with modeling operations: extrusion, filleting, shelling, sweeping, lofting, etc. They’re designed for users to create geometry step by step.

MTK doesn’t do that.

Instead, it provides algorithms to analyze and interpret geometry that already exists - especially in the context of manufacturing.

For example:

• Is this boss a functional feature or just cosmetic?
• Does this part have undercuts that make it impossible to machine?
• Can this sheet metal bracket be unfolded and cut from flat stock?

These aren’t authoring operations. They’re reasoning tools. And they require different internal logic, tolerancing rules, and robustness strategies.

Сomputations: from basic geometry to manufacturing-grade analysis

Most CAD kernels offer a standard set of geometric computations: bounding boxes, surface areas, volumes, centroids, geometry evaluations (curve points and tangents, surface normals, etc). These are useful, but they only scratch the surface of what manufacturing workflows actually need.

MTK builds on those foundations and goes further - providing analysis tools specifically designed for real-world production.

This includes:

• Wall thickness computation - critical for injection molding and lightweighting.
• Draft angle analysis - to assess moldability and detect undercuts.
• Projection areas - used in cost estimation and material usage.
• Stock and billet estimation - to help select blanks before CAM starts.

These aren’t just academic algorithms - they’re designed to work reliably on imperfect geometry imported from STEP or STL, without requiring manual repair.

Manufacturing algorithms: beyond the kernel  

Here’s where MTK steps completely outside the scope of traditional kernels. We don’t just expose geometry. We explain what it means in manufacturing terms.

This includes:

• Feature recognition: pockets, holes, slots, fillets, bends, bosses.
• DFM checks: minimum wall thickness, deep holes, missing radii in corners, undercuts.
• Unfolding: flattening sheet metal into manufacturable patterns.

In most CAD kernels, these aren’t part of the product. They’re left to downstream CAM or PLM tools.

In MTK, they’re core modules - not plug-ins, not afterthoughts.

Constraint solvers: we don’t need them  

Sketch solvers and constraint engines are critical in authoring environments. You can’t build a parametric model without them. Some kernels natively include them. Some partner with other vendors.

But MTK doesn’t create sketches.

It processes fully-defined geometry from imported CAD models. So instead of solving constraints, we focus on evaluating what’s already there.

PMI and metadata: not optional  

In most kernels, metadata like materials, or part numbers is either ignored or left to external systems. Tolerance has a special (geometrical) meaning in the context of a kernel.

But in quoting workflows, metadata is just as important as geometry. You can’t price a part without knowing the material or if the tolerance is ±0.1 vs ±0.01.

That’s why MTK makes PMI and metadata part of the model:

• Dimensions, tolerances, and notes are parsed and stored structurally.
• Custom property tables (e.g., key-value pairs from STEP) are available in API.
• Annotations can be linked back to faces and features.

It’s not just nice to have. It’s required for the job.

Web visualization: built-in, analysis-aware  

Geometric kernels often don’t care how their results are displayed. Visualization is the job of another layer.

In MTK, we ship a full web visualization component - because we believe inspection and collaboration are part of the workflow.

More importantly:

• It’s not just a viewer. It knows about features, checks, results.
• You can highlight all machinable pockets, color-code DFM issues, or trace back a warning to the face that caused it.

It’s one thing to run analysis. It’s another to explain it visually to an engineer or customer.

CAD import: built for the messy real world 

Most kernels assume you’ll feed them native data - or clean, well-prepared STEP. But if you’ve worked in manufacturing, you know that’s rare.

MTK is built for messy input:

• Sloppy STEP files with slim surfaces or wrong edge orientations.
• STL files with thousands of triangles but no part metadata or even connectivity.
• DXF profiles with overlapping curves and no layer structure.

We maintain our own importers and healing logic, tuned specifically for this mess. Because that’s what our users see every day.

Summary table

Conclusion

MTK is not trying to be “the next Parasolid.” We respect those kernels - they’re foundational. But we’re solving a different problem.

If your job is to model geometry, you need a CAD kernel. If your job is to analyze CAD data, price parts, check for manufacturability, and build quoting workflows - then you need MTK.

• Try it in our online demos or explore the documentation.
• If you’ve built similar tools, I’d love to hear how you approached it.