Why We Chose CNC and Sheet-Metal Parts Over Organic Shapes
SolidMake will never generate a phone case or a figurine — that's a deliberate scope decision, not a limitation we're embarrassed about.
Ask SolidMake for a phone case, a figurine, or a piece of jewelry, and it will not attempt one. That's stated plainly in scope of the project's design document, right next to what the system is actually built for: brackets, plates, flanges, gears, housings, and enclosures destined for a CNC mill or a laser/plasma/waterjet cutter. This isn't a gap we're hoping to close later. It's a line we drew on purpose, because drawing it is what makes the rest of the problem solvable.
Parametric sequences describe mechanical parts, not organic ones
The core technical bet behind SolidMake is that the model should output a parametric construction sequence — sketch, extrude, boolean, fillet — rather than a mesh. That sequence is exactly how a mechanical part is actually built in real CAD software: a machinist or a design engineer thinks in terms of profiles and operations, not vertices and triangles. A bracket is a sketch of a right angle, extruded, with holes cut through it. A flange is a circular sketch, extruded, with a bolt pattern subtracted. These are all things a short sequence of well-understood operations can represent exactly.
An organic shape — a phone case with a soft-touch curve, a figurine's face, a piece of jewelry with a freeform band — doesn't decompose into sketch-and-extrude operations in any natural way. Representing that kind of geometry well generally means NURBS surfaces or subdivision meshes, entirely different mathematical representations with entirely different tooling, loss functions, and training data. Trying to make one model span both worlds would mean compromising on both: a program good at parametric mechanical sequences and mediocre at organic surfaces, or vice versa. We picked one world and committed to it.
The scope decision and the dataset line up
This isn't an arbitrary line, either — it happens to be exactly where the available training data lives. DeepCAD, Text2CAD, and the Fusion360 Gallery dataset, the three corpora the text branch is trained and evaluated against, are all sourced from real parametric CAD histories captured out of tools like Onshape and Fusion 360. Nobody exports a sculpted organic model as a construction-history JSON, because that's not how those models get made in the first place — they're built in surface or mesh modelers, not feature-tree CAD. The data that exists for this kind of supervised training is mechanical-part data, full stop.
That's a fortunate alignment rather than a coincidence we discovered after the fact: the domain we scoped to for tractability reasons is the same domain the available research datasets happen to cover, because both the scoping and the datasets trace back to the same fact about how mechanical engineers actually design things. If we'd scoped toward organic shapes, we'd have had to go build or find a dataset that doesn't obviously exist in comparable size or quality — a project on its own, before the actual CAD-generation model could start training.
What this buys us, concretely
Narrowing the target domain isn't a consolation prize — it's what turns "generate CAD from text" from a research moonshot into a scoped, gradeable engineering project. It means the validator can check things like watertightness, minimum wall thickness, and sheet-metal flat-unfold feasibility, because those checks presuppose a manufacturable mechanical part in the first place — they wouldn't mean anything applied to a sculpted figurine. It means the evaluation metrics (execution rate, Chamfer distance, manufacturability rules) have a coherent target to measure against. And it means every design decision downstream — the CadQuery output format, the sandbox, the exporters targeting STEP and DXF instead of a generic mesh format — reinforces the same bet instead of hedging across two incompatible ones.
We're not embarrassed that SolidMake can't make you a phone case. A tool that tries to do everything for everyone usually ends up doing nothing particularly well for anyone. We'd rather be the system that reliably turns "L-bracket, 60 by 40 by 3 millimeters, four M4 holes" into a STEP file that opens cleanly in Fusion and cuts cleanly on a mill, than one that produces plausible-looking geometry for a category of problem the underlying representation was never built to solve.