not interesting as the writeup as very AI sloppish :(. i'm sad about that as I would really like to have an intuitive sense for how good the current frontier models are at coming up with interesting 3d printable parts.
I've been just getting started on this with Astra. Astra is one-shotting good 3D models from photographs for me. I was unable to get Sol to do this, even after multiple rounds.
It's not a small change, it's from "not useful" to "pretty good"
None of the "findings" here really needed an AI experiment to do it:
- "CadQuery fails loudly and early... OpenSCAD fails silently and late"
This should be obvious, from the documentation, from the way geometry construction works. OpenSCAD has no sense of failure where one shape means another won't work; you're just drawing the equivalent of 3D pixels in space. It will always potentially-meaninglessly succeed if the syntax is OK.
- Renders caught nothing that mattered
Objects with hollows are not going to show their major problems this way.
- CadQuery can be interrogated, OpenSCAD cannot
Isn't this explicit from the documentation of both? One works by iteratively building on top of a previous result that can be stored in a variable; the other doesn't.
- OpenSCAD renders have no concept of a part edge
Again — this should be explicit from the documentation, which describes no methods for operating on edges.
- Speed favours OpenSCAD, and it barely matters
Yes, being faster is no good if things are wrong.
- "What decides it is verifiability rather than expressiveness, and CadQuery leads there by a wider margin than the syntax difference suggests."
Yes, because the difference is semantic. Which you can get from the documentation. Building iteratively on the basis of existing geometry is inherently more verifiable, because stuff that can't work won't work.
Honestly do people not try learning CAD before they try to get an AI to generate CAD models?
I mean, people didn't write the text, but people did decide it was what they wanted it to say?
I don't really get it. But then I think text-to-CAD is probably the strongest example of cart-before-horse thinking in the AI world as regards technical work compared to creative work.
Should try different models and harnesses, CC and opus5 aren’t the best combo. Also, I expect soon to have models that verify the mesh and even render it not just generating the code. So we got this for mechanical engineering, cupperhead and similar for electronics, usual agents for software, what is next?
Models already do this, I tell them to use Blender and OpenSCAD to render previews, use tools in those packages to verify/modify meshes and otherwise it'll write its own custom software. Codex has written me thousands of lines of Blender Python over the last week to do all sorts of amazingly complicated and custom mesh inspection and cleanup that I have no idea how I would even begin doing that by hand. And render previews, which I then annotate with Paint. Like I tell it 'I marked a missed corner chamfer in red here, and the blue is where the other part should mate' and then I paste a screenshot of that Paint image and it goes off and fixes it.
Exactly. But then text-to-CAD projects almost all have this over-reliance on the declarative nature of OpenSCAD.
Cynically it always feels to me like they are written by people who not only think end users shouldn't have to learn CAD principles, they themselves shouldn't have to either.
do you know the WASM bundle size of Python and CadQuery? OpenSCAD has a lot of cons in terms of concept and CAD approach, but there are things where it is good - it is embeddable and sandboxable and fast. It gets the job done in simple models and that is the reason why it is popular.
It reminds me a bit how everyone was bashing PHP because 'it is not a programming language' while wordpress ruled the world.
Comparing OpenSCAD to CadQuery is super apples-to-oranges in the first place. CQ works directly with NURBS curves via the Cascade engine, and OS functions by performing CSG operations. Both certainly have their place, but for engineering applications NURBS are decidedly more powerful.
I’ve been playing in this space as a moderately experienced hobbyist - mainly for 3D printing functional parts.
I’m using a single repo for all my models and Claude with build123d (plus a VS Code viz extension). Over time, I’ve built up a little folder of useful skills and I’m generally getting satisfactory results.
That said, I have had my eye on CadQuery and am looking for an excuse to try it. For those in the know: how does it compare to build123d?
The fundamental difference is that CadQuery uses that jQuery-inspired fluent syntax, with a sort of metalanguage for some aspects, and Build123D is more pythonic with two different more procedural syntaxes.
The other difference (which I have only read abut) is in the way their assembly constraints work; again Build123D takes the more procedural approach (declaring "joints" etc.)
CadQuery came first; Build123D is sort of a more pythonic, robust restatement of it.
I've also been playing around in this area and starting getting somewhat useable around Opus 4.8. It has been able to generate some quite impressive designs, but for me it has been quite hard to get the model to understand what exactly I want modeled.
Are you willing to share your work?
Mine is available at https://jnslmk.github.io/build123d-models/?model=drill_stora...
One of the things I've found more useful is the generation of a static site to view and download the models.
With WASM you can make minor adjustments directly in browser
"Downloading WASM: 40mb of Python and build123d" - this hurts :( This is exactly the good thing about OpenSCAD: its WASM build size is minuscule compared to Python build, and you can edit/customize a model right in the browser. https://modelrift.com/models/desktop-organizer-with-drawer
I've been making Rapidcam.app. The file schema is open source and json format designed for AI to be able to write directly. The format is also designed for version control. The focus is 2.5D parametric mostly for 3 or 4 axis CNC.
Has anyone have good success using AI generated CAD parts? I’ve been trying but it’s always 95% there, but with all hardware, you need 100% right. It’s often quicker and cheaper for me to do it by hand (but I was a mechanical design engineer for about a decade prior)
Just this morning I used OpenSCAD for the first time. I got Gemini (just the chatbot, no harness or MCP) to help me design a water-bowl holder for our senior dog (she kept knocking it over).
It was probably an easy model to get right, since the only "critical" dimension was the radius of the interior. But I was able to tweak the numbers on the support length & some other details relatively easily, and I had a working solution 2 hours of print time later.
(I had a CAD class in highschool, but haven't used it since).
I suspect this may be another case of "LLMs are mainly good at things you're bad at."
assemblies and tolerances are where AI generation quickly gets hard. but, for simpler things, it can be surprisingly good, especially for people who has no CAD knowledge. it certainly might feel a bit like brute-forcing through the LLM - but this also applies to vibe-coding..
Oh, on this topic, I've actually built a geometric CAD kernel with GPT that I think is pretty promising and in my biased opinion, a bit more advanced than OpenSCAD or CadQuery's OCCT backend, anybody here want to clone the repo to give it a try with their Claude/GPT to see they do better on my thing?
It's still kinda buggy but they are actively getting fixed, but Claude and GPTs seemed to work better with my current design than other CAD stacks. Still haven't added threads yet, so can't speak for T3, but generally speaking the generated parts are pretty good quality, and I also got fillets/chamfers working so that's a plus.
I've been working on something similar as well, but not yet ready to be shared. It's a geometry kernel and then an authoring layer on top. The idea is that the constraints are tests that get run after the geometry is defined, so it's more programmatic. Sol was able to generate STEP files for credible turbo machinery with it, and I have Astra building out the assembly for an inline three engine idea I had. The drawings are looking credible, but that's about all I can really say. I'm just blown away at how far the models have come in the last 12 months.
I tried modifying the provided CadQuery skill to work with build123d with an agent (surprisingly gemini pretty good at this) and it produced very good results (possibly better than the reported CadQuery/OpenSCAD results after taking a little care to avoid leaking the benchmark pass/fail criteria). Worth a try if you are interested in this space.
I like build123d simply because it can export proper STEP (like CadQuery) but has a nicely python friendly design.
Replicad is another frontend to the same cad kernel. But can run in browser or via bun or whichever js runtime you want. I've found llms to be better at writing typescript than python code for things like this.
Using Replicad, I've successfully iterated on a 3d printed enclosure for my electronics project. It's fantastic to get everything parameter based and version controlled from revision 1.
34 comments
[ 0.22 ms ] story [ 2.8 ms ] threadIt's not a small change, it's from "not useful" to "pretty good"
I'm the target for such material for I do use OpenSCAD to model parts I then 3D-print to fix stuff around the house and enhance the cars etc.
And yet the writing is totally insufferable AI slop:
"All six parts came out printable. Capability turned out to be the boring part of the answer. Where the two diverge is in how they fail."
Anyone who writes like this or who enjoys such kind of sentences: from the bottom of my heart, just go fuck yourself.
- "CadQuery fails loudly and early... OpenSCAD fails silently and late"
This should be obvious, from the documentation, from the way geometry construction works. OpenSCAD has no sense of failure where one shape means another won't work; you're just drawing the equivalent of 3D pixels in space. It will always potentially-meaninglessly succeed if the syntax is OK.
- Renders caught nothing that mattered
Objects with hollows are not going to show their major problems this way.
- CadQuery can be interrogated, OpenSCAD cannot
Isn't this explicit from the documentation of both? One works by iteratively building on top of a previous result that can be stored in a variable; the other doesn't.
- OpenSCAD renders have no concept of a part edge
Again — this should be explicit from the documentation, which describes no methods for operating on edges.
- Speed favours OpenSCAD, and it barely matters
Yes, being faster is no good if things are wrong.
- "What decides it is verifiability rather than expressiveness, and CadQuery leads there by a wider margin than the syntax difference suggests."
Yes, because the difference is semantic. Which you can get from the documentation. Building iteratively on the basis of existing geometry is inherently more verifiable, because stuff that can't work won't work.
Honestly do people not try learning CAD before they try to get an AI to generate CAD models?
I don't really get it. But then I think text-to-CAD is probably the strongest example of cart-before-horse thinking in the AI world as regards technical work compared to creative work.
after making SEVERAL observations that cadquery is pretty much better overall, they say "ehhh we're going to stay with openscad".
Cynically it always feels to me like they are written by people who not only think end users shouldn't have to learn CAD principles, they themselves shouldn't have to either.
I’m using a single repo for all my models and Claude with build123d (plus a VS Code viz extension). Over time, I’ve built up a little folder of useful skills and I’m generally getting satisfactory results.
That said, I have had my eye on CadQuery and am looking for an excuse to try it. For those in the know: how does it compare to build123d?
The other difference (which I have only read abut) is in the way their assembly constraints work; again Build123D takes the more procedural approach (declaring "joints" etc.)
CadQuery came first; Build123D is sort of a more pythonic, robust restatement of it.
Are you willing to share your work?
Mine is available at https://jnslmk.github.io/build123d-models/?model=drill_stora... One of the things I've found more useful is the generation of a static site to view and download the models. With WASM you can make minor adjustments directly in browser
At a glance, not sure how you're approaching constraints, and what luck you've had with getting language models to be able to juggle them?
It was probably an easy model to get right, since the only "critical" dimension was the radius of the interior. But I was able to tweak the numbers on the support length & some other details relatively easily, and I had a working solution 2 hours of print time later.
(I had a CAD class in highschool, but haven't used it since).
I suspect this may be another case of "LLMs are mainly good at things you're bad at."
Claude Code: Oops, I am sorry but I was wrong.
As you say it is quicker to do it by hand. Now.
I certainly wouldn’t entrust this job to a general-purpose (universal) tool that gets it 99.9 percent right.
But a domain-specific harness? Maybe it could work.
Hardware and engineering dont tolerate hallucinations, trust-me-bro numbers, deviations.
https://github.com/yuechen-li-dev/Aetheris/
It's still kinda buggy but they are actively getting fixed, but Claude and GPTs seemed to work better with my current design than other CAD stacks. Still haven't added threads yet, so can't speak for T3, but generally speaking the generated parts are pretty good quality, and I also got fillets/chamfers working so that's a plus.
I like build123d simply because it can export proper STEP (like CadQuery) but has a nicely python friendly design.
Yuck, this style of LLM output is awful, it’s horrible to read and does a lot to say absolutely nothing.
Using Replicad, I've successfully iterated on a 3d printed enclosure for my electronics project. It's fantastic to get everything parameter based and version controlled from revision 1.