Geometric Kernel for Digital Manufacturing

A really long preamble

Back in 2022, we delivered a presentation of our services in a local "Computational Geometry" workshop. The occasion was a small event backed by a well-known corporation and we prepared carefully. To me, this meetup was another milestone: the former OCC team was parting ways with the parent company and there were a lot of rumors about possible directions for the future development of the kernel. Back then, our team had already been independent for a couple of years, so we used this opportunity to summarize our experience and talked publicly about the things we were up to.

Over the past 5 years, it has become evident that most of the algorithms, data flows, and computation principles we've been practicing can be summarized under the umbrella of a software development kit (SDK). The idea is nothing new: there is something to reuse and resell from one client to another, so you turn this reusable thing into a separate package and bring it to the market. Supplemented with customization services, this package becomes an offer not only to buy something but also to work on a problem together with your customer. We jargonized this offer as an "MaaS kernel" to draw a parallel between a general-purpose geometric modeling kernel (like OpenCascade, ACIS, or Parasolid) and our tools. Technically speaking, it remained the same OpenCascade but was empowered with more libraries related to:

• Feature recognition
• Assembly management
• Geometry preprocessing (simplification, healing)
• Direct editing
• Specialized data exchange
• etc.

This "MaaS kernel" is being developed in the Analysis Situs SDK, both its open-source and commercial components. The architecture is not monolithic and is well illustrated by the following diagram:

Analysis Situs SDK.

Among other things, the CG event served as a forum for discussing the future of the OpenCascade library. There have been different opinions on where it should go and how. One school of thought is to evolve OpenCascade by specializing it to specific needs. E.g., if we are building a direct modeler (or editor), we have to focus on the core modeling functions, such as Booleans or defeaturing. If all we need is the data conversion, then let's probably focus more on the API functions employed in the CAD translators (e.g., spline approximation will be one of such). Our use case is more of a CAM domain, so we can push the development of a kernel in this direction better than in others.

The hard thing is that a CAD kernel isn't really a source of innovation anymore. It is rather a commodity. At least, this is what people expect from a CAD kernel. The days of innovative development in Boolean operations or surface-surface intersections are clearly gone, and we are mostly left without a reliable and good-enough general-purpose CAD kernel. We are trying to catch a departed train, trampling our feet until they bleed, while gentlemen who paid for tickets enjoy swift travel with their icy umbrella drinks. There is also this constant question of human resources and money you must burn to feed OpenCascade development. Unless you have several million dollars, this question is not that trivial. My absolutely random estimate would be about 5 people for 5 years of full-time development to contribute meaningful changes to the library. It's not the cheapest thing to do, of course. But the main question is not money and time. It's the purpose and the goals you set for the kernel development, because this is what defines your roadmap.

Funding the development of yet another geometric modeling kernel for the sake of having yet another geometric modeling kernel is a bad idea in many aspects, starting from the financial side of things and ending up with the inevitably poor quality of the code that is not used by any significant community of engineers. Our "MaaS kernel" is based on the well-established OpenCascade core, where we accumulated decades of experience and that is used by thousands of companies over the globe. We have a well-defined plan to transform it into a robust product that caters to the CAM market in its MaaS dimension. This intention of building up the "MaaS kernel" is not a startup idea whatsoever. This idea has been organically crystallized from dozens of custom development projects where we've been implementing the same and similar algorithms over and over again.

Today we see companies like PaperlessParts, DigiFabster, SecturaFab, QuotationFactory and many others that expose more or less the same API. No matter which geometric kernel they use under the hood and how much AI wording their sales put into PowerPoint decks, they are all from the same family of software components. And our MaaS kernel aims at providing a general-purpose API for platforms like the listed ones.

The place of AI in CAD feature recognition

This topic could have been another side thread in our MaaS talk but back in 2022 we did not hear this AI hype loud enough. For anyone interested in learning from the leaders, I would definitely recommend the following podcast from The Fabricator magazine: "Practical approaches to using AI in manufacturing and fabrication." While the whole discussion was definitely worth the time, the most interesting piece is, in my opinion, the message delivered by Caleb Chamberlain of OSH Cut (a top-tech US company for sheet metal fabrication). Here is the quote:

"Honestly, I think that stuff like DFM will probably make sense to be done from first principles for the foreseeable future. By first principles, I mean, hey, model the part, model the break, run a collision check, and render it. That's first principles. An AI large language model is using these massively scaled-up neural networks to create these complex results, and I think to the extent that you can just take a relatively physical real-world system and just model it, that's always going to be better."

The same goes for CAD feature recognition: you do not need a large, overly trained language model to understand that a bottom face is concavely connected to a contour of perpendicular walls. It's the computational geometry question that was answered in a trivial way by something called a "Geometric Modeling System" back in the '70s. CAD feature recognition can be done entirely based on Caleb's "first principles," and the real intelligence here will likely be avoiding anything "artificial" in a well-defined geometric problem.

Having said that, let's not pretend that AI is useless in our domain. It is useful but for another purpose. You can still predict fabrication costs based on AI models and you can basically use them for any other type of similar approximation where a CAD is the input and a number is the output. In this context, a CAD feature recognition subsystem is employed as the data source for training a neural network. It quantifies the CAD geometry in a way that can be used by AI. You may want to read more about our take on this issue here: "Interfacing rule-based feature recognition with machine learning (AI) methods."

But Analysis Situs is all about Caleb's "first principles." So let's dive into the presentation now.

The talk

Below I will reproduce the main ideas we presented at the CG event, followed by the corresponding slide deck. This whole thing is reduced quite a bit, so only key topics are highlighted.

The idea for the front cover and a few other illustrations down the road was borrowed from A. McKay and A. de Pennington, whose paper I was pleased to review the other day. The talk is devoted to a "MaaS kernel," which we define as an SDK to address some typical needs of an "online manufacturing-as-a-service platform." After many years of working in this niche of CAD development, we were able to crystallize the common thing behind this whole business. Because we are being contacted by start-up companies aiming at building their own MaaS solutions, it feels like this presentation can help CTO people understand better what they are actually looking for. Of course, people are often referring to existing systems that they wish to reproduce and make better, but let's avoid any companies' names and focus on the common core.

Just to state the fact, our core team is compact yet highly experienced. All of us have a long story contributing to CAD software, including end-user products and low-level math of geometric modeling kernels. All of us participated heavily in the development of the OpenCascade geometric modeling kernel starting in the days when it was built using WOK. Somehow, the history of the kernel has become our own history, with youth, middle ages and retirement phases all together. Aside from this, our team contributed more than 600k lines of code to open-source Analysis Situs and Mobius projects, and this journey has only begun.

In the field of industrial geometric modeling, public dissemination of knowledge about low-level CAD/CAGD algorithms is a good style. Equipped with the proper theoretical mindset, the future generations of CAD researchers and developers will have a more profound idea of how low-level CAD works. Publishing openly is a part of our profession, and we keep dedicated to providing scholarly contributions to the field of geometric modeling.

Analysis Situs started as an educational software package. Within the frames of the European IODA project, we conducted a workshop about computational geometry. To make a talk a little less boring, we prototyped a compact VTK-based software package with three viewers to display a CAD part, the host geometry of a single B-rep primitive and its trimming contour. The idea was to illustrate the mechanics of B-rep. It became clear after a while that a tool for CAD model inspection is just a proper foundation for a feature recognition and shape interrogation system.

After ten years of development, Analysis Situs has proven to be a successful project. Just several months after the first version was compiled, I found myself using it more often than Draw. Today I do not remember when I launched Draw for any productive use last time. My sole prototyping workbench is Analysis Situs and its functionality continues to expand. With this tool as a basic framework, we developed a number of new algorithms, including the vast majority of feature recognizers. We also developed the commercial CAD Processor, having Analysis Situs as a main prototyping environment. Now, since our team is independent, we base our commercial offers on the Analysis Situs SDK.

As this talk is devoted to MaaS, let's highlight the key feature of Analysis Situs with respect to digital manufacturing: the open-source feature recognition SDK. A normal user starts with the interactive application where you load a CAD model and check its contents by clicking through the CAD faces. Besides the 3D visualization, Analysis Situs works in a pure batch mode and exposes its C++ API for software developers.

The added value of Analysis Situs lies in its implementation of the Attributed Adjacency Graph (AAG), rule-based feature recognizers and the pattern-matching algorithm based on the dictionary of features. There is also a bridge between AAG and trendy machine learning tools such as UVNet. The feature recognition framework is supplemented with the corresponding modeling core. We develop a range of specific algorithms for defeaturing, direct editing, shape conversion, shape interrogation and more. As practice proves, feature recognition needs to be backed by a powerful modeling kernel in order to extract various properties of the detected features and facilitate manufacturability checks. And this modeling core is open-sourced in our case. We do not compete with Parasolid or ACIS; we just do it differently: in a completely open way.

MaaS is a fancy term that describes a clear business case. A customer wants to get a part fabricated and he has a "digital drawing" of a product (e.g., a CAD model). He communicates this "drawing" to a specialized CAD service (normally, just sends it over the Internet) and gets back a couple of outcomes: the manufacturability report, the quotation, and the delivery date. The quotation and DFM checks can be done at the target shop or by an intermediate broker. How this communication process is done defines several types of MaaS architecture.

The first case is a hub. The customer sends his design to a centralized platform and the platform delegates the job to one or another manufacturer. Normally, it is the hub that decides on the price. The connected (and certified) manufacturers can pick up the already preprocessed order from a centralized platform if they ensure to have all the required tooling and capacities.

The second case is when an MaaS platform belongs to a manufacturer. It is often the case when a shopfloor prefers to keep the entire order processing logic at their premises, aiming at higher flexibility. In such a case, the manufacturer acts as a software developer because it is the manufacturer who has to create and maintain the MaaS CAD service bottom-up.

Another case is when an MaaS platform is being developed as a box product that is then installed or given access to among several manufacturers. The shop itself just uses the platform provided by a vendor and does not bother with developing such a complex piece of software on its own. It's not a hub, though: from the customer's point of view, the platform belongs to the manufacturer. The user who uploads a part for quotation does not know that the manufacturer licenses the MaaS service from a 3rd-party provider. The user does not care. But we do.

The last case is when MaaS is integrated as a plugin to CAD software. The user may stay in his favorite design tool when placing an order, but there should still be a remote part of a CAD service: one of the three options mentioned above: a hub, a self-hosted solution or a licensed software package.

Staying on the ground of computational geometry and deterministic pricing models, we claim that all the mentioned cases may benefit from the same common core: the MaaS kernel. A MaaS kernel to a MaaS platform is the same thing as a CAD kernel to a CAD system.

From all the logistics around MaaS platforms, we, as computational geometry engineers, care only about price and manufacturability feedback.

When a CAD design is uploaded, we need to be able to check the production method first and answer the very basic question: do we have all the required machines in our park to fabricate the part in question?

If yes, then let's have a closer look at a design in terms of its features. Are all features machinable? If yes, do they all come with a reasonable manufacturing effort?

The more precise rules you build on top of a feature recognizer, the better price you can give. The quotation platform should also avoid automatically pricing parts that expose manufacturing difficulties. To avoid high prices that drive your clients away, it might make more sense to give a client a manufacturability report first. Once all the issues are addressed, it's the right time to price the part.

The overview of a typical quotation workflow brings us to the following key opportunities for automation:

• Automate design validation by DFM checks;
• Automate price calculation by predicting the required machining time.

Both topics are challenging and require proper geometric and algorithmic support. Let's talk about the API of a geometric system that could address these two challenges.

We presume that there is already a general-purpose CAD modeling kernel, such as ACIS, Parasolid or OpenCascade, that we use for working with CAD geometry. It appears that literally all quotation platforms use one or another kernel, and it also seems that OpenCascade is a brilliant choice for exactly this use case. It is free, it is flexible, and it works well with the existing CAD designs created somewhere else. But at the same time, the modeling kernel is not enough. It just does not have the required functions to assess the manufacturability of a part, feature-recognize it and derive machining time from the dumb geometry. But what do we actually need from a CAD kernel to make an MaaS solution possible?

It all begins with reading a CAD file, be it a single part or an assembly. Let's focus on a single part in this talk with a remark that adding assemblies is quite a simple technical question.

The vast majority of our clients use the STEP format at the input. For better user experience, some prefer plugging in native data converters, e.g. SolidWorks or Inventor. Adding more data exchange formats does not add anything to the workflow except for a more extensive list of file formats to choose between. Therefore, proprietary file formats are often added as a "luxury" feature. Analysis Situs has a bridge with a well-known vendor of data connectors, so adding more input formats is not a big deal technically.

Whichever CAD format we use as the input, what we need to get from it is the B-rep geometry and optionally the assembly structure. All other metadata, including colors and GD&T, is normally out of the question, so it should not come as a surprise that even with the native formats as the input, we do not import any design features to work with. The thing is that manufacturing features are generally different from the design features and therefore they must be extracted from the model as if they never existed there.

The imported boundary representation (B-rep) needs to be expressed with canonical forms. Feature recognizers in the MaaS domain do not work on meshes (with the exception of 3D printing). Also, splines should be used with care: if a feature can be expressed without them, it should be. If splines are still popping up, they normally have to be converted to canonical shapes first. We do this with our open-sourced CANCONV operator.

As mentioned earlier, assemblies cannot be ignored, as more often than not users upload multibody parts and complex CAD products for automatic quotation. In such cases, we need to extract BOM (bill of material), i.e., to list all unique parts and their quantities. This is also done by our open-sourced component for traversing assembly hierarchy.

Now let's look closer at the geometry of a part. Feature recognition in essence is like coating our part in different dresses depending on the identified production method and the analysis goal we set for ourselves. For example, in the image above, we are interested in thin walls that we would consider as ribs and expose to thickness analysis.

Alternatively, we might want to look at a part from the perspective of subtractive manufacturing (milling). The questions to answer then are different: how much of the raw material is to be machined out? Are there any sharp corners that are difficult to fabricate? Are there any zones that are not accessible by the tools we have? These and similar questions are so fundamental that we cannot be sure if a part is manufacturable if we don't answer them all. Now imagine that you have to quote dozens and hundreds of such parts every day. How much easier would it be if there was an accompanying software package doing this for you?

Whichever perspective we put on a part, such smart software would necessarily have two key ingredients: shape interrogation as the basic modeling API and feature recognition for extracting the design intent.

So we arrive at three bullets here:

• Data exchange for importing and exporting CAD files.
• Feature recognition for looking at a part under different perspectives.
• Common modeling API for shape interrogation and DFM analysis.

These ingredients constitute a generic MaaS kernel that can be used for process planning, quotation and manufacturability checks.

There are some other useful services provided by a MaaS kernel. For example, our customers often want to have little thumbnail images for previewing the processed CAD parts. Very often it's a raster format like PNG, which is generated in a headless manner (i.e., without UI and even without GPU) with configurable appearance properties (colors, background, lighting, etc.).

If you want to go for a real 3D preview, there is such an option as well. The standard de facto for 3D visualization on the web is the Three.js framework, where you can load a glTF file. We make sure to keep all features reported as groups in the mesh-based glTF outcomes so that you can match the reported face IDs with specific triangles in the viewer. We have an online demo viewer that is publicly available to see these mechanics in action. The viewer is open-sourced, so our customers can quickly get up to speed by customizing it or simply reusing some ideas or code.

Let's talk about different production methods, because they define which feature recognizers to use. For example, feature recognition algorithms employed for sheet metal interrogation would not be suitable in a more generic CNC domain. Also, there are different subtypes of production methods, like rolling in sheet metal or 3D milling in CNC. We need to be able to cope with all these complexities to give a CAD part the care it deserves.

In the CNC milling domain we distinguish between pure CNC milled, turned, and turned+milled parts.

In sheet metal, we started with classic bent parts that are usually made on press brake machines. Such parts need to be flattened out with a proper k-factor at bends. We published many articles (including scientific papers) to explain how these algorithms work.

Besides bending, such processes as rolling are not uncommon. Moreover, there are cases that mix both production methods: bending and rolling. The MaaS kernel should be able to treat rolled flanges equally well.

Let's dive a little deeper into the feature recognition discipline to uncover some of its non-obvious complexities.

Let's start from the beginning. In traditional CAD software, you normally build a part in terms of its design features, such as sketches, holes, pockets, slots, embossings, etc. In the vast majority of cases, these features are parameterized and arranged in a history tree that allows you to reevaluate the geometry of a part once you change some of the design variables. The responsiveness of a design to change is encoded in this history tree: whenever you change something, you get back to the originating CAD system to reevaluate the geometry.

In contrast to this, there are direct editing software packages that do not employ history trees. Instead, they come with a bunch of powerful algorithms that are able to recognize the design intent as you go and alter the geometry based on inline feature recognition. In such systems, the responsiveness of a design to changes is not coming from data. It is rather based on how intelligent your modeling algorithms are.

The key workhorse of our feature recognition framework in Analysis Situs is the Attributed Adjacency Graph. This is a classic data structure that encodes a B-rep model as a formal graph of faces and their neighborhood relationships. Equipped with this data structure, we can build very efficient feature recognition algorithms, either rule-based or pattern-based. Many shape interrogation issues and design flaws can be addressed using the graph alone, without a need to go down to the geometry. In the photo, it is my son (8 years old at that time) checking the valences of graph nodes in the interactive graph view shipped with Analysis Situs: he is chasing the situations where a node has more than three incident links in order to localize a design issue for yet another industrial sheet metal part. He's actually having some fun because it's often a true detective story to figure out where exactly your CAD model is broken.

Academic papers come with lots of profound classifications for feature recognition algorithms. They call them rule-based, graph-based, hint-based and whatnot. In our practice, we came to using just two terms: rule-based and pattern-based. In fact, all our feature recognizers are effectively graph-based as long as AAG is involved. In a similar manner, they are all hint-based, because we use many strong and weak heuristics that act pretty much as "hints" for the recognizer. Let's take a closer look at these two different types of recognizers that we have.

Since we are able to formalize a CAD part as a graph, it is very appealing to try to formalize the feature recognition process as well. Indeed, if a feature is a subset of CAD faces, then, mapped to the graph theory, it would be nothing more than a subgraph that we have to find in the bigger graph of the entire model. The graph theory applied to geometric computing is so powerful that we devoted a conference talk to explore different aspects of its use. One of such is the so-called graph isomorphism matching.

With the isomorphism algorithm, we do not have to program a line of code: the algorithm of feature recognition is generic. What we rather have to do to recognize a specific type of feature is to give it a proper description in a "feature dictionary" that is often organized as a JSON or an XML file. In the process of feature recognition, the algorithm would collect all available feature descriptors from the dictionary and will search for the corresponding subgraphs. Although graph isomorphism is known to be a computationally heavy operation, we rarely see any performance issues with it because the input data is optimized by pruning out unnecessary relations. There is another issue with this technique, though: it cannot reliably handle features that interact with each other.

The graph isomorphism technique is used in our sheet metal recognition solution to identify typical features, such as drilled holes or punching features. You normally consider using this algorithm to make your system more "data-driven," i.e., when you let the users customize the feature dictionary. In the sheet metal domain, good candidates for pattern matching are different types of louvers, bridges and other deformed features that are otherwise quite laborious to express programmatically.

An alternative to isomorphism is rule-based matching. In a broad sense, a rule is a C++ program that iterates over AAG and searches for specific patterns by cursoring over the neighbor CAD faces and asking a bunch of geometric questions on the go. These rules, if implemented properly, are unbeatable in performance and generality: you can make a program that would recognize any kind of a feature, regardless of whether it interacts with other features or not. You just need to ground the recognition logic on good enough heuristics, and sometimes this is not a trivial thing to do. Some feature recognizers become so capable and mature that they easily turn out to be several thousand lines of C++ code. The logic behind such rules is far from trivial at times.

Rules are also invaluable for compound features that are common in CNC machining. Take a look at the compound hole in the slide above: you never know how many counterbores and countersinks a hole contains, so it is just impractical to use feature dictionaries in such situations.

At the same time, if you are looking for standard shapes, then graph isomorphism is of much help. We employ it not only to recognize drilled holes but also to extract conventional forms of cutouts: slot-like, rectangular, squared, etc.

Now let's go over typical CAD/CAM features that are of much interest for the users of a MaaS kernel. Historically, we developed a bunch of feature recognizers in the scope of our R&D activities. I was personally doing my PhD studies between 2015 and 2019, with the main focus on reverse engineering, feature recognition and defeaturing algorithms. We made a number of conference talks and published a bunch of papers, followed by plenty of open-source prototypes that made their way into our Analysis Situs software package. Back then, it mostly had academic use and we did not have any clear intention to commercialize our results.

The recognition of fillets was one of the first algorithms we implemented. This recognizer identifies smooth "spring" edges and transversal "cross" edges to compose a chain. For machining automation, we added the identification of approach axes and different grouping strategies for blends. It should be noted that in machining reality it is not enough just to recognize a feature, such as a fillet chain. What we also need to understand is whether or not a fillet is too small in radius or too tall in length. Some fillets are designed as double-curved spline surfaces, which essentially means that 3D milling is required to make them. There are many cost drivers associated with the complexity of a feature, and that is why the recognition toolbox has to question the input geometry heavily to generate a useful outcome.

Surprisingly, chamfers are harder to recognize than fillets, even though they are represented with individually simpler feature faces: a plane and a cone instead of a cylinder and a torus (in the canonical case). Because fillets possess the distinctive property of having surface curvature, we can trace the whole chain by probing this curvature value across neighboring faces. Chamfers are not so explicit: they often look no different from their supporting planar faces.

Our implementation of chamfer recognition follows some ideas that we grabbed from a US patent registered by Siemens. Of course, we could not reuse any piece of code, but we borrowed some terminology and a couple of heuristics. The very existence of a patent related to chamfer recognition speaks for itself: this is how complicated those feature recognition rules are.

"Prismatic feature" is a term that we use to name pockets. This feature is done by side milling with optional bottom milling with a flat-end tool. To put CAD faces into contours, we first evaluate their candidate approach axes and then group together those faces that can theoretically be done all together.

A slot is a special case for a contour. Slots are usually narrow so that they can be done in a single pass, for example, with a disk cutter. We require a slot to be open-ended in at least one direction.

Modeled threads are usually represented with helical splines. We recognize different types of modeled threads and also classify them into internal (at drilled holes) and external features. For lathed parts, we also check if the identified modeled threads are coaxial with the turning axis of a machine.

CNC recognition comes hand in hand with the analysis of manufacturability. In the early days of our SDK, we had a specific library to analyze manufacturability issues on milled parts, but this module appeared to be tightly coupled with the feature recognizer. Indeed, to judge if a pocket is too deep and narrow, we first need to understand that we are dealing with a pocket (contour) feature. Features first, DFM second.

Fundamentally, we want a MaaS kernel to secure the estimator or process planner from problematic designs. DFM analysis calls for the "heavy artillery" of shape interrogation, where we need to make hundreds and thousands of probes to reveal potential design issues. Some of the typical questions we'd like to address are listed on the slide above.

One example is the face accessibility analysis. Can a mill approach a certain pocket? Can a drill approach a certain hole? Answering these questions requires intensive ray casting, which is pretty much a visibility test in a simplified formulation.

To raycast a model, we have to cover it with a dense cloud of probe points. Here we have some options. For example, our approach in Analysis Situs is to generate a uniform mesh that covers the surface of a part. Alternatively, it could have been a uniform point cloud on the boundary. The mesh nodes or points from the point cloud are used as ray sources, whereas the rest of the part is checked for intersections with the emitted rays.

The identified problematic regions are communicated to the user (estimator or process planner) with visual artifacts. In our case, it is a glTF file that is supposed to be rendered on top of the part being analyzed.

Because the generated glTF files preserve the information about features, it is easy to build an interactive frontend to highlight the problematic regions and report their geometric properties.

Feature recognition opens the door to estimating the number of required setups. The slide above illustrates a situation where it is not clear which face is a bottom one and which are the walls. Such an ambiguity is reported by the feature recognizer as a "configuration" of three (in this case) potential features. Depending on the order of operations, one of the reported configurations prevails. Analysis Situs may predict the required number of ops by an original optimization algorithm.

A MaaS kernel is a highly complex piece of industrial software. Depending on the application domain, such a kernel may need to contain a variety of computational methods not necessarily belonging to the feature recognition domain. Some examples are 2D and 3D nesting, bending sequence simulation, analysis of 3D printed parts, etc.

Analysis Situs accumulates decades of our R&D in the field of geometric modeling, computational geometry, and algorithms. It has an open-source core that is used by a wide community of CAD software developers and engineers all over the world. We continue developing it in a transparent way and welcome anyone interested to contribute to the project or partner with us to solve challenging industrial issues.

Want to discuss this? Jump in to our forum.