Rethinking Structured Meshing

Despite decades of research, fully automatic structured hexahedral meshing remains a difficult problem. While automatic methods have made significant progress, experienced engineers can still produce better results for many complex industrial models by deciding how the geometry should be partitioned.

But that often involves a tedious process of cutting, splitting, merging and repairing geometry before the actual meshing can even begin.

CAD systems already provide powerful tools for performing these operations. So why does preparing geometry for structured meshing still require so much manual effort?

Perhaps we're automating at the wrong level.

From Operations to Intent

One thing I've learned while developing engineering software is that automating what the customer already does isn't always the best way to help them.

Engineering workflows are often shaped by the technology available at the time. Over the years, those workflows become familiar and eventually accepted as the way things are done.
But technology moves on.

Instead of asking how we can automate the individual operations an engineer performs, what if we understood what they're actually trying to achieve and let the software work out how to get there?

That's the philosophy I've followed in developing CADfix HexSplit.

Consider a component with several repeating patterns and different symmetries. An engineer might detect the cyclic regions, separate the ones that don't match, identify mirror symmetry, create partitions and finally connect everything into one structured layout.

With SCAGE, the engineer simply requests the quadrilateral partitioning. The algorithm recognizes the different patterns, works out how they relate and creates the connected layout.

Figure 1: SCAGE: component with different periodicities, generated quad partition and final mesh

Or consider a feature that needs to be punched through a solid to make it sweep-able. A simple projection might interfere with geometry on the opposite side, requiring additional cutting and merging operations.

HexSplit's cookie-cutter operation uses the medial axis to reason about the surrounding geometry and produces the intended decomposition in one operation.

Figure 2: A planar split introduces a sliver which can go unnoticed.


Figure 3: HexSplit Cookie Cutter can spot sliver and fix it automatically

Similarly, an engineer looking at an axisymmetric component can recognize which regions should be spun, and which should be swept. HexSplit's circular cutter uses that geometric structure to separate those regions automatically.

Figure 4: Circular cuts separate out swept and spun regions of the component.

These are different geometric problems, but they illustrate the same idea.

Rather than asking the engineer to orchestrate a sequence of low-level geometry operations, we provide a higher level of abstraction where they can specify the intended result.

The software handles the geometric reasoning underneath.

AI Agents

This becomes particularly interesting as AI agents begin interacting with engineering software.

An AI agent may be perfectly capable of recognizing that a region needs to be separated or that a surface requires structured quadrilateral partitioning.

But asking it to manipulate dozens of faces, edges and vertices, manage geometric tolerances, recover from failed operations and repair topology is a very different challenge.

An agent might eventually learn to navigate those operations, just as an experienced engineer does. But why should it have to?

If the software exposes higher-level operations such as split this region, punch this feature or create a structured quad layout, the agent can focus on deciding what needs to happen rather than working out every geometric step needed to achieve it.

Fewer intermediate decisions, fewer opportunities for failure, and a much more direct route from intent to result.

In that sense, geometry reasoning isn't just useful for making engineering software easier for people to use. It could also make that software considerably easier for AI agents to drive reliably.

Closing the Gap between Intent and Result

The aim isn't necessarily to automate every engineering decision. An experienced engineer still understands what kind of mesh is needed and why. What we're trying to eliminate is the complicated sequence of operations between that decision and the desired result.

Traditional workflow:

Engineer decides → Cuts, splits, merges, repairs, works around limitations → Result

With geometry reasoning:

Engineer decides → Requests the operation → Software reasons about the geometry → Result

The same principle applies whether the user is an experienced engineer or an AI agent.

And while structured meshing provides some good examples, this is how I approach engineering software development more generally.

I believe the most valuable automation comes from understanding what the user is really trying to achieve, rather than simply reproducing the steps they currently take to get there.

The goal isn't just fewer clicks. It's fewer things to think about between knowing what you want and getting it.