Split View: 프롬프트로 3D CAD를 만든다는 것 — 메시와 B-rep, 그리고 제약 조건이라는 병목

What It Means to Generate 3D CAD From a Prompt — Mesh vs. B-rep, and the Constraint Bottleneck

• Introduction — CAID Shows Up on Show GN, and a Confession: "Don't Use This for Manufacturing"
• Mesh and B-rep Are Different Things
• What "Parametric" Actually Means — the Feature Tree and the Constraint Solver
• What Today's Tools Actually Do
• What the Benchmarks Say About the Limits
• Where This Is Actually Useful Today
• Where Engineers Are Still Necessary — Tolerances, DFM, Machinability
• Conclusion — the Distance Between Making a Mesh and Making a Part

Introduction — CAID Shows Up on Show GN, and a Confession: "Don't Use This for Manufacturing"

A tool called CAID that generates 3D CAD models from a prompt showed up on GeekNews Show GN. The problem its creator identifies is clear — turning a shape and mechanism you're imagining into reality currently requires learning a CAD tool's feature set and clicking hundreds of times, and that's the bottleneck in hardware design.

The mechanics are simple too. Type the shape you want in natural language, an LLM generates code, a 3D model renders, and you can adjust parameters. It exports to STEP and STL. Three categories — flanges, L-brackets, and heatsinks — are pre-validated templates that skip the LLM path entirely; only free-form prompts go through the AI route.

What's interesting is the limitations the creator disclosed themselves. It can't automatically verify dimensions, it can't judge manufacturability — tolerances, DFM constraints, machinability from a CNC or milling standpoint — and it states plainly that this is a verified prototype and the output shouldn't go straight into manufacturing.

That admission summarizes the state of the entire field accurately. And why becomes obvious the moment you look at what kind of data structure CAD actually is.

Mesh and B-rep Are Different Things

The sentence "I generated a 3D model" can point to two completely different results.

A mesh is a list of triangles. Vertex coordinates and triangle indices — that's it. Curved surfaces don't exist; they're approximated by polygons. A cylinder 20mm in diameter is, in reality, about thirty-two flat faces — not an actual cylinder. Generating a mesh from text works well right now — diffusion models and 3D generative models produce one in tens of seconds.

B-rep (boundary representation) is a topological graph. There are faces, each face sits on an analytic surface (a plane, a cylinder, a torus, a NURBS surface), faces meet at edges, and edges meet at vertices. A cylinder 20mm in diameter is a single cylindrical face carrying a radius parameter of 10. This is what a STEP file holds, and it's what mechanical CAD works with.

Here's how the difference shows up in practice.

# The same bracket represented two ways

Mesh (STL):
  vertex 12.000 0.000 5.000
  vertex 11.951 1.111 5.000
  ...  (one hole approximated by 64 triangles)
  -> "What's the diameter of this hole?"  Can't answer. You'd have to reverse-engineer it from the point set.
  -> "Change the diameter from 8 to 10"  Requires full regeneration.
  -> Can't generate a drilling instruction. There's no concept of "a hole" at all.

B-rep (STEP):
  CYLINDRICAL_SURFACE('', axis_placement, 4.0)
  -> "What's the diameter of this hole?"  8.0 millimeters.
  -> CAM software recognizes the cylindrical face and generates a drill cycle.
  -> But STEP only holds the resulting geometry. It has no record of how it was made.

That last line matters. STEP holds a B-rep, but it doesn't hold a feature tree. So the claim that "exporting to STEP means it's editable in any CAD system" is only half true. Direct edits — pushing and pulling faces — work fine. But "change this bracket's thickness parameter from 5 to 8 and have everything else adjust automatically" doesn't work. That relationship simply isn't in the file.

What "Parametric" Actually Means — the Feature Tree and the Constraint Solver

When mechanical CAD is called parametric, it means two layers.

The first layer is constraints inside a sketch. You draw lines and circles in a 2D sketch, then apply geometric conditions — parallel, perpendicular, tangent, concentric, symmetric — plus dimensions. These conditions become a system of equations, and a geometric constraint solver solves it. When the user changes one dimension, the solver reruns and recomputes the positions of everything else.

The second layer is the feature tree. The sequence in which a sketch gets extruded, a hole gets cut into the result, and a fillet gets applied to an edge — all of it gets recorded. When a parameter changes, this sequence gets replayed from the start.

There are three walls where LLM-based generation runs into trouble here.

The constraint solver is a satisfiability problem. Apply too few conditions and the shape floats with leftover degrees of freedom (under-constrained); apply too many and they contradict each other and can't be solved (over-constrained). People get stuck here often too. Having a model extract, from natural language, a set of constraints that strikes this balance is a fundamentally different kind of task from drawing a shape. And the failures are quiet — it's common for the solver to converge on a solution, just not the one that was intended.

Feature replay is fragile. A fillet references a specific edge, and if an upstream parameter changes such that that edge disappears or splits, the fillet fails. This is a long-standing problem in the CAD industry, well-known enough to have its own name. A tree generated by an LLM doesn't account for this fragility, so it's easy to end up with a model that collapses on replay after only a small parameter change.

Spatial reasoning is weak. This criticism comes up repeatedly in a Text-to-CAD discussion on Hacker News. One person points to a stiffening rib covering a hole in an L-bracket benchmark, questioning whether positional calculation is even working correctly. Another notes that the effort required to describe exactly the shape you want rivals hand-drawing it in CAD, undercutting the efficiency argument entirely. And the thread's shared conclusion is that the constraint-solving complexity inside a parametric feature tree remains, in practice, essentially untouched.

What Today's Tools Actually Do

Here's a rundown of the approaches currently in this space.

A few things worth pointing out.

Using code as an intermediate representation is currently the most robust approach. The text-to-cad harness uses build123d, sitting on top of the OpenCascade kernel. Instead of having the LLM generate geometry directly, it writes Python code that builds a parametric model. The advantage of this structure is clear — the code is the feature tree, it's version-controlled with git, parameters are variables, and a failure produces a stack trace. Observability is preserved.

# Why CAD-as-code is robust: intent survives as text
from build123d import *

THICKNESS = 5.0
HOLE_D    = 8.0
EDGE_MARGIN = HOLE_D * 0.75   # fix the minimum wall thickness around the hole as a relation

with BuildPart() as bracket:
    with BuildSketch() as base:
        Rectangle(60, 40)
    extrude(amount=THICKNESS)
    with Locations((20, 0)):
        Hole(radius=HOLE_D / 2)
    fillet(bracket.edges().filter_by(Axis.Z), radius=3)

# Change HOLE_D to 12 here and EDGE_MARGIN moves along with it.
# This relationship isn't preserved in a STEP file. It only survives in the code.

This example demonstrates the problem at the same time. The set of edges fillet references gets selected by a filter, and if an upstream shape changes such that the target edge disappears, it either quietly applies to a different edge or fails outright. Writing it as code doesn't make the fragility of feature replay go away.

SGS-1 points in a different direction. Released by Spectral Labs in September 2025, this model bills itself as the first generative model aimed at structured CAD (B-rep) generation. It takes an image or mesh as input and produces an editable STEP, so its main uses are automating reverse engineering and generating new parts within the context of an existing assembly. The team reported an advantage in success rate over GPT-5 and HoLa BRep across 75 complex CAD images. The limitations the developers themselves acknowledge are complex surfaces, organic structures, very thin features, and full assemblies. The Hacker News reaction carried substantial skepticism — CAD users who'd actually tried it reported dimension errors, failed holes, and misaligned features, and questioned the phrase "easily editable."

What the Benchmarks Say About the Limits

Text2CAD-Bench, published in May 2026, puts this state into numbers. It curated 600 examples across four complexity tiers (L1 through L4), and attached two prompt styles to each — one written the way a non-expert would describe it, and one written procedurally the way an expert would. This dual-prompt design is a good choice, since it lets you isolate how much the user's CAD proficiency itself affects the outcome.

The conclusion is predictable but useful. Both general-purpose LLMs and domain-specific models perform reasonably on basic shapes but drop off sharply on complex topology and advanced features. In other words, the performance curve doesn't decline gently — it collapses at a certain point.

This matches intuition. Drilling a hole in a box is a matter of extracting a handful of parameters from a prompt. But a shape where multiple features reference each other, surfaces meet with tangent continuity, and thin walls have to avoid collapsing is a constraint-satisfaction problem — a fundamentally different kind of computation from language modeling.

Where This Is Actually Useful Today

There's no need to read this only pessimistically. There are uses that deliver real value right now.

First drafts. Getting a plausible shape to start with and then fixing it, instead of starting from a blank screen, genuinely saves time. This is especially true for standard parts — flanges, brackets, heatsinks, housings — where the range of shape variation is narrow, so generation quality is good. CAID setting aside these three categories as pre-validated templates looks like the same judgment call.

Part-library search. Typing "a 90-degree angle bracket that fits four M8 bolts" in natural language to find it in an existing library is far easier and safer than generating it, since you're reusing an already-validated part. The real value of generative models here may lie less in creating geometry and more in indexing and retrieving it.

CAD-as-code and agent workflows. A coding agent writing parametric CAD code, looking at the rendered image, and fixing it itself in a loop actually works. Users on the text-to-cad thread report this iterative refinement working well on simple shapes. There's an interesting implementation detail — this harness generates a topology sidecar for the STEP file, letting the model read B-rep information without loading the entire file, an attempt to work with geometry within a limited context budget.

Reverse engineering. Converting mesh or scan data into B-rep was already semi-automated and tedious work to begin with. This is where SGS-1 is aimed. On the premise that a human reviews the result, the verification burden is smaller than creating something from a blank slate.

A common thread emerges. Value shows up where verification cost is low, where a human can confirm it visually right away, or where a failure is cheap to undo.

Where Engineers Are Still Necessary — Tolerances, DFM, Machinability

The three things CAID's developer honestly listed are exactly the areas that remain unautomated.

Tolerances and fits. A hole diameter of 8mm means nothing on its own. Whether it's 8H7 or 8H11, a clearance fit or an interference fit, determines whether the part assembles at all. And tolerance isn't derived from geometry — it comes from functional intent. Whether this shaft needs to rotate, needs to be fixed, or needs to absorb thermal expansion is something the model can't know unless it's in the prompt. Tolerance-stack analysis across multiple parts is a whole other level beyond that.

DFM. Injection molding needs draft angles and uniform wall thickness; 3-axis milling has trouble with internal corners and undercuts the tool can't reach; sheet metal is constrained by bend radius and minimum flange length. The same shape can be manufacturable or not depending on the process. Even when a process is specified in the prompt, there's no guarantee the model satisfies that constraint while generating the geometry.

Machinability verification. Tool accessibility, number of setups, fixturing method — none of this can be judged from geometry alone; it requires knowing the shop floor's equipment inventory.

And there's one more thing, less often mentioned but important. Recording intent. A well-made CAD model carries not just geometry but why it's that geometry — which dimensions are functionally critical (and so tightly toleranced), and which were chosen arbitrarily. This information is what lets someone else modify it safely six months later. A generated model tends to have every dimension look equally arbitrary, and that comes back as a maintenance cost.

Conclusion — the Distance Between Making a Mesh and Making a Part

If I had to leave one question as the most useful lens for this field, it's this: does this tool's output carry editable features, or is it just resulting geometry?

• If only a mesh comes out, it's for visualization and printing drafts. It can't enter a mechanical design pipeline.
• If B-rep (STEP) comes out, you can bring it into CAD and edit it directly. But without a feature tree, you can't change one parameter and regenerate.
• If parametric code comes out, it's genuinely parametric. But the code can contain fragile references, and that fragility needs a human's eyes on it.

And none of these substitute for tolerances, DFM, or machinability. The developer of the tool posted to Show GN writing "don't use this directly for manufacturing" isn't modesty — it's an accurate technical description. The distance between making a shape and making a part is still far greater than what this field has closed so far.