That's exactly how I use Solidworks (and similar parametric CAD software) all the time. It takes some discipline, but the key is for all your geometry and relations to be driven from sketches and equations. Then you just change a value (sketch dimension or global constant), hit rebuild, and everything regenerates fairly reliably.

Don't get me wrong, this is a great project and I love seeing efforts like this, OpenSCAD, etc. add more options in the landscape of parametric CAD.

But I do find the graphical interface very natural for doing creative design work. In fact, sometimes I wish I could literally step into my design in VR and grab and move vertices around in 3 dimensions (eg. when fine tuning non-planar splines).

> I keep designing physical parts for our robots. Motor mounts, sensor brackets, wheel hubs. Every time, the workflow is the same: open a GUI CAD program, click around for an hour, export an STL, realize the bolt pattern is 2mm off, repeat.

This doesn't make sense. When you realize the bolt pattern is 2mm off, you just edit that dimension and let the CAD program recalculate. You don't need to click around for an hour again. That's the beauty of contstraint-based parametric modeling as opposed to, say, modeling in Blender.

The author's program is akin to writing vim to replace Publisher. They're solving entirely different problems. Not to mention, this code-as-model paradigm already exists: OpenSCAD

BTW: I spent a few weekends playing with Microcad (https://microcad.xyz/). It was cool, and had a similar rust feel. I just, for the life of me, couldn't figure out how to do 3d ellipses.

> The geometry engine is manifold, which guarantees watertight meshes from boolean operations. The Rust bindings give us zero-cost abstractions over the C++ core — the operator overloads compile down to direct manifold calls. No garbage collection pauses. No floating point surprises from a scripting layer.

Floating point is incredibly surprising. People seem to believe that a typed programming language eliminates floating point error. Scripting and interpretability has nothing to do with why floating point is hard. Floating point arithmetic is as deterministic in Python as C++ or Rust. The issue is whether people understand the rules. The type system has nothing to do with this, as floating point errors are almost always value errors, not type errors. The only way to avoid floating point errors using formal methods is an actual theorem prover. Rust is nowhere close to being a theorem prover.

> No clicking. No undo. Just recompile.

> That's our mascot. Entirely CSG.

> No garbage collection pauses. No floating point surprises from a scripting layer.

And worst of all, the dreaded "and/but honestly":

> But honestly, the main reason is the toolchain.

Am I misreading things?

[1]: https://github.com/elalish/manifold

This seems a bit wasteful to me. Why do you need an LLM to do the part of controlling Blender? Can't normal code be used to automate this instead? And save a scary amount of electricity in the process...

[1]: https://github.com/ljanyst/ghostscad

Edit: oh I guess sketchup is a surface modeler weird thought it was parametric this whole time, lol someone else said it's a polygon modeler

Yeah I don't know what parametric modeling is apparently, I use a mouse/calipers to model stuff not parameters

There is a solid validator plugin you use before you export an STL to make sure the mesh is closed/a manifold

I only know of another text -> STL AI model, I'm quite a bit more excited about this idea.

Does someone have experience with this?

If you're doing serious CAD work, like designing a whole machine, or working with multiple vendors to get parts manufactured, then it really is worth paying for a commercial CAD system and learning how to use it. All of the commercial CAD systems today support parametric modelling where later operations are updated automatically when the earlier operations are changed by the user.

If you insist on writing code, then even entry level systems like SolidWorks have APIs to do everything from creating the part geometry, defining geometric tolerances and PMI, running simulations, doing different types of analysis, creating machine/tooling instructions (G-code, etc.), exporting to various formats, and a million other things.

And they have workbenches for manufacturing techniques other than 3D printing, like sheet metal, CNC machining, cable routing, injection molding, welding, etc. And most of them have libaries of standard and off the shelf parts, like screws, bolts, nuts, washers, cables and housings, etc. in various standardized sizes so you don't have to model those at all.

For testing, on the higher end, the CAD systems integrate with metrology hardware and they're able to actually measure the manufactured parts and compare against the model to validate that they have the correct shape and meet all of the tolerances. Not as a virtual unit test running in CI, but by actually measuring the physical part.

https://github.com/elalish/manifold

FreeCad is getting somewhere but it is still way behind. The last thing I care about is what language was it implemented with.

This approach is explored by OpenSCAD. No need to reinvent the wheel. But parametric CAD is much more than that.

I specifcally had it spit out a FreeCAD macro, which is basically Python that looks like what you've made.

Fucking A Right!