All summaries · 2026-09-17

www.ijcai.org/proceedings/2023/0200.pdf

Unknown authors

arXiv:url-063ea42052b9ee84 · abstract · pdf · summarized by meta/muse-spark-1.3-contributor on 2026-09-17

The one-paragraph version

This paper tackles reverse-engineering for engineering models: given only the finished 3D shape of a manufactured part, recover the step-by-step recipe a designer would have used to build it in CAD software. The authors introduce both a new dataset and a new model called CADParser. The dataset contains about 40,000 real manufacturing-style parts with their full build histories, including operations beyond just drawing and pulling a shape — namely spinning a profile, and adding small rounded or beveled edges. The model works by first reading the shape as a connected network of surfaces and edges, then writing out the build recipe one step at a time like a sentence, using a graph-reading encoder plus a language-style Transformer decoder. On their own dataset it rebuilds shapes reasonably well and much faster than two prior methods, but with slightly lower geometric overlap, and it still often produces recipes that fail to build.

The problem they're solving, and why it matters

Parametric Computer-Aided Design, meaning design where a shape is defined by editable features and numbers rather than just fixed triangles, is how most real manufactured things are made — car parts, electronics housings, furniture fittings.

A finished CAD file ideally contains two things: 1. Geometry: what the shape looks like right now. 2. Construction workflow: how it was built, for example draw a rectangle on a flat plane, pull it up 4 millimeters, cut a hole, round an edge.

That second part preserves design intent. If you want to make the hole deeper or the wall thicker for simulation or manufacturing, you just change a number instead of pushing individual vertices around.

The trouble is that the standard sharing format, called boundary representation, describes only the finished outer skin — which faces meet at which edges — not how it was made. History is often lost in translation between programs. Many models on the internet are geometry-only.

Earlier learning work mostly used a different, simpler modeling language called constructive solid geometry, where you glue together boxes, spheres and cylinders with union or difference. That is easy for a network to search, but it is not how modern engineers actually work. Engineers use feature-based modeling: start with a 2D sketch, then add features like bosses, holes, slots, spins, and edge treatments, with Boolean operations between solids along the way. That space of possible programs is much larger and harder to infer.

Recent sequence-inference methods also narrowed the problem to only two operations — sketch plus extrusion — and often skipped the sketching itself by starting from pre-selected faces. The authors argue this limits diversity and makes results hard to import back into real CAD software for editing.

The key idea, in plain words

Think of the problem as translation between two very different languages.

The input language is space: a solid described by its skin. A flat side touches a curved side along a shared edge, that edge has two directed sides, and so on. That tight neighbor structure naturally looks like a graph, meaning a collection of items plus a list of who touches whom.

The output language is time: an ordered list of designer actions. For example: pick a plane, draw lines and a circle, pull that profile into a solid, spin another profile around an axis, pick an edge and round it.

So the authors build a reader for space and a writer for time. The reader is a graph neural network that summarizes all the faces, edges, and their connections. The writer is a Transformer, the same family of models used for sentences, that predicts the next action given the shape summary and all previous actions. To make this work they also needed better training data, so they collected manufacturing parts that actually use rounding and spinning, not just pulling, and expanded them by systematically editing the last steps.

A concrete example from the paper: from a finished bracket shape, infer something like draw a six-point outline, define a spin axis through the origin, spin the outline a full circle, round the edge at a certain point with radius 0.05, then cut an extrusion — and then a designer could re-edit those numbers to get a family of new parts.

How it actually works, step by step

1. Build a more realistic dataset. They start with about 10,000 template models designed in SolidWorks, described as national standard parts and enterprise standard parts — in other words, real engineering components, not beginner practice shapes. Using SolidWorks programming interfaces they parse the design history and keep five operation families that each appear frequently: sketch, extrusion, revolution, fillet, and chamfer.

Because 10,000 is small for a Transformer, they augment. They rewrite each history as a short series of steps, where sketch plus extrusion or sketch plus revolution counts as one step. Then working from back to front — because later steps depend on earlier ones — they repeatedly trim the last step or jitter its numbers, and check with a geometry library that the result is still a valid solid. That grows the set to about 40,000. In the final data, sketches dominate, and most recipes are short: about 64% have 0 to 5 steps, 23% have 5 to 10, with only small fractions longer than that.

2. Represent the input shape as a graph. For one input model they build a network where each item is a face, an edge, or a directed edge-side called a coedge. Connections record relationships like face touches edge touches directed edge-side. Each face gets a description combining its underlying surface math plus a grid of sampled points in its own surface coordinates, an idea borrowed from prior B-Rep learning work. Edges and coedges get their curve geometry. This lets the network see both local curvature and how pieces join.

3. Represent the output recipe as a fixed-size sentence. A recipe is an ordered list of commands, padded or cut to 32 slots. Each command has a type and a list of numbers. Types include start, line defined by its end point, arc defined by end point plus sweep angle and direction flag, circle defined by center and radius, plane placement defined by position shift plus rotations plus scale, extrusion defined by pull distances in two directions, extrusion-cut which is the same but removes material, revolution axis placement, revolution defined by spin angle, revolution-cut, fillet defined by a 3D point on the edge to be rounded, chamfer which is similar but for a flat bevel, plus padding and end markers.

To handle the fact that different commands need different numbers of values, they stack all possible parameters into one long vector of length 19 and fill unused slots with -1. To handle a mix of discrete choices and continuous numbers, they first scale every solid into a two-by-two-by-two cube, then bucket each continuous number into 256 levels, turning everything into classification.

4. Encode, fuse, and decode. The graph goes through a B-RepNet-style backbone that passes messages along special topological walks, producing a detailed local summary for each face, edge and coedge, plus a global summary made by averaging.

A small fusion module merges that global shape summary with the embedding of the commands predicted so far. Each command embedding is itself a sum of three learned pieces: what type it is, what its numbers are, and where it sits in the sequence.

The decoder is 4 Transformer layers. At each step it looks back at earlier predicted commands with masked self-attention, looks at the shape summary with cross-attention, and then predicts the next type and its numbers through two separate classifiers. In words: the probability of the whole recipe is the product of the probabilities of each next step given all previous steps and the shape. Training maximizes the log-probability of the true recipes using the AdamW optimizer, with warmup, dropout, gradient clipping, 100 epochs and batch size 96 on a single older GPU.

What they showed — results, honestly, with limitations

They split off 1,000 models for testing and evaluate by rebuilding a solid from the predicted recipe with a CAD engine, then measuring overlap.

They use three measures: volumetric overlap between rebuilt and true solids, computed with OpenCascade; success rate, where they count it as failure if building crashes or overlap is below 0.5; and time to parse.

On their own data, the numbers are: Fusion360 Gym gets about 0.91 overlap, 0.82 success, 20 seconds; ZoneGraph gets about 0.95 overlap, 0.42 success, 38.5 seconds; CADParser gets about 0.81 overlap, 0.64 success, 3.9 seconds. In other words, CADParser is an order of magnitude faster, middle of the pack on success rate, and lowest on pure overlap.

The paper suggests two reasons, which sound plausible but are not rigorously proven: competitors use a trick called face extrusion that directly picks groups of parallel faces to pull, which is very good at extrusion but hard to extend to rounding or spinning; and overlap mostly rewards big bulk shape, so it can undervalue small but meaningful local features like a tiny fillet. Qualitatively they show cases with curved or non-flat faces where the baselines fail to produce anything while CADParser produces a close shape.

Ablations support three claims: using both global and local shape features is slightly better than either alone; replacing the Transformer with a simpler recurrent LSTM decoder drops overlap from about 0.81 to 0.73 and success from 0.64 to 0.40, so the Transformer helps even at this data scale; removing augmentation drops overlap only slightly from 0.81 to 0.78 but collapses success from 0.64 to 0.45, so augmentation mainly teaches validity.

Limitations to keep in mind: the comparison is not fully apples-to-apples — ZoneGraph was retrained by the authors for only 10 epochs on a different reconstruction subset with time and step caps, and Fusion360 Gym uses released weights. Evaluation is only on their own dataset, only five operation families, only recipes up to 32 steps. The quantization into 256 bins inherently loses precision. And because CAD is strictly constrained, many predictions still fail to build. The authors themselves note that future work should enforce constraints during prediction and develop a better metric than pure overlap that values both global bulk and local features.

Why this might matter to me

For spatial reasoning in LLMs and VLMs: this frames building as language. If a shape history is a sentence of typed commands with numbers, a language or vision-language model can in principle read, critique, or edit it — change the spin angle, move a sketch plane — rather than just captioning a render. It is a concrete test of whether a model understands adjacency, symmetry, and order of operations.

For world models: CAD construction is a tiny, exact world with actions and state. Predicting the next feature given the current solid and target solid is like learning an inverse dynamics model. Success rate here is a grounded measure of action feasibility, not just visual similarity.

For text-to-CAD and parametric geometry: most text-to-3D today outputs static meshes or radiance fields that you cannot edit by numbers. A sequence of sketch, pull, spin, round, bevel is directly editable and manufacturable. The paper's move beyond sketch-plus-extrusion to revolution, fillet and chamfer is exactly the direction needed for useful parts, though precision loss from bucketing numbers remains a bottleneck for tolerance-critical work.

For 3D generation and scene representation: program-like representations are compact, resolution-independent, and preserve sharp edges and smooth analytic surfaces that meshes approximate poorly. The graph-plus-sequence pattern here — encode topology and geometry, decode program — could complement neural fields or Gaussian splats: use those for appearance, use inferred CAD programs for structure, editability, and downstream simulation.

Terms worth knowing