Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • 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)
  • A screw can't be 99.9 percent correct—it has to be 100 percent correct. Microns matter.

    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.

  • 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..
  • 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."

    by fwip
  • 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.
  • The OP seems to be shilling this tool nonstop. Modelrift just seems to be an LLM wrapper.. the original models can handle OpenSCAD just fine.
  • 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.

  • 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.
    by Jemm
  • Interesting. I think if AI is useful at all it will be useful in a partly-GUI context, so I am encouraged.

    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?

    by dofm
  • 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.
  • Sure! but, for 3d printing hobbyist who wants to create and print a cube, both are able to provide a printable cube.
  • 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?

    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'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.
  • such a garbage post for various reasons, but the ending is the kicker

    after making SEVERAL observations that cadquery is pretty much better overall, they say "ehhh we're going to stay with openscad".

  • 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.
  • 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.

    by dofm
  • 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?

  • 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

  • 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 big difference (which I have only read about) 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.

    by dofm
  • 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.

  • 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 (and largely from the fact that it is declarative).

    - 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 build an AI tool to generate CAD models? This feels like yet another situation where people who have not done the foundational conceptual work seem to think that they can avoid it and just work around it with AI.

    by dofm
  • Your mistake is assuming “people” wrote this.
  • > Both toolchains shipped. The difference is in how they fail.

    Yuck, this style of LLM output is awful, it’s horrible to read and does a lot to say absolutely nothing.