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.<p>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.<p>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.<p>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.<p>Rather than that definition being too strict, this one is too litteral.<p>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:<p><a href="https://en.wikipedia.org/wiki/Rhinoceros_3D" rel="nofollow">https://en.wikipedia.org/wiki/Rhinoceros_3D</a><p><a href="https://en.wikipedia.org/wiki/Computer-aided_design" rel="nofollow">https://en.wikipedia.org/wiki/Computer-aided_design</a>
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.
> Nice! I love code-based CAD.<p>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! :)<p>And could someone read the code and understand it?
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.<p><a href="https://marketplace.visualstudio.com/items?itemName=bernhard-42.ocp-cad-viewer" rel="nofollow">https://marketplace.visualstudio.com/items?itemName=bernhard...</a>
> I love code-based CAD.<p>So do I. A lot.<p>But wait until you try to pair it with an Agentic AI, it will simply blow you away.<p>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.<p>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.<p>But, I wonder how much longer the claim of "LLM's have strictly no sense of how 3D geometry" works will stand.<p>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.<p>---<p>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!<p>There's nothing proprietary, so I'll made a quick GitHub project [1] since the Claude links don't show files.<p>[1] <a href="https://github.com/ConAcademy/WeaselToonCadova" rel="nofollow">https://github.com/ConAcademy/WeaselToonCadova</a>
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.