Text-to-CAD vs text-to-3D: why the difference matters

Last Tuesday I watched a colleague import an AI-generated mesh into SolidWorks with the confidence of someone who has never been hurt by an STL file. He'd typed a prompt into one of those text-to-3D tools, something about a sensor housing with snap fits, and the preview looked great. Clean edges on screen. He dragged the OBJ into an assembly, and within about three seconds the mood shifted. SolidWorks treated the import like a lump of concrete dropped onto the feature tree. No selectable faces. No real edges. Just a dense, triangulated blob refusing to participate in engineering. He tried to add a fillet to the snap-fit lip and got an error that basically said "I don't know what you're pointing at." I sipped my lukewarm coffee and said nothing, which is my version of sympathy.

That moment captures the entire text-to-CAD vs text-to-3D distinction better than any diagram could. Both approaches start with a text prompt and end with a 3D shape on your screen. But what's inside that shape, and what you can do with it afterward, is completely different. If your work ends at "rotate it in a viewport," you might never notice. If your work continues into dimensioning, manufacturing, or the next revision, you'll notice immediately, and it will cost you an afternoon.

The geometry under the hood#

A text-to-CAD tool produces B-Rep geometry. B-Rep stands for Boundary Representation, and it's the same kind of math that SolidWorks, Fusion 360, NX, and every other serious CAD program uses internally. A B-Rep solid has faces defined by mathematical surfaces, edges defined by the intersection of those surfaces, and vertices where edges meet. Select a face and the software knows it's a face. Ask for a fillet on an edge and the software knows which edge you mean and how to roll a radius along it. You can measure exact distances, compute real volumes, cut pockets, and export a STEP file that a machinist can work from without asking what went wrong.

A text-to-3D tool produces a mesh. A mesh is a skin of triangles draped over an approximated shape. It can look identical to B-Rep geometry in a viewport, the way a photograph of a sandwich looks identical to a sandwich until you try to eat it. But there's no face information, no edge topology, no mathematical surface definition. Just triangles, thousands or millions of them, stitched together into something that vaguely resembles geometry. Import that into SolidWorks and the software sees one monolithic body made of facets. You can rotate it. You cannot fillet it, chamfer it, or dimension a hole diameter.

If you want a deeper explanation of what text-to-CAD actually is and how it produces editable models, I've covered that separately. The short version: text-to-CAD tools generate sequences of CAD operations (sketch, extrude, fillet, chamfer) that produce real parametric solids. Text-to-3D tools predict what a surface should look like and approximate it with triangles. Same screen, very different file.

What you can actually do with each#

With B-Rep output from a text-to-CAD tool, you can do everything you'd do with a model you built by hand. Select a face and offset it. Add a counterbore. Shell the part. Apply draft angles for molding. Measure true diameters and wall thicknesses. Export to STEP and hand it to a machine shop. Generate a drawing with real dimensions. Roll back the feature tree and edit an earlier sketch. The geometry behaves like CAD geometry because it is CAD geometry.

With mesh output from a text-to-3D tool, you can render it, 3D print it (if the mesh is watertight, which isn't guaranteed), and look at it. That's roughly where the useful list ends. You can try to convert a mesh to B-Rep using tools like SolidWorks' mesh-to-solid or Fusion 360's mesh workspace, and I have tried this many times, usually on a Friday afternoon when my judgment is weakest. The conversion is lossy, slow, and produces geometry that looks hungover. Faces that should be planar come back warped. Cylindrical holes become polygonal approximations. You spend longer cleaning up the converted geometry than you would have spent modeling the part from scratch. The B-Rep vs mesh comparison covers the technical breakdown, but the practical summary is: mesh-to-solid conversion is a last resort, not a workflow.

The file format tells you everything#

This is the fastest way to figure out whether a tool is doing text-to-CAD or text-to-3D with better branding. Look at the output format.

STEP (ISO 10303) is the standard exchange format for B-Rep geometry. If a tool outputs STEP, you're getting real engineering geometry that opens in any professional CAD program with selectable faces and real edges. STEP is what machine shops expect. It's what mold makers expect. It's what your downstream workflow needs.

STL is triangulated mesh. It's the lingua franca of 3D printing, and that's about where its usefulness ends for engineering work. You cannot dimension an STL. You cannot fillet an STL edge. You cannot generate a manufacturing drawing from an STL. A tool that only outputs STL is a text-to-mesh tool, regardless of what it calls itself.

OBJ, FBX, glTF, PLY are all mesh or visualization formats. They exist for rendering, games, and animation. They are not engineering formats.

OpenSCAD's .scad format is an interesting case because it's code that compiles into geometry. An AI generating an OpenSCAD script is technically generating a parametric model, which is closer to the CAD side. The text-to-CAD guide covers the full range of output formats and what they're each good for.

The file format question isn't pedantic. A colleague once sent me a "CAD model" that turned out to be a high-resolution OBJ from a text-to-3D tool. It had 400,000 triangles and looked gorgeous in the viewport. It was completely useless for the tolerance analysis I needed to do. Forty minutes trying to extract a clean diameter measurement from what was essentially a polygon sculpture. That's time I'm not getting back.

The tools on each side#

The text-to-CAD side is smaller and more serious. Zoo.dev is the most established dedicated tool, running on a GPU-native kernel called KittyCAD, outputting real B-Rep geometry in STEP and other formats. AdamCAD generates parametric models with adjustable dimension sliders. CADAgent is an open-source Fusion 360 add-in that generates models inside Fusion's own environment, which means the output has actual feature history. These tools are trying to solve the hard problem: generating geometry that engineers can work with. The best text-to-CAD tools post covers each one in more detail.

The text-to-3D side is larger and louder. Meshy, Tripo, DreamFusion, Point-E, Magic3D. These tools produce impressive visual 3D content: game assets, concept visualization, character models, product renders. The meshes can look stunning. They're also engineering dead ends. Nobody is going to CNC machine a Meshy output. That's not a criticism of those tools. They're doing exactly what they're designed to do. The problem is when someone mistakes what they do for what CAD needs to do.

When mesh is fine#

I don't want to give the impression that mesh output is always wrong. It's not. Mesh is the right format for plenty of real work.

Game development lives on meshes. Every character, environment, and prop in a modern game is mesh geometry, and text-to-3D tools are genuinely useful for accelerating asset creation. Architectural visualization, product renders, VFX, concept art, 3D-printed figurines, physical prototypes where exact dimensions don't matter much. All fine with mesh output. The geometry doesn't need to be editable in a parametric sense. It just needs to look right and, in the case of printing, be watertight.

The trouble starts when someone tries to cross the boundary. When a mesh that was fine for rendering gets handed to an engineer who needs to add mounting features. When a 3D-printed prototype that "worked fine" needs to become an injection-molded production part. When the cool-looking housing from the text-to-3D demo needs real snap fits, real wall thicknesses, and real draft angles. That's where mesh output hits a wall, and the wall is made of manufacturing reality.

When you need CAD#

If the geometry is going to be manufactured with any process that cares about precision (CNC, injection molding, sheet metal, casting), you need B-Rep. Period. Machinists work from STEP files. Mold designers work from STEP files. Nobody in manufacturing is working from OBJ files, and if someone tells you they are, check whether they're actually in manufacturing.

If the part needs to mate with other parts, you need B-Rep. Assembly relationships, interference checks, and tolerance stack-ups require real geometric data.

If the part will go through revisions (and every real part goes through revisions), you need geometry you can edit without rebuilding from zero. A B-Rep model with a proper feature tree can survive a dimension change. A mesh cannot. You change one dimension on a mesh by rerunning the prompt and hoping the AI gives you something close to what you had before, which it usually doesn't.

The text-to-CAD file formats post goes deeper on which formats support which workflows, but the decision tree is short: if the part needs to be manufactured, edited, or mated with precision, you need text-to-CAD output. If the part needs to look good on a screen, text-to-3D is fine.

The marketing blur#

The thing that irritates me most about this space is how deliberately the line gets blurred. Every week there's another announcement about an AI tool that "generates 3D models from text," and every week I check the output format and find OBJ or FBX. The demos look amazing. And then you try to open the result in Fusion 360 and you're back to staring at a triangle soup wondering why you trusted a demo.

Calling mesh output "CAD" is like calling a photograph of a floor plan "architecture." It resembles the thing. It is not the thing.

If you're evaluating any text-to-geometry tool, the first question to ask is: "what format is the output, and can I select a face in my CAD software?" If the answer is yes, you're looking at text-to-CAD. If the answer is "it exports to OBJ and STL," you're looking at text-to-3D, no matter what the landing page says.

I keep a STEP file and an OBJ file of roughly the same bracket on my desktop. Same shape, same proportions. One came from Zoo.dev, the other from a text-to-3D tool. The STEP file is 47 kilobytes. The OBJ is 3.2 megabytes. One opens with twelve selectable faces and eight real edges. The other opens as a single imported body with 68,000 triangles. Same bracket. Two completely different futures. The small, boring file is the one I can actually build something from.

That's the whole argument, really. Text-to-CAD gives you geometry with a future. Text-to-3D gives you geometry with a viewport. Both have their place, but if you confuse the two, you'll find out the hard way, usually on a Tuesday afternoon with a deadline and a mesh that won't cooperate.