Nice! I love code-based CAD. Eventually I want to build a tool which uses a hybrid approach: a GUI for things that are hard/tedious to express in code like complicated 2D sketches, with code as the "persistence" layer so at the end you still just have code to maintain, no binary files or piles of XML.
One of the hard parts though will be synchronizing changes between UI and code. I suppose it could start as a unidirectional flow from UI to code... if you were to generate a sketch with something like a loop, it would be hard to recover that code structure from just a bunch of resulting points and line segments.
But anyway, I'm happy to see more code-based CAD approaches pop up. I think there's still a lot to explore in this space.
For my airplane design, I've used Rhino3D (which is 3d modeling, not CAD), and used their Python-based plug-in API to create a very custom, limited scope parametric CAD on it... using a mix of geometric and aerodynamic parameters, and using vortex lattice methods to bridge between them. So the wing chord (MAC) can be set in centimeters, but the wing span set to achieve a specific modeled climb rate. It's all very ad hoc, but also lovely to develop in. Hit run, in three seconds have a freshly-generated OML, use Rhino's UI to make a few changes, confirm I like them, then move those changes to code and re-run. Hit undo/redo a few times to compare the hand-drawn and generated versions, then move on to the next feature.
Do you find you prefer python to grasshopper? I loved how easy it was to connect data sources to geometry, and feedback is instantaneous. never tried the Python plugin.
(a) I started this before grasshopper was mature enough to use.
(b) I haven't looked too much into grasshopper because of that, but my impression was that the version control story was basically non-existent. As pure text, Python is easier to change review and to version.
(c) Having a "real" language to bridge to other languages is fundamental for what I'm doing. For example, the panel code is written in Fortran, and the CFD libraries are written in C++.
Well, it's certainly not parametric CAD -- it's a drawing program that happens to be in 3D, with limited (and, I'm very glad to see, growing) ability to use history for some more structured creation. But the biggest limitation is that it's numerics are mediocre, and subtle -- everything is in float space, and it's very easy to get into a space where things just don't make sense, especially far from the origin. In a CAD tool I'd expect to be able to enforce constraints to resolve this ("these two points must match"); I've been able to do that somewhat with my plug-in when the precision is there but the error stack-up has been too high, but there's also cases where the precision just doesn't exist.
You're in luck! As of a year ago, I work at McNeel on the math team on Rhino's in-house CAD kernel. Luckily, we own the entirety of the kernel, so we are free to improve it. I've been in the field of numerical methods for most of my career in academia and industry, so you are preaching to the converted when you say that Rhino's numerics are mediocre. At McNeel, I'm actively pursuing strategies to improve this situation, although it will be a massive long term project.
Hopefully you know that you can reach out to the McNeel developers directly and on the Discourse forums. But I would also love to chat directly if you're interested. It sounds like you're working on a project that is both sophisticated and interesting, which directly stresses many of the known pain points in the kernel. If you're interested, I can shoot an email to the address you've got listed in your profile from my McNeel email.
I think this definition is a bit too strict. CAD just means computer aided design. Architects use Rhino to design buildings. You use it to design airplanes. CAD doesn't even have to be 3D.
You could design entirely in notepad.exe, and that would be computer aided design by your definition.
Rather than that definition being too strict, this one is too litteral.
It was perfectly reasonable to characterize the tool as not really CAD, even though a 3d drawing/modelling/rendering/visualizing program is on a computer and is part of a design process.
FreeCAD apparently supports OpenSCAD as well as build123d, which looks like a very nice DSL for geometry. Still no 2 way binding tho, unless you count the variable editor in the GUI.
Yeah I like the idea of combining code and a visual editor of some kind. Many of my current openscad projects are just mixing code with SVG files, which is finicky and feels like it could easily be improved.
I haven't tried it yet, but I would think that coming up with variable names for all the little parts and distances and whatnot must be a nightmare! :)
And could someone read the code and understand it?
Depends on the complexity of the model and how you organize it. If it's broken into functions where one function is one relatively simple part of the model, things work pretty nicely. And names are scoped to the function so you don't have to worry about polluting some global scope.
But if you're making something very complicated, code-based CAD sort of falls apart, which is why I'd love to see some sort of hybrid approach.
I too love seeing code-based CAD and the general aspect of using LLM's using code as an expression-intermediary: SQL to data, Swift to CAD, SVG to images of pelicans.
I have not used Constructive Solid Geometry CAD MCPs myself (but I have used some of the AI model creators). Some of the videos I've seen look very cool.
But, I wonder how much longer the claim of "LLM's have strictly no sense of how 3D geometry" works will stand.
Last week I used Claude extensively to design the upgrade to my homemade pontoon boat. In addition to my textual descriptions, I uploaded pictures of hat channel cross-sections with dimensions and screenshots of my CAD drawings. I was asking questions about strength and stability and relationships between parts and evolved the design. It took some sort of world understanding of boats, relationships of parts, types of physical interconnects, materials properties. There's definitely some understanding going on.
---
Actually, show rather than tell. I just took Cadova for a spin, using screenshots of my boat's CAD and the previous conversation. Then I vibe-coded my boat up with Cadova, in an agentic loop with Claude Desktop and VSCode and the Cadova Viewer and screen shots. Pretty wild. Certainly not perfect, and I don't think this is how I would actually go about it, but it was interesting!
There's nothing proprietary, so I'll made a quick GitHub project [1] since the Claude links don't show files.
I've started fresher and am now in an agentic loop in Claude Code, asking it to render the generated 3mf and look at the results and evolve the Swift code to have a model that matches the reference image. Not sure how it will go but it is doing it.... will eventually update the repo.
Funny that you say that. Just yesterday I was playing with the thought of using SDFs. I asked ChatGPT how, given a SDF, I could implement erosion followed by dilation (by the same amount), and ChatGPT said that the entire operation is the identity. Here the LLM failed to see that the erosion step could delete parts of the design. Anyway, it was interesting to see an area where LLMs clearly have no idea what they're talking about.
I've had very poor results trying to reason about geometry with chatgpt (to the point where it hallucinated that a line can intersect a sphere 3 times...) but it would be interesting to have a feedback loop from code to image. I just found out about build123d as a newer variety of cadquery and looking forward to trying an LLM out with it.
This is the base part of my little delta printer. This was an experimental project and not something I planned to publish. The code is unfinished, unorganized and originally written for an older version of Cadova. I’ve patched it to work with the latest release, but otherwise it’s largely unchanged. Posting it as-is for reference: https://github.com/tomasf/m3
Thanks, but that's a 404 for me. Maybe a private repo? I would just like to see something more complex than very simple examples — an actual real project.
Manifold works on solid triangle meshes, OpenCascade is a true BREP kernel that represents solids as edges (straight and curved) and surfaces (not meshed) computed from those edges. There is no triangulation in the root model in OpenCascade.
“Cadova builds on the ideas of OpenSCAD, but replaces its limited language with the power and elegance of Swift. It’s inspired by SwiftUI and designed for developers who want a better way to build models through code. It's cross-platform and works on macOS, Linux and Windows.”
Nice! I love code-based CAD. Eventually I want to build a tool which uses a hybrid approach: a GUI for things that are hard/tedious to express in code like complicated 2D sketches, with code as the "persistence" layer so at the end you still just have code to maintain, no binary files or piles of XML.
One of the hard parts though will be synchronizing changes between UI and code. I suppose it could start as a unidirectional flow from UI to code... if you were to generate a sketch with something like a loop, it would be hard to recover that code structure from just a bunch of resulting points and line segments.
But anyway, I'm happy to see more code-based CAD approaches pop up. I think there's still a lot to explore in this space.
For my airplane design, I've used Rhino3D (which is 3d modeling, not CAD), and used their Python-based plug-in API to create a very custom, limited scope parametric CAD on it... using a mix of geometric and aerodynamic parameters, and using vortex lattice methods to bridge between them. So the wing chord (MAC) can be set in centimeters, but the wing span set to achieve a specific modeled climb rate. It's all very ad hoc, but also lovely to develop in. Hit run, in three seconds have a freshly-generated OML, use Rhino's UI to make a few changes, confirm I like them, then move those changes to code and re-run. Hit undo/redo a few times to compare the hand-drawn and generated versions, then move on to the next feature.
Do you find you prefer python to grasshopper? I loved how easy it was to connect data sources to geometry, and feedback is instantaneous. never tried the Python plugin.
(a) I started this before grasshopper was mature enough to use. (b) I haven't looked too much into grasshopper because of that, but my impression was that the version control story was basically non-existent. As pure text, Python is easier to change review and to version. (c) Having a "real" language to bridge to other languages is fundamental for what I'm doing. For example, the panel code is written in Fortran, and the CFD libraries are written in C++.
Why would you say Rhino 3D "isn't CAD"?
Well, it's certainly not parametric CAD -- it's a drawing program that happens to be in 3D, with limited (and, I'm very glad to see, growing) ability to use history for some more structured creation. But the biggest limitation is that it's numerics are mediocre, and subtle -- everything is in float space, and it's very easy to get into a space where things just don't make sense, especially far from the origin. In a CAD tool I'd expect to be able to enforce constraints to resolve this ("these two points must match"); I've been able to do that somewhat with my plug-in when the precision is there but the error stack-up has been too high, but there's also cases where the precision just doesn't exist.
You're in luck! As of a year ago, I work at McNeel on the math team on Rhino's in-house CAD kernel. Luckily, we own the entirety of the kernel, so we are free to improve it. I've been in the field of numerical methods for most of my career in academia and industry, so you are preaching to the converted when you say that Rhino's numerics are mediocre. At McNeel, I'm actively pursuing strategies to improve this situation, although it will be a massive long term project.
Hopefully you know that you can reach out to the McNeel developers directly and on the Discourse forums. But I would also love to chat directly if you're interested. It sounds like you're working on a project that is both sophisticated and interesting, which directly stresses many of the known pain points in the kernel. If you're interested, I can shoot an email to the address you've got listed in your profile from my McNeel email.
I think this definition is a bit too strict. CAD just means computer aided design. Architects use Rhino to design buildings. You use it to design airplanes. CAD doesn't even have to be 3D.
You could design entirely in notepad.exe, and that would be computer aided design by your definition.
Rather than that definition being too strict, this one is too litteral.
It was perfectly reasonable to characterize the tool as not really CAD, even though a 3d drawing/modelling/rendering/visualizing program is on a computer and is part of a design process.
I'm not gonna argue with you. That's just silly. Have a read here if you want, but I suppose you're just trolling:
https://en.wikipedia.org/wiki/Rhinoceros_3D
https://en.wikipedia.org/wiki/Computer-aided_design
Again with the definitions. That thing you just did was what everyone else calls arguing.
FreeCAD apparently supports OpenSCAD as well as build123d, which looks like a very nice DSL for geometry. Still no 2 way binding tho, unless you count the variable editor in the GUI.
Yeah I like the idea of combining code and a visual editor of some kind. Many of my current openscad projects are just mixing code with SVG files, which is finicky and feels like it could easily be improved.
There's a VScode extension for that! For viewing renderings from cadquery and build123d. Haven't tried it yet, but maybe it's the weekend for it.
https://marketplace.visualstudio.com/items?itemName=bernhard...
> Nice! I love code-based CAD.
I haven't tried it yet, but I would think that coming up with variable names for all the little parts and distances and whatnot must be a nightmare! :)
And could someone read the code and understand it?
Depends on the complexity of the model and how you organize it. If it's broken into functions where one function is one relatively simple part of the model, things work pretty nicely. And names are scoped to the function so you don't have to worry about polluting some global scope.
But if you're making something very complicated, code-based CAD sort of falls apart, which is why I'd love to see some sort of hybrid approach.
> I love code-based CAD.
So do I. A lot.
But wait until you try to pair it with an Agentic AI, it will simply blow you away.
Until, that is, you realize LLM's have strictly no sense of how 3D geometry works, but still, it's amazing.
I too love seeing code-based CAD and the general aspect of using LLM's using code as an expression-intermediary: SQL to data, Swift to CAD, SVG to images of pelicans.
I have not used Constructive Solid Geometry CAD MCPs myself (but I have used some of the AI model creators). Some of the videos I've seen look very cool.
But, I wonder how much longer the claim of "LLM's have strictly no sense of how 3D geometry" works will stand.
Last week I used Claude extensively to design the upgrade to my homemade pontoon boat. In addition to my textual descriptions, I uploaded pictures of hat channel cross-sections with dimensions and screenshots of my CAD drawings. I was asking questions about strength and stability and relationships between parts and evolved the design. It took some sort of world understanding of boats, relationships of parts, types of physical interconnects, materials properties. There's definitely some understanding going on.
---
Actually, show rather than tell. I just took Cadova for a spin, using screenshots of my boat's CAD and the previous conversation. Then I vibe-coded my boat up with Cadova, in an agentic loop with Claude Desktop and VSCode and the Cadova Viewer and screen shots. Pretty wild. Certainly not perfect, and I don't think this is how I would actually go about it, but it was interesting!
There's nothing proprietary, so I'll made a quick GitHub project [1] since the Claude links don't show files.
[1] https://github.com/ConAcademy/WeaselToonCadova
I've started fresher and am now in an agentic loop in Claude Code, asking it to render the generated 3mf and look at the results and evolve the Swift code to have a model that matches the reference image. Not sure how it will go but it is doing it.... will eventually update the repo.
Funny that you say that. Just yesterday I was playing with the thought of using SDFs. I asked ChatGPT how, given a SDF, I could implement erosion followed by dilation (by the same amount), and ChatGPT said that the entire operation is the identity. Here the LLM failed to see that the erosion step could delete parts of the design. Anyway, it was interesting to see an area where LLMs clearly have no idea what they're talking about.
I've had very poor results trying to reason about geometry with chatgpt (to the point where it hallucinated that a line can intersect a sphere 3 times...) but it would be interesting to have a feedback loop from code to image. I just found out about build123d as a newer variety of cadquery and looking forward to trying an LLM out with it.
I'd like to see the code for this more complex object: https://github.com/tomasf/Cadova/wiki
This is the base part of my little delta printer. This was an experimental project and not something I planned to publish. The code is unfinished, unorganized and originally written for an older version of Cadova. I’ve patched it to work with the latest release, but otherwise it’s largely unchanged. Posting it as-is for reference: https://github.com/tomasf/m3
Thanks, but that's a 404 for me. Maybe a private repo? I would just like to see something more complex than very simple examples — an actual real project.
Oops. Yeah, it was private. Should work now. Here's a newer and less messy project: https://github.com/tomasf/advent-candle-bridge
This project uses some very interesting Swift techniques. Is this the new C++ interop? Looks very clean.
Regarding the geometry engine, the README says:
Cadova uses Manifold-Swift, Apus and ThreeMF.
First I hear of those. Curious to see how those compare to things like OpenCascade.
Manifold works on solid triangle meshes, OpenCascade is a true BREP kernel that represents solids as edges (straight and curved) and surfaces (not meshed) computed from those edges. There is no triangulation in the root model in OpenCascade.
So ... meaning Cadova has an underlying Mesh model, like OpenSCAD ... I wonder how they pull off proper filetting and curves.
Manifold is impressive, lots of info here:
https://github.com/elalish/manifold
I find this much more readable than KCL[0], but I also understand the ultimate goals of the two are probably a bit different.
[0]: https://zoo.dev/docs/kcl-samples/pillow-block-bearing
Looks similar to OpenSCAD:
https://en.wikipedia.org/wiki/OpenSCAD
Indeed. The home page of the wiki says as much.
“Cadova builds on the ideas of OpenSCAD, but replaces its limited language with the power and elegance of Swift. It’s inspired by SwiftUI and designed for developers who want a better way to build models through code. It's cross-platform and works on macOS, Linux and Windows.”
I'm pretty sure FreeCAD can be used the same way, ignoring its UI. Just with Python as a core language.