With the ability to change one number and regenerate everything
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'm with you. What I've learned from all those "programmatic CAD" threads is that some people just really prefer code over anything else. They also build only simple parts, so it's not an issue for them.
As the author says:
"I wanted to write my parts the way I write firmware. In Rust. With types. With version control."
Yeah, sometimes it seems there is a certain kind of devs who don't just like code for the sake of it, but have an active hostility against GUI tools and visualization in general, for whatever reasons.
I get the appeal of "change a number and regenerate everything" as well as "you can store everything in git" - but there is no reason why a decent visual CAD program couldn't do both of them just as well.
In contrast, the ability to actually see a part in front of me and not having to mentally visualize it the whole time seems substantial to me.
Even as some who would generally prefer graphical CAD software in most cases, sometimes for simple parts like the examples in the linked article code really is just easier.
Sometimes it’s the same when I’m working on texturing for 3D models and I want to combine some texture maps in a specific way, I really don’t want to open Photoshop or similar for something that could be expressed in just a few lines of code. ImageMagick can probably do it, whatever it is, but then I need to learn the incantation.
but there are 0 reasons you can't have that in a visual application as well.
It just needs good domain model design.
I mean it's _not_ trivial. To start with you have to first understand the relationships between your model entities, and how versioning strategy affects your model hierarchy (well, graph basically), and that potentially locks you down on a certain path. But it's totally doable as a hobby project (once you know CAD systems are built - so it's not suitable as ones first CAD project ofc).
The requirement to a) collaborate b) version the work is quite old and well supported industrially. Depending on the application it may not "look or feel" that nice of course.
I guess the key thing is these are not "code first" offerings.
They chose maybe one of the toughest imaginable combinations for a business model. Viable open source businesses are hard (since you don’t own your ip in closed form, hard to explain to investors what the actual value is). 3D businesses are hard.
So it’s hard x hard.
Clearly their _tech_ worked. I guess there is a lesson here - better mousetrap is almost never enough for a viable business.
"I do find the graphical interface very natural for doing creative design work"
As do I!
I don't think there is any correct single answer. People, their workflows, and requirements are different.
It seems we are living in CAD renaissance which is great! So many new promising new companies and free tools popping up.
Personally I would prioritize data stability and visual accessibility. These give user a creative workspace that is intuitive and forgiving. That's why I started doing my own modeler as a side project:
The data model is fully immutable and would enable doing _proper_ model branching when I get there. For now all the user gets is a super robust undo and not needing to save (the model is streamed to disk persistently).
But eventually I would like it to be a visual, robust workbench where you can iterate fast, save versions when feel like it, etc.
(I worked for a decade on various CAD offerings at Trimble including SketchUp so know fairly well what I'm doing but it's still super early)
I am trying to do something similar but inside a GUI - https://lilicad.com/
This is still very basic. Also 100% vibe coded and therefore not as robust as I would like it to be.
To add to this, constructive solid geometry systems like OpenSCAD seem to be practically incapable of doing anything related to surfacing, even if it's just G2 fillets or G2 continuity (much less more advanced work with splines and patches).
I think it's partially a positive feedback loop: the "hacker" tools (OpenSCAD) influence the aesthetic (blocky/square brackets, like in the post), which in turn influences the tools. When creating a simple fillet or a chamfer is an annoying exercise in constructive geometry rather than five mouse clicks, there'll be fewer fillets, chamfers, and flowing surfaces, even when they make mechanical or manufacturing sense; but then that becomes "the look", and people don't even think about fillets.
> 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
Agree, it's really hard to do work where you leverage "feels right" together with code, because even if the iteration loop is really tight ("change a bit of code > look at the results"), it's still loose compared to just clicking and dragging, feels like the mental load is a lot less.
Environment art really changed and became a lot easier with VR, I think maybe it's mostly a perspective thing, adjusting with controllers and dragging a moving is great, but the perspective it gives you really has no comparison and makes it all a lot simpler to get right. I can't wait for the tooling to mature more.
You can do parametric for games too. Building an entire scene using code/data can be very productive when you are trying to tune complex concerns like travel time between arbitrary points on the map (balance). Parametric also makes things like [LLM] automation way more feasible because it's using editor APIs rather than exercising piecemeal scene tools. 1000 lines of c# can do a hell of a lot more damage than a bucket of calls like GetObject, SetComponentProperty, etc. This also allows for much deeper integration and iteration over non-geometric concerns like lighting systems, materials and physics.
These projects are cool but to me they seem like they all come from the place: a programmer opens up a CAD program, and within days concludes that they would prefer if they could use their existing scripting skills to make something instead of learning to use the program, including the parametric features. Which is fine, but as a mechanical engineer 99% of the useful/required features are not there.
Well yeah, that’s the whole point of parametric CAD. I use Fusion360 but everything is a user parameter, use constraints for placements, dimensions are relative fractions of base dimensions, extrudes as distance to a face etc.
If anyone is interested, you can try EngineeringSketchPad (https://acdl.mit.edu/ESP/) which is very similar but much more mature. It also supports simple geometric primitives and boolean operations via a scripting language, but also more general rational curves and surfaces (i.e. BREPs). It has other nice features like differentiation, application-specific views (think structural vs CFD), and an attention to water-tightness/correctness.
The opening paragraph is very telling; the author doesn't seem to understand typical pro-level parametric CAD programs available on the market:
> 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
> That's the beauty of constraint-based parametric modeling as opposed to, say, modeling in Blender.
I was thinking the same thing. This looks more like an API that makes 3d modeling look closer to CAD, but without realizing that CAD is about constraints, parametrizing, and far more.
> but without realizing that CAD is about constraints, parametrizing, and far more
Constraints and parametrizing are the trivial parts of CAD, something you can now implement in a weekend with Claude Code, the MINPACK/SolveSpace test suite, and OpenCascade as an oracle. The hard part is a geometric kernel that can express boundary representations for complex shapes (sketches, chamfers, fillets, etc) and boolean operations while somewhat handling the topographical naming problem without driving the user insane (which existing kernels are still all shit at).
Keywords: Jacobian, Newton-Raphson, Levenberg-Marquardt, Powell dog leg, Schur complements, sparse QR/Cholesky, and so on. The LLM can figure the rest out. Try it yourself!
I recommend Rust because the methods are old and most of the algorithms are already implemented by crates, you just have to wire them together. Like I said the hard part is the b-rep: you’re not going to find anything equivalent to Parasolid or ACIS in the literature or open source.
I can't help but find this comment a little insulting. It's very similar to saying "if, while, else, malloc. The LLM can figure the rest out!" as if CS were a solved thing and the whole challenge weren't assembling those elementary bricks together in computationally efficient and robust ways.
Also more to the point, I doubt you'll have much success with local optimization on general surfaces if you don't have some kind of tessellation or other spacial structure to globalize that a bit, because you can very easily get stuck in local optima even while doing something as trivial as projecting a point onto a surface. Think of anything that "folds", like a U-shape, a point can be very close to one of the branches, but Newton might still find it on the other side if you seeded the optimizer closer to there. It doesn't matter whether you use vanilla Newton or Newton with tricks up to the gills. And anything to do with matrices will only help with local work as well because, well, these are non-linear things.
"Just work in parameter space" is hardly a solution either, considering many mappings encountered in BREPs are outright degenerate in places or stretch the limits floating point stability. And the same issue with local minima will arise, even though the domain is now convex.
So I might even reduce your list to: Taylor expansion, linear solver. You probably don't need much more than that, the difficulty is everything else you're not thinking of.
And remember, this has to be fast, perfectly robust, and commit error under specified tolerance (ideally, something most CAD shops don't even promise).
Yeah but have you tried it? You can throw as many keywords as you want into Claude but it does get things wrong in sometimes subtle ways. I’ve tried it, I know.
Look, I'm not trying to decimate you here but your list of keywords is wrong and I know it because I explored that list last month for a completely different application.
The Jacobian is the first order derivative for a function that accepts a vector as an input and produces a vector as an output, hence it must be a matrix.
Newton-Raphson is an algorithm for finding the roots(=zeroes) of a function. Since the derivative of the minimum of a function is zero, it can be used for solving convex optimization problems.
Levenberg-Marquardt is another way to solve optimization problems.
The Powell dog leg method is new to me, but it is just an extension of Gauss-Newton which you could think of a special casing of Newton-Raphson where the objective function is quadratic (useful for objectives with vector norms aka distances between positions).
Most of the algorithms require solving a linear system for finding the zero of the derivative. The Schur complement is a way to factor the linear system into a bunch of smaller linear systems and sparse QR/Cholesky are an implementation detail of solving linear systems.
Now that we got the buzzwords out of the way I will tell you the problem with your buzzwords. Constraint solving algorithms are SAT or SMT based and generally not optimization based.
Consider the humble circle constraint: a^2 + b^2 = c^2. If you have two circles with differing centers and radii, they may intersect and if they do, they will intersect at two points and this is readily apparent in the equations since c = sqrt(a^2 + b^2) has two solutions. This means you will need some sort of branching inside your algorithm and the optimization algorithms you listed are terrible at this.
Optimization can work well for interactive CAD usage, because geometric sketches tend to be close to the intended solution, and it's fast. It also has the nice property of stability (i.e., with optimization, small changes in parameters tend not to cause large perturbations in the solution). Doing more gets into what you mentioned, and is called chirality or root identification in the literature. That's much more intense computationally, but could be useful especially if cheaper approaches like optimization failed.
We've started a 2D geometric constraint solver at https://github.com/endoli/fiksi doing the constraint part of this in Rust. We're using it internally and so far it works well, though it's still experimental. More constraints and especially better behavior around failure are needed. The latter will likely entail at least doing more with degree of freedom counting, though there's some of that already.
This is something I don't get about the code-based CAD tools. They don't let you specify declarative geometric constraints.
Constraints are useful beyond just designing parts. If you have a parallel mechanism there are only two ways to solve the kinematics/dynamics for it: Constraint solving for rigid contacts or iterative solving by approximating the model with non-rigid contacts via internal springs.
The pull request is to delete the project and open SOLIDWORKS or FreeCAD.
But don't actually delete it. It looks like a nice alternative to OpenSCAD. But like OpenSCAD it's really a niche thing for designs that are highly parametric like fasteners, gears, 3D printed boxes, etc.
Like OpenSCAD using it for normal "irregular" CAD is going to be extremely frustrating. Like editing an SVG in notepad instead of Inkscape.
I still feel like there's a unexplored space where you combine the benefits of both somehow though. Like a code-based CAD but it also has a GUI editor that stays in sync and avoids the need to type in coordinates by hand. That would be extremely difficult though.
I'm sure you didn't intend it as an attack, but it's easy to cross into poisoning the community without meaning to. Many people have been hounded into abandoning HN because of this type of swipe, or at least into never sharing their work here. We all lose when that happens.
It's a pity, because what you wrote was otherwise a fine contribution. if you had begun your comment at the good part ("It looks like a nice alternative [etc.]") it would have been great.
Onshape is just a GUI over the Parasolid geometric modeling kernel, the same kernel used by Solidworks [1]. Whatever their scripting primitives are, they're at best a thin wrapper over Parasolid (which is true for the entire industry - it's all Siemens Parasolid and Dassault ACIS).
Yes, this is all true, but the comment I responded to wanted to be able to basically code rather than GUI sometimes , but still have the GUI up to date. Because of how onshape was built it makes this very very easy. Solidworks very much does not. Fusion360 also has good enough python bindings but it's still nowhere near as easy or integrated to do this (or debug it) as onshape.
So I'm kinda not sure what you are going for here. The fact that they are all the same kernels under the cover is sort of irrelevant. It's not that thin a layer and the layer matters a lot since it is what you get to use. It's like saying all of userspace is just syscalls. That's not what users see or interact with, the layer they interact with matters a lot to them.
My surmise is that this is tightly coupled with Parasolid, so it wouldn't be feasible to create an implementation of this language using some other CAD kernel?
(Click tab manager in the bottom left and you'll get a nicer list of the files involved)
The actual representation is essentially dictionaries. IE transform is a functon that looks like this:
/**
* Construct a [Transform] using the matrix argument for rotation
* and scaling and the vector argument for translation.
*/
export function transform(linear is Matrix, translation is Vector) returns Transform
precondition
{
matrixSize(linear) == [3, 3];
is3dLengthVector(translation);
}
{
return { "linear" : linear, "translation" : translation } as Transform;
}
Fillets, for example, are a whole bunch of featurescript UI around fillet operations:
(The underlying fillet ops are opFullRoundFillet, etc. All of this is UI to generate the parameters and highlight the results and such)
The actual geometry ops are in geomOperations. Those are the geometry primitives you'd have to duplicate, and they are fairly standard. Fillets, holes, CSG, etc.
It would not be a ton of work (IMHO) to have a geometry kernel that supports what they support.
The UI related primitives, the query engine, etc, those are i think where you'd have real work to do.
Note that Graphite does _not_ work with a stylus --- in the web version the input is too jerky/disjointed, for the desktop, it won't react to a stylus in any fashion at all (for the Windows version).
SolveSpace does have some ability to control the color and fill of areas. It's nowhere near as powerful as Inkscape, but enough to make simple diagrams. The exported SVGs can also be edited in Inkscape.
> "highly paramteric like fastners, gears, 3D printed boxes"
1. These parts should probably be on McMaster. If you are not using them straight from there, you better have a _great_ reason as to why not when it comes up in the design review.
2. Solidworks has Smart Fasteners, Inventor has Spur Gear Component Generator, Sketch->Extrude->Shell takes 30 seconds, so not sure why 3D printed boxes would be faster or better with this for most stuff. Also, this stuff is easily solved by things like the component library and configurations.
Are you saying that you don't us McMaster because they don't ship to where you live? That seems silly - you can still download their drawings and then find an alternate source. They are a great listing of everything you might ever want to buy, but you can almost always find an alternative source.
There is also the possibility you think because McMaster is in the US they don't have metric parts. This is wrong, a lot of engineering in the US is done in metric - nearly all big manufacturing companies went metric 40 years ago, so they have plenty of metric parts that you should work with. Of course most manufacturing is small companies that still haven't gone metric, but they also deal with metric once in a while, and in any case you wouldn't be ordering from them anyway.
>I still feel like there's an unexplored space where you combine the benefits of both somehow though. Like a code-based CAD but it also has a GUI editor that stays in sync and avoids the need to type in coordinates by hand. That would be extremely difficult though.
I think you can do this if the data representation of operations and values is human readable. The simplest implementation would restrict the language/data format to operations representable in the gui.
Unlike trying to solve the "visual programming" problems, we don't need or desire Turing completeness.
Draw your free-hand shape in Inkscape, export to SVG, import it in FreeCAD and go from there.
I used that trick to trace a part from an image and it worked surprisingly well. Not very efficient compared to commercial tooling, but despite the clumsiness its fairly intuitive and free.
All the good commercial parametric CAD apps have an API that allow you to define models programatically to avoid repitition, or do more complicated things like ensure gear ratios are exactly correct. I'm not sure I entirely understand what you're getting at with the "stays in sync" part though.
Rhino has no free tier. I’d love to play with it, and it’s where AutoDesk made the right call. It’s why Fusion 360 has such a strong ecosystem for hobbyists / prosumers.
If you like OpenSCAD, you should check https://modelrift.com which is an OpenSCAD browser-based IDE which uses LLM to generate .scad and instantly shows the .stl 3d model result via 3d model viewer. Since AI models are still not good at openscad, the useful feature of modelrift is the "screenshot-powered" iteration where human annotates visual problems and sends it back to AI assistant to fix, all using hotkey shortcuts.
Over the weekend I took pictures of the four walls of my office and asked Claude Desktop to examine them and give me a plan for tackling it. It absolutely “understood” my room, identifying the different (messy) workspaces and various piles of stuff on the ground. It generated a checklist with targeted advice and said that I should be motivated to clean up because the “welcome back daddy” sign up on the wall indicates that my kids love me and want a nice space to share with me.
I vibe-code TUI and GUI by making statements like “make the panel on the right side two pixels thinner”.
Related to this thread, I explored agentic looping for 3d models (with a swift library, could be done with this Rust one by following the workflow:
https://github.com/ConAcademy/WeaselToonCadova
I've found they are actually quite good at semantic geometry even if they struggle with visual or pixel-based reasoning. Since this is parametric the agent just needs to understand the API and constraints rather than visualize the final output. It seems like a code-first interface is exactly what you want for this.
I've even already asked an LLM to generate designs in openscad, and there's plenty of examples out there. Obviously there's a complexity limit, but there's also a cheat sheet that makes it pretty easy to discover how to do almost anything that's possible within.
I had a lot of fun playing around with antimony (also from Keeter) a few years ago, but unfortunately it has been mostly abandoned. I heard libfive is supposed to be the next generation, but I haven't experimented with it yet.
What's nice about this is that it allows for programmatic CAD, enabling things like web applications that can download an .stl file based on user input. I hope I can find a weekend or two to play with it.
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 definition of an ellipsoid is that it can have three independent radii. A revolved ellipse only has two independent radii. If only two independent radii are needed then yes I agree with you, but I wanted to provide a fully qualified answer.
I'm about as into formal methods as you can get, with a deep background in Haskell and such. Rust is wonderful and all that, but sometimes I think the optimism is misplaced and doesn't come from a place of full knowledge. Statements like this make me scared:
> 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.
Yeah, I'd like to see a CAD program which uses integer math at its core for repeatability and to avoid errors such as 10.000 being displayed as 9.999 after multiple scaling operations.
I really like the idea of openscad, or this, or the many alternatives. But when I say a shape with these and these dimensions, the next shape should attach to it somewhere. And then I want to say: chamfer all outside edges. But in all these programs, it's me redoing the math in my code, computing where the shape goes. As for chamfers, I just give up ...
FreeCAD can do this. So can all of the proprietary parametric CAD programs I've ever used, some of which (PTC OnShape, Siemens Solid Edge, Autodesk Fusion) have usable free tiers available.
If you are a programmer OpenSCAD is easier to learn. However you will quickly run into limits. Just a few hours of a FreeCAD tutorial and I was already seeing how I could do things I'd never attempt in OpenSCAD. FreeCAD has a reputation of not being great, but I'm not far enough into it to learn the limits - things I can't figure out feel like things I could learn, in OpenSCAD the things I couldn't figure out where because they were too complex - I could but the code wouldn't be readable so there was no point (not to mention math errors).
FreeCAD is designed for the things real designers really do. OpenSCAD is designed for the things mathematicians do.
Is anyone else put off by the AI-sounding text? Two things that give it away for me are the excessive use of punctuation-emphasized sentence fragments ex:
> No clicking. No undo. Just recompile.
> That's our mascot. Entirely CSG.
> No garbage collection pauses. No floating point surprises from a scripting layer.
> Every render in this post was made that way. Claude generated the geometry with vcad, imported each STL/GLB into Blender via MCP, set up studio lighting, and rendered to PNG. No human touched Blender.
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...
My whole CAD experience is with OpenSCAD, which apparently uses the same kernel; Honest question -- what is the alternative? I would assume the vast majority of 3D model processing relies on triangle meshes...
Meshes are an output, not a source, and not a good internal representation.
Meshes are only a lossy approximation of the actual geometry, and the errors accumulate as features reference off of earlier features.
A simple example is a line tangent to an arc. The line will only be the correct distance from the center of the arc at one point (one angle) per segment.
In openscad you don't notice the problem because since it's code and you have variables and programming ways of expressing relationships, you would usually not try to derive one thing from another by geometry, instead both things would reference a common ancestor variable. But that's a technical implimentation detail that works around the problem by just not doing a thing that doesn't work. The problem is still there that a valid geometry constraint would produce invalid results.
but then the author used the source directly as noted in the Github footnote:
>I ended up directly using solvespace's solver instead of the suggested wrapper code since it didn't expose all of the features I needed. I also had to patch the solver to make it sufficiently fast for the kinds of equations I was generating by symbolically solving equations where applicable.
I've built something very similar (also based on triangle meshes, but in TS), and while it wouldn't work for say 3D printing, my target is game object modeling. I guess people have specific use cases in mind when referring to "CAD".
An example of common terms that disagrees with that somewhat, is "CAD/CAM" where the design component is clearly distinct from the manufacturing component.
I do agree that historically, software aimed at building 3d models for games/animations and other digital use was usually called modeling and not cad. I'm thinking of software like 3D Studio Max back in the 90s here.
I notice though that the Wikipedia article for CAD says: "This software is used to increase the productivity of the designer, improve the quality of design, improve communications through documentation, and to create a database for manufacturing."
my personal distinction I use is about measurements. while you may model to a specific scale for use in 3d gfx (game by engine/animation/vfx) you cross over from "modeling" to "cad" as soon as you are creating geometry with specific real world measurements. (probably for manufacturing or engineering reasons bc thats when it matters most)
like I can model a table that is the right size and looks like it will not tip over for my game, but I am going to cad that table to run a stress sim and make the plans for building it for real.
though id still call the action of doing the building in the cad software "modeling"... so idk.. language is weird.
so software that lets you work accurately with measurements and real units == cad. (fusion360) software that just makes geometry == modeling. (blender)
but if you wanna go get real confused look at "plasticity" an app targeted at "modeling" but uses a cad engine and sells itself as "cad for artists" it has real scale
measurements and everything too.
I've been doing a similar thing using GhostSCAD[1], which is a relatively thin wrapper around OpenSCAD in Go. Not as typesafe, but my language of choice.
SketchUp was my go to for a while but I'm done with parametric personally, trying to fix meshes for 3D printing... time I grow up and use something like Fusion360 seems like or onshape. Still it was good/simple enough for non-round shapes in SketchUp except they have some kind of memory leak/bug at least for the 2017 version. But I guess quit being cheap and buy a modern copy on my part.
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
It's using a constructive solid geometry system. You can add and subtract volumes. Making a hole is subtracting a volume. This has classically been numeric roundoff hell, where points that should coincide and surfaces which should touch don't get handled properly due to numerical error.
The geometry engine is Manifold, which guarantees watertight meshes from boolean operations.
Ah. That's what's doing the constructive solid geometry. Here's the 2009 PhD thesis behind the object merge and difference algorithms inside Manifold. Nice. At last, soundness.
This is a long-standing problem. And now there's an open source implementation. Manifold itself is in C++, not Rust, though.
None of this is parametric. That's a different problem. That's where you put in constraints such as A is perpendicular to B, B is 100mm from C, etc., and the constraint solver tries to satisfy all the constraints. Change a dimension and everything adjusts to preserve the constraints. Parametric CAD is all about constraint solving and expressing conflicts to the user. Autodesk Inventor, Fusion, etc. have good constraint solvers.
Ah. That's good to know. I wondered how they did that. I can see doing it with triangles. Smooth curves are far more difficult.
I'm not an expert at this but I've done CNC machining, used Autodesk Inventor, and coded 3D collision detection. CSG engines were considered mathematical nightmares, and I've used them, but never been inside one. The good ones can take a cylinder and a thread profile, project the thread profile along a spiral as a cutting tool, and make a bolt. Then you can chamfer the end of the bolt, and the ends of the thread are correct.
Just because you type dimensions in doesn't mean it's parametric. If you're manually patching meshes, you're almost certainly not doing parametric CAD! (This does match with my memories of SketchUp, beck when it was owned by Google. I had to fix holes and overlapping geometry by editing the .STL files in Blender before any of the primitive slicer programs could process them.)
OnShape and Fusion360 are fully parametric CAD programs. Another free-tier closed-source one is Siemens Solid Edge (the "Hobbyist" edition). FLOSS parametric CAD programs that are reasonably usable are FreeCAD (complicated but powerful) and SolveSpace (an 80/20 sort of tool -- nowhere near as powerful, but vastly easier to use).
Yeah I learned SketchUp like 17 years ago it's crazy. But I want to make more complex round shapes and ensure it is a solid (for 3D printing) so time to make the jump.
Not to crap on this project too much, but this, and most of the other small CAD projects that get posted here, always have a condescending, "Look how easy I've made this" vibe to them, and then they're always light years behind modern CAD software.
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.
I've found LLMs perform surprisingly well here if you target CSG or OpenSCAD. It seems to frame the 3D modeling challenge as a logic and syntax problem rather than a spatial one, which plays to the model's strengths. You avoid the spatial hallucinations common in image generation because it's effectively just writing code.
Amazing work! This is what I was looking for, I thought of this few months ago and didn't have the time to create it myself. Thanks will explore it and give my feedback!
I am constantly designing parts myself. I just wish that instead of having many unfinished, unpolished products we had something with the level of Solidworks / Onshape / whatever.
FreeCad is getting somewhere but it is still way behind. The last thing I care about is what language was it implemented with.
That is actually not so bad a reason. I use build123d, but want it in haskell, enough to look at how hard it would be to create something similar.
(I also totally agree about the gui being worth having sometimes, and would have loved the ability to fully mix. Code as the main driver, but gui to help choose it. For example to figure out faces and other attachment stuff)
I suspect that Moment of Inspiration and Rhinoceros 3D are something along those lines, but I'm not aware of an opensource tool which hoes that row.
One thing in particular which it would be nice to see would be a facility where one could draw a piece of geometry, then all the coordinates/values which describe it could be displayed in a pane where they could then be named or re-arranged, or the values changed, or even the values changed into formulae.
definitely learn solidworks or something in that vein first
that, and as a prior skill, learn to draw by hand on paper orthogonal and isometric views of 3d objects.
cad is another theory building excercise, but instead of being about processes, its about objects. you want to start from a strong manual/first principles base
If you're more interested int the result than the process, Onshape or Fusion are great, free (with use restrictions) parametric CAD. And both support scripting, to some extent.
Has there been any work on it to make it usable w/ touch or a stylus or a trackpad?
I'm on the verge of breaking down and buying a license for Moment of Inspiration 3D since it was designed for use on tablet computers (which is my preferred sort of hardware).
To rotate the view in SolveSpace, you need any one of these:
* a keyboard's shift key and a right mouse button, or
* a middle mouse button, or
* a 3D mouse.
I've done some work in SolveSpace with a Wacom tablet, by binding the stylus's buttons to the middle and right mouse buttons. SolveSpace is a pretty simple program, so you don't need to dig deep through the UI to get to all the functions. Lost of the often-used functions have keyboard shortcuts, but I don't think there is anything that is only accessible through the keyboard.
Depending on what you aim to do, you might be interested in keeping up with Blender's currently-in-development tablet mode:
Yeah, that's the problem --- Samsung colludes w/ Wacom to deny right-click functionality to their devices using the S-Pen --- really, really, really miss that some days.
I'll keep experimenting w/ this in mind for the next time I'm using my Wacom One attached to my MacBook.
Or Blender, pen and paper, bag of LEGO, etc. Text in context of geometric object is more or less an abstract classification tool, barely a descriptive one.
Everyone knows what a `dice` is. But that's a taxonomical label, not a definition of one. Anyone reading this can probably draw a representative `dice` using only standard stationery supplies in under a minute. Now describe one in English with such rigor and precision that it readily translates to a .gcode file to be printed. That requires a good amount of useful neurodivergence to pull off at all.
The great thing about OpenSCAD is that one can model anything which one can describe using mathematics and cubes, cylinders, spheres, and transformations/relocations of same.
The awful thing about OpenSCAD is that what one can model is bounded by one's fluency with mathematics and one's ability to place and transform cubes, cylinders, and spheres.
I wouldn't call a FOSS project that you compare to some 2,620 USD/year software a dead-end. It's good enough for simple modeling, especially when it comes to scripting, and has been for 10 years already.
If you're using one of the old stable builds, then the newer nightly builds are markedly faster --- hopefully there will be a new stable release presently.
> Types prevent you from passing a radius where a diameter was expected. CAD files should be code. Code has tests, reviews, diffs, and CI. An STL file has... bytes.
GP perhaps did not say it in a polite manner, but their criticism is valid.
Please have a check on a different monitor and browser than you are currently using, as most of the article is unreadable. Code blocks are nigh unreadable, and the screenshots are washed out as if they were HDR with improper tone mapping (I tested both with Firefox on Linux and Safari on iOS).
It's a shame, because it made me gloss over the article.
Oh, and the screenshots have the same issue both on the blog post and on the main vcad.io website. Funnily enough, code snippets on vcad.io have proper readable colors as opposed to your blog (they're still too dim to be comfortable though, but they're readable).
I agree the UI on the screenshot is not very accessible. I'm also think that language and tone choice matter a lot when delivering (even constructive) criticism.
With the ability to change one number and regenerate everything
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'm with you. What I've learned from all those "programmatic CAD" threads is that some people just really prefer code over anything else. They also build only simple parts, so it's not an issue for them.
As the author says:
"I wanted to write my parts the way I write firmware. In Rust. With types. With version control."
Yeah, sometimes it seems there is a certain kind of devs who don't just like code for the sake of it, but have an active hostility against GUI tools and visualization in general, for whatever reasons.
I get the appeal of "change a number and regenerate everything" as well as "you can store everything in git" - but there is no reason why a decent visual CAD program couldn't do both of them just as well.
In contrast, the ability to actually see a part in front of me and not having to mentally visualize it the whole time seems substantial to me.
It depends. I use Solidworks all the time but I think OpenSCAD was a great choice to make this part:
https://github.com/settinger/selectric_typeballs
A bit like how you can edit images in MS Paint, Python, or Photoshop. None of these is or should be a one size fits all solution.
Even as some who would generally prefer graphical CAD software in most cases, sometimes for simple parts like the examples in the linked article code really is just easier.
Sometimes it’s the same when I’m working on texturing for 3D models and I want to combine some texture maps in a specific way, I really don’t want to open Photoshop or similar for something that could be expressed in just a few lines of code. ImageMagick can probably do it, whatever it is, but then I need to learn the incantation.
I agree with the OP:s statement
"With version control"
but there are 0 reasons you can't have that in a visual application as well.
It just needs good domain model design.
I mean it's _not_ trivial. To start with you have to first understand the relationships between your model entities, and how versioning strategy affects your model hierarchy (well, graph basically), and that potentially locks you down on a certain path. But it's totally doable as a hobby project (once you know CAD systems are built - so it's not suitable as ones first CAD project ofc).
Example of a CAD program/system which implements this?
Version control?
Quite a few with their domain specific naming conditions, constraints and workflows.
For example Fusion 360 https://www.autodesk.com/products/fusion-360/blog/fusion-360...
Then there's stuff like "Tekla model sharing" https://www.tekla.com/products/tekla-model-sharing
Onshape https://cad.onshape.com/help/Content/versionmanager.htm
Etc
The requirement to a) collaborate b) version the work is quite old and well supported industrially. Depending on the application it may not "look or feel" that nice of course.
I guess the key thing is these are not "code first" offerings.
I was more thinking opensource options now that Ondsel has folded, but appreciate the information.
Their blog post about this subject is really good https://www.ondsel.com/blog/goodbye/
They chose maybe one of the toughest imaginable combinations for a business model. Viable open source businesses are hard (since you don’t own your ip in closed form, hard to explain to investors what the actual value is). 3D businesses are hard.
So it’s hard x hard.
Clearly their _tech_ worked. I guess there is a lesson here - better mousetrap is almost never enough for a viable business.
"I do find the graphical interface very natural for doing creative design work"
As do I!
I don't think there is any correct single answer. People, their workflows, and requirements are different.
It seems we are living in CAD renaissance which is great! So many new promising new companies and free tools popping up.
Personally I would prioritize data stability and visual accessibility. These give user a creative workspace that is intuitive and forgiving. That's why I started doing my own modeler as a side project:
https://github.com/AdaShape/adashape-open-testing/releases/t...
The data model is fully immutable and would enable doing _proper_ model branching when I get there. For now all the user gets is a super robust undo and not needing to save (the model is streamed to disk persistently).
But eventually I would like it to be a visual, robust workbench where you can iterate fast, save versions when feel like it, etc.
(I worked for a decade on various CAD offerings at Trimble including SketchUp so know fairly well what I'm doing but it's still super early)
I am trying to do something similar but inside a GUI - https://lilicad.com/ This is still very basic. Also 100% vibe coded and therefore not as robust as I would like it to be.
Eagerly awaiting a demo video
To add to this, constructive solid geometry systems like OpenSCAD seem to be practically incapable of doing anything related to surfacing, even if it's just G2 fillets or G2 continuity (much less more advanced work with splines and patches).
I think it's partially a positive feedback loop: the "hacker" tools (OpenSCAD) influence the aesthetic (blocky/square brackets, like in the post), which in turn influences the tools. When creating a simple fillet or a chamfer is an annoying exercise in constructive geometry rather than five mouse clicks, there'll be fewer fillets, chamfers, and flowing surfaces, even when they make mechanical or manufacturing sense; but then that becomes "the look", and people don't even think about fillets.
The thing is, fillets are often recommended as a way to prevent a potential stress-point in a part:
https://wefab.ai/blog/chamfer-vs-fillet-in-3d-printing-a-des...
> 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
Agree, it's really hard to do work where you leverage "feels right" together with code, because even if the iteration loop is really tight ("change a bit of code > look at the results"), it's still loose compared to just clicking and dragging, feels like the mental load is a lot less.
Environment art really changed and became a lot easier with VR, I think maybe it's mostly a perspective thing, adjusting with controllers and dragging a moving is great, but the perspective it gives you really has no comparison and makes it all a lot simpler to get right. I can't wait for the tooling to mature more.
You can do parametric for games too. Building an entire scene using code/data can be very productive when you are trying to tune complex concerns like travel time between arbitrary points on the map (balance). Parametric also makes things like [LLM] automation way more feasible because it's using editor APIs rather than exercising piecemeal scene tools. 1000 lines of c# can do a hell of a lot more damage than a bucket of calls like GetObject, SetComponentProperty, etc. This also allows for much deeper integration and iteration over non-geometric concerns like lighting systems, materials and physics.
These projects are cool but to me they seem like they all come from the place: a programmer opens up a CAD program, and within days concludes that they would prefer if they could use their existing scripting skills to make something instead of learning to use the program, including the parametric features. Which is fine, but as a mechanical engineer 99% of the useful/required features are not there.
Well yeah, that’s the whole point of parametric CAD. I use Fusion360 but everything is a user parameter, use constraints for placements, dimensions are relative fractions of base dimensions, extrudes as distance to a face etc.
If anyone is interested, you can try EngineeringSketchPad (https://acdl.mit.edu/ESP/) which is very similar but much more mature. It also supports simple geometric primitives and boolean operations via a scripting language, but also more general rational curves and surfaces (i.e. BREPs). It has other nice features like differentiation, application-specific views (think structural vs CFD), and an attention to water-tightness/correctness.
The certificate just expired, so mobile Safari is not willing to let me see it. :(
I should have shared this more recent page directly on the manual with examples to begin with: https://flexcompute.github.io/EngineeringSketchPad/EngSketch...
The opening paragraph is very telling; the author doesn't seem to understand typical pro-level parametric CAD programs available on the market:
> 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
> That's the beauty of constraint-based parametric modeling as opposed to, say, modeling in Blender.
I was thinking the same thing. This looks more like an API that makes 3d modeling look closer to CAD, but without realizing that CAD is about constraints, parametrizing, and far more.
> but without realizing that CAD is about constraints, parametrizing, and far more
Constraints and parametrizing are the trivial parts of CAD, something you can now implement in a weekend with Claude Code, the MINPACK/SolveSpace test suite, and OpenCascade as an oracle. The hard part is a geometric kernel that can express boundary representations for complex shapes (sketches, chamfers, fillets, etc) and boolean operations while somewhat handling the topographical naming problem without driving the user insane (which existing kernels are still all shit at).
> Constraints and parametrizing are the trivial parts of CAD, something you can now implement in a weekend with Claude Code
You go ahead and try that.
;)
Keywords: Jacobian, Newton-Raphson, Levenberg-Marquardt, Powell dog leg, Schur complements, sparse QR/Cholesky, and so on. The LLM can figure the rest out. Try it yourself!
I recommend Rust because the methods are old and most of the algorithms are already implemented by crates, you just have to wire them together. Like I said the hard part is the b-rep: you’re not going to find anything equivalent to Parasolid or ACIS in the literature or open source.
I can't help but find this comment a little insulting. It's very similar to saying "if, while, else, malloc. The LLM can figure the rest out!" as if CS were a solved thing and the whole challenge weren't assembling those elementary bricks together in computationally efficient and robust ways.
Also more to the point, I doubt you'll have much success with local optimization on general surfaces if you don't have some kind of tessellation or other spacial structure to globalize that a bit, because you can very easily get stuck in local optima even while doing something as trivial as projecting a point onto a surface. Think of anything that "folds", like a U-shape, a point can be very close to one of the branches, but Newton might still find it on the other side if you seeded the optimizer closer to there. It doesn't matter whether you use vanilla Newton or Newton with tricks up to the gills. And anything to do with matrices will only help with local work as well because, well, these are non-linear things.
"Just work in parameter space" is hardly a solution either, considering many mappings encountered in BREPs are outright degenerate in places or stretch the limits floating point stability. And the same issue with local minima will arise, even though the domain is now convex.
So I might even reduce your list to: Taylor expansion, linear solver. You probably don't need much more than that, the difficulty is everything else you're not thinking of.
And remember, this has to be fast, perfectly robust, and commit error under specified tolerance (ideally, something most CAD shops don't even promise).
Yeah but have you tried it? You can throw as many keywords as you want into Claude but it does get things wrong in sometimes subtle ways. I’ve tried it, I know.
Look, I'm not trying to decimate you here but your list of keywords is wrong and I know it because I explored that list last month for a completely different application.
The Jacobian is the first order derivative for a function that accepts a vector as an input and produces a vector as an output, hence it must be a matrix.
Newton-Raphson is an algorithm for finding the roots(=zeroes) of a function. Since the derivative of the minimum of a function is zero, it can be used for solving convex optimization problems.
Levenberg-Marquardt is another way to solve optimization problems.
The Powell dog leg method is new to me, but it is just an extension of Gauss-Newton which you could think of a special casing of Newton-Raphson where the objective function is quadratic (useful for objectives with vector norms aka distances between positions).
Most of the algorithms require solving a linear system for finding the zero of the derivative. The Schur complement is a way to factor the linear system into a bunch of smaller linear systems and sparse QR/Cholesky are an implementation detail of solving linear systems.
Now that we got the buzzwords out of the way I will tell you the problem with your buzzwords. Constraint solving algorithms are SAT or SMT based and generally not optimization based.
Consider the humble circle constraint: a^2 + b^2 = c^2. If you have two circles with differing centers and radii, they may intersect and if they do, they will intersect at two points and this is readily apparent in the equations since c = sqrt(a^2 + b^2) has two solutions. This means you will need some sort of branching inside your algorithm and the optimization algorithms you listed are terrible at this.
Optimization can work well for interactive CAD usage, because geometric sketches tend to be close to the intended solution, and it's fast. It also has the nice property of stability (i.e., with optimization, small changes in parameters tend not to cause large perturbations in the solution). Doing more gets into what you mentioned, and is called chirality or root identification in the literature. That's much more intense computationally, but could be useful especially if cheaper approaches like optimization failed.
Sure man. Solidworks will be out of business any day now.
[dead]
We've started a 2D geometric constraint solver at https://github.com/endoli/fiksi doing the constraint part of this in Rust. We're using it internally and so far it works well, though it's still experimental. More constraints and especially better behavior around failure are needed. The latter will likely entail at least doing more with degree of freedom counting, though there's some of that already.
A C++-library to be aware of is SolveSpace's slvs: https://github.com/solvespace/solvespace/tree/e74c2eae54fdd9....
This is something I don't get about the code-based CAD tools. They don't let you specify declarative geometric constraints.
Constraints are useful beyond just designing parts. If you have a parallel mechanism there are only two ways to solve the kinematics/dynamics for it: Constraint solving for rigid contacts or iterative solving by approximating the model with non-rigid contacts via internal springs.
Could you mock up some code to describe which you feel would be suitable to describing such a thing?
You're correct, I'm completely uneducated! Pull requests welcome :)
The pull request is to delete the project and open SOLIDWORKS or FreeCAD.
But don't actually delete it. It looks like a nice alternative to OpenSCAD. But like OpenSCAD it's really a niche thing for designs that are highly parametric like fasteners, gears, 3D printed boxes, etc.
Like OpenSCAD using it for normal "irregular" CAD is going to be extremely frustrating. Like editing an SVG in notepad instead of Inkscape.
I still feel like there's a unexplored space where you combine the benefits of both somehow though. Like a code-based CAD but it also has a GUI editor that stays in sync and avoids the need to type in coordinates by hand. That would be extremely difficult though.
> The pull request is to delete the project
Ouch. Please don't attack someone's work this way. It's too aggressive and against the site guidelines: https://news.ycombinator.com/newsguidelines.html.
I'm sure you didn't intend it as an attack, but it's easy to cross into poisoning the community without meaning to. Many people have been hounded into abandoning HN because of this type of swipe, or at least into never sharing their work here. We all lose when that happens.
It's a pity, because what you wrote was otherwise a fine contribution. if you had begun your comment at the good part ("It looks like a nice alternative [etc.]") it would have been great.
This is actually what onshape is, under the covers.
The GUI is really just using their scripting primitives, etc. You can access it the same as they can, actually.
Onshape is just a GUI over the Parasolid geometric modeling kernel, the same kernel used by Solidworks [1]. Whatever their scripting primitives are, they're at best a thin wrapper over Parasolid (which is true for the entire industry - it's all Siemens Parasolid and Dassault ACIS).
[1] https://en.wikipedia.org/wiki/Parasolid#Applications
Yes, this is all true, but the comment I responded to wanted to be able to basically code rather than GUI sometimes , but still have the GUI up to date. Because of how onshape was built it makes this very very easy. Solidworks very much does not. Fusion360 also has good enough python bindings but it's still nowhere near as easy or integrated to do this (or debug it) as onshape.
So I'm kinda not sure what you are going for here. The fact that they are all the same kernels under the cover is sort of irrelevant. It's not that thin a layer and the layer matters a lot since it is what you get to use. It's like saying all of userspace is just syscalls. That's not what users see or interact with, the layer they interact with matters a lot to them.
For folks who are curious about this, see:
https://cad.onshape.com/FsDoc/
My surmise is that this is tightly coupled with Parasolid, so it wouldn't be feasible to create an implementation of this language using some other CAD kernel?
You could port it, but i don't think the geometry kernel is the hard part.
The code for the standard library is here: https://cad.onshape.com/documents/12312312345abcabcabcdeff/w...
(Click tab manager in the bottom left and you'll get a nicer list of the files involved)
The actual representation is essentially dictionaries. IE transform is a functon that looks like this:
Fillets, for example, are a whole bunch of featurescript UI around fillet operations:https://cad.onshape.com/documents/12312312345abcabcabcdeff/w...
(The underlying fillet ops are opFullRoundFillet, etc. All of this is UI to generate the parameters and highlight the results and such)
The actual geometry ops are in geomOperations. Those are the geometry primitives you'd have to duplicate, and they are fairly standard. Fillets, holes, CSG, etc.
It would not be a ton of work (IMHO) to have a geometry kernel that supports what they support.
The UI related primitives, the query engine, etc, those are i think where you'd have real work to do.
Ah sorry, I misunderstood.
And both of them were written by Ian Braid, Alan Grayer, and Charles Lang (and others) in Cambridge.
Parasolid was v1 and old school C, then they got the C++ bug like many of us at the time and did ACIS as v2.
> Like editing an SVG in notepad instead of Inkscape.
Speaking of which, I would love to have parametric capabilities in Inkscape.
https://graphite.art/
https://paragraphic.design/
Note that Graphite does _not_ work with a stylus --- in the web version the input is too jerky/disjointed, for the desktop, it won't react to a stylus in any fashion at all (for the Windows version).
I recently stumbled across cuttle.xyz, and it’s a code-based parametric vector editor. I recently did a real world art project in it and LOVED it.
FWIW, the FLOSS CAD program SolveSpace can generate parametric sketches and export them as SVG files (file > export 2d view)
Is there a facility when doing this for controlling colour/fill?
SolveSpace does have some ability to control the color and fill of areas. It's nowhere near as powerful as Inkscape, but enough to make simple diagrams. The exported SVGs can also be edited in Inkscape.
Nice! (if memory serves, the last time this came up that wasn't possible)
> "highly paramteric like fastners, gears, 3D printed boxes"
1. These parts should probably be on McMaster. If you are not using them straight from there, you better have a _great_ reason as to why not when it comes up in the design review.
2. Solidworks has Smart Fasteners, Inventor has Spur Gear Component Generator, Sketch->Extrude->Shell takes 30 seconds, so not sure why 3D printed boxes would be faster or better with this for most stuff. Also, this stuff is easily solved by things like the component library and configurations.
> you better have a _great_ reason as to why not
Because I don't live in America?
Are you saying that you don't us McMaster because they don't ship to where you live? That seems silly - you can still download their drawings and then find an alternate source. They are a great listing of everything you might ever want to buy, but you can almost always find an alternative source.
There is also the possibility you think because McMaster is in the US they don't have metric parts. This is wrong, a lot of engineering in the US is done in metric - nearly all big manufacturing companies went metric 40 years ago, so they have plenty of metric parts that you should work with. Of course most manufacturing is small companies that still haven't gone metric, but they also deal with metric once in a while, and in any case you wouldn't be ordering from them anyway.
Are ISO standard parts not used where you live? McMaster is in the US but the much of the parts and CAD are standard
I download and use parts dimensioned in metric to ISO standards all the time...
>I still feel like there's an unexplored space where you combine the benefits of both somehow though. Like a code-based CAD but it also has a GUI editor that stays in sync and avoids the need to type in coordinates by hand. That would be extremely difficult though.
I think you can do this if the data representation of operations and values is human readable. The simplest implementation would restrict the language/data format to operations representable in the gui.
Unlike trying to solve the "visual programming" problems, we don't need or desire Turing completeness.
Very interesting indeed!
Ha! Since you mention SVG, there is a trick!
Draw your free-hand shape in Inkscape, export to SVG, import it in FreeCAD and go from there.
I used that trick to trace a part from an image and it worked surprisingly well. Not very efficient compared to commercial tooling, but despite the clumsiness its fairly intuitive and free.
All the good commercial parametric CAD apps have an API that allow you to define models programatically to avoid repitition, or do more complicated things like ensure gear ratios are exactly correct. I'm not sure I entirely understand what you're getting at with the "stays in sync" part though.
Are you aware of Rhino 3D with grasshopper?
Rhino has no free tier. I’d love to play with it, and it’s where AutoDesk made the right call. It’s why Fusion 360 has such a strong ecosystem for hobbyists / prosumers.
A more affordable option is Moment of Inspiration 3D (written by the same dev who did Rhino originally) which also has a node editor available:
https://moi3d.com/forum/messages.php?webtag=MOI&msg=11614.11...
If you like OpenSCAD, you should check https://modelrift.com which is an OpenSCAD browser-based IDE which uses LLM to generate .scad and instantly shows the .stl 3d model result via 3d model viewer. Since AI models are still not good at openscad, the useful feature of modelrift is the "screenshot-powered" iteration where human annotates visual problems and sends it back to AI assistant to fix, all using hotkey shortcuts.
Read a bit before critisizing:
> One thing I care about that most CAD tools don't: vcad is designed to be used by AI coding agents.
AI coding agents are notoriously bad at anything that involves spatial awareness.
Over the weekend I took pictures of the four walls of my office and asked Claude Desktop to examine them and give me a plan for tackling it. It absolutely “understood” my room, identifying the different (messy) workspaces and various piles of stuff on the ground. It generated a checklist with targeted advice and said that I should be motivated to clean up because the “welcome back daddy” sign up on the wall indicates that my kids love me and want a nice space to share with me.
I vibe-code TUI and GUI by making statements like “make the panel on the right side two pixels thinner”.
Related to this thread, I explored agentic looping for 3d models (with a swift library, could be done with this Rust one by following the workflow: https://github.com/ConAcademy/WeaselToonCadova
I've found they are actually quite good at semantic geometry even if they struggle with visual or pixel-based reasoning. Since this is parametric the agent just needs to understand the API and constraints rather than visualize the final output. It seems like a code-first interface is exactly what you want for this.
For that there’s openscad
Breaks down for complex parts with lots of repeated operations, suffers from floating point rounding errors. No constraint solver.
Usually when one needs constraints one can code it up as a recursive function.
That’s certainly not the case for most situations where a constraint solver is useful
Worked for the one time I needed it, and it seems to be a frequently used technique for folks using OpenSCAD.
Curious if something different could be achieved using Python....
I've even already asked an LLM to generate designs in openscad, and there's plenty of examples out there. Obviously there's a complexity limit, but there's also a cheat sheet that makes it pretty easy to discover how to do almost anything that's possible within.
[dead]
This sounds a lot like Fidget (https://github.com/mkeeter/fidget) and libfive (https://github.com/libfive/libfive) by the amazing Matt Keeter!
I had a lot of fun playing around with antimony (also from Keeter) a few years ago, but unfortunately it has been mostly abandoned. I heard libfive is supposed to be the next generation, but I haven't experimented with it yet.
Do you know how it compares?
Hadn't ran into these, thanks!
What's nice about this is that it allows for programmatic CAD, enabling things like web applications that can download an .stl file based on user input. I hope I can find a weekend or two to play with it.
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.
Here's an ellipsoid in build123d using geometric transformation of a sphere:
Also, FYI build123d now runs in the browser thanks to OCP.wasm. Example playground here https://jojain.github.io/build123d-sandbox/If you are using build123d, probably the easiest way is to sketch an ellipse and revolve it.
The definition of an ellipsoid is that it can have three independent radii. A revolved ellipse only has two independent radii. If only two independent radii are needed then yes I agree with you, but I wanted to provide a fully qualified answer.
build123d isn't Microcad
I'm about as into formal methods as you can get, with a deep background in Haskell and such. Rust is wonderful and all that, but sometimes I think the optimism is misplaced and doesn't come from a place of full knowledge. Statements like this make me scared:
> 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.
Yeah, I'd like to see a CAD program which uses integer math at its core for repeatability and to avoid errors such as 10.000 being displayed as 9.999 after multiple scaling operations.
Note that there's an existing CAD-in-Rust project, Fornjot, which has been quietly developing since 2020: https://www.fornjot.app/
Neither Fornjot nor Truck are ready for general use as a BREP CAD kernel.
Also Truck https://github.com/ricosjp/truck
I really like the idea of openscad, or this, or the many alternatives. But when I say a shape with these and these dimensions, the next shape should attach to it somewhere. And then I want to say: chamfer all outside edges. But in all these programs, it's me redoing the math in my code, computing where the shape goes. As for chamfers, I just give up ...
> chamfer all outside edges
FreeCAD can do this. So can all of the proprietary parametric CAD programs I've ever used, some of which (PTC OnShape, Siemens Solid Edge, Autodesk Fusion) have usable free tiers available.
If you are a programmer OpenSCAD is easier to learn. However you will quickly run into limits. Just a few hours of a FreeCAD tutorial and I was already seeing how I could do things I'd never attempt in OpenSCAD. FreeCAD has a reputation of not being great, but I'm not far enough into it to learn the limits - things I can't figure out feel like things I could learn, in OpenSCAD the things I couldn't figure out where because they were too complex - I could but the code wouldn't be readable so there was no point (not to mention math errors).
FreeCAD is designed for the things real designers really do. OpenSCAD is designed for the things mathematicians do.
BOSL2 is a great library to use with Openscad. It provides a bunch of primitives shapes functions with chamfer/rounding parameters.
Math doesn't go away tho
Yup, the attachments with BOSL2 are really great. You can do a ton without much math at all, TBH.
https://github.com/BelfrySCAD/BOSL2/wiki/attachments.scad#se...
Build123d can do chamfers. You can also do relative positioning by selecting positions from the first shape. (there's various ways to do that)
Aren't a few definitions missing from the examples (e.g. base_holes and wall_holes)?
Is anyone else put off by the AI-sounding text? Two things that give it away for me are the excessive use of punctuation-emphasized sentence fragments ex:
> 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?
> Am I misreading things?
Probably not.
There's also this at the bottom.
> One thing I care about that most CAD tools don't: vcad is designed to be used by AI coding agents.
Thanks for the feedback
CLAUDE.md in the repo and "Co-Authored by Claude" on all the commits too.
Hard pass.
Yeah I hate it. Why should I read something you didn't bother to write?
> Every render in this post was made that way. Claude generated the geometry with vcad, imported each STL/GLB into Blender via MCP, set up studio lighting, and rendered to PNG. No human touched Blender.
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...
Unfortunately, using a geometry kernel [1] that operates on triangle meshes means this is a no-go for serious CAD usage.
[1]: https://github.com/elalish/manifold
My whole CAD experience is with OpenSCAD, which apparently uses the same kernel; Honest question -- what is the alternative? I would assume the vast majority of 3D model processing relies on triangle meshes...
Meshes are an output, not a source, and not a good internal representation.
Meshes are only a lossy approximation of the actual geometry, and the errors accumulate as features reference off of earlier features.
A simple example is a line tangent to an arc. The line will only be the correct distance from the center of the arc at one point (one angle) per segment.
In openscad you don't notice the problem because since it's code and you have variables and programming ways of expressing relationships, you would usually not try to derive one thing from another by geometry, instead both things would reference a common ancestor variable. But that's a technical implimentation detail that works around the problem by just not doing a thing that doesn't work. The problem is still there that a valid geometry constraint would produce invalid results.
Breps. Nearly all commercial cad packages operate on boundary representations of objects.
Mesh is also a boundary representation. I think you meam NURBS.
It's just the name, BREP stands for Boundary REPresentation.
I would start with CSG if you are new to these ideas:
https://en.wikipedia.org/wiki/Constructive_solid_geometry
OpenCASCADE?
https://dev.opencascade.org/
Notably wrapped by build123d into cad as a code package
pythonocc is a joy
https://github.com/tpaviot/pythonocc-core
SolveSpace is available in library form. It uses NURBS to represent surfaces, with triangles as a fallback.
https://solvespace.com/library.pl
Notably the library was used (at least for a while) in the development of Dune 3D:
https://dune3d.org/
but then the author used the source directly as noted in the Github footnote:
>I ended up directly using solvespace's solver instead of the suggested wrapper code since it didn't expose all of the features I needed. I also had to patch the solver to make it sufficiently fast for the kinds of equations I was generating by symbolically solving equations where applicable.
libfive
I've built something very similar (also based on triangle meshes, but in TS), and while it wouldn't work for say 3D printing, my target is game object modeling. I guess people have specific use cases in mind when referring to "CAD".
In my mind, cad that you’re not going to manufacture is “modeling”. Not sure if that’s a common verbal distinction.
An example of common terms that disagrees with that somewhat, is "CAD/CAM" where the design component is clearly distinct from the manufacturing component.
I do agree that historically, software aimed at building 3d models for games/animations and other digital use was usually called modeling and not cad. I'm thinking of software like 3D Studio Max back in the 90s here.
https://en.wikipedia.org/wiki/CAD/CAM
I notice though that the Wikipedia article for CAD says: "This software is used to increase the productivity of the designer, improve the quality of design, improve communications through documentation, and to create a database for manufacturing."
https://en.wikipedia.org/wiki/Computer-aided_design
my personal distinction I use is about measurements. while you may model to a specific scale for use in 3d gfx (game by engine/animation/vfx) you cross over from "modeling" to "cad" as soon as you are creating geometry with specific real world measurements. (probably for manufacturing or engineering reasons bc thats when it matters most)
like I can model a table that is the right size and looks like it will not tip over for my game, but I am going to cad that table to run a stress sim and make the plans for building it for real.
though id still call the action of doing the building in the cad software "modeling"... so idk.. language is weird.
so software that lets you work accurately with measurements and real units == cad. (fusion360) software that just makes geometry == modeling. (blender)
but if you wanna go get real confused look at "plasticity" an app targeted at "modeling" but uses a cad engine and sells itself as "cad for artists" it has real scale measurements and everything too.
Not sure either but sharing the sentiment.
I've been doing a similar thing using GhostSCAD[1], which is a relatively thin wrapper around OpenSCAD in Go. Not as typesafe, but my language of choice.
[1]: https://github.com/ljanyst/ghostscad
Note that a while back Python support was added to a soft-fork of OpenSCAD:
https://pythonscad.org/
SketchUp was my go to for a while but I'm done with parametric personally, trying to fix meshes for 3D printing... time I grow up and use something like Fusion360 seems like or onshape. Still it was good/simple enough for non-round shapes in SketchUp except they have some kind of memory leak/bug at least for the 2017 version. But I guess quit being cheap and buy a modern copy on my part.
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
It's using a constructive solid geometry system. You can add and subtract volumes. Making a hole is subtracting a volume. This has classically been numeric roundoff hell, where points that should coincide and surfaces which should touch don't get handled properly due to numerical error. The geometry engine is Manifold, which guarantees watertight meshes from boolean operations.
Ah. That's what's doing the constructive solid geometry. Here's the 2009 PhD thesis behind the object merge and difference algorithms inside Manifold. Nice. At last, soundness. This is a long-standing problem. And now there's an open source implementation. Manifold itself is in C++, not Rust, though.
None of this is parametric. That's a different problem. That's where you put in constraints such as A is perpendicular to B, B is 100mm from C, etc., and the constraint solver tries to satisfy all the constraints. Change a dimension and everything adjusts to preserve the constraints. Parametric CAD is all about constraint solving and expressing conflicts to the user. Autodesk Inventor, Fusion, etc. have good constraint solvers.
[1] https://github.com/elalish/manifold/blob/master/docs/RobustB...
Manifold (which is doing the heavy lifting in this) uses triangles, which are an approximation.
This is never going to have the accuracy seen in higher-end CAD circles, which use b-Reps: highly accurate mathematic representation.
Manifold is good for visualization, but to use it as an engine for manufacturing .. its limits will be hit.
Ah. That's good to know. I wondered how they did that. I can see doing it with triangles. Smooth curves are far more difficult.
I'm not an expert at this but I've done CNC machining, used Autodesk Inventor, and coded 3D collision detection. CSG engines were considered mathematical nightmares, and I've used them, but never been inside one. The good ones can take a cylinder and a thread profile, project the thread profile along a spiral as a cutting tool, and make a bolt. Then you can chamfer the end of the bolt, and the ends of the thread are correct.
Just because you type dimensions in doesn't mean it's parametric. If you're manually patching meshes, you're almost certainly not doing parametric CAD! (This does match with my memories of SketchUp, beck when it was owned by Google. I had to fix holes and overlapping geometry by editing the .STL files in Blender before any of the primitive slicer programs could process them.)
OnShape and Fusion360 are fully parametric CAD programs. Another free-tier closed-source one is Siemens Solid Edge (the "Hobbyist" edition). FLOSS parametric CAD programs that are reasonably usable are FreeCAD (complicated but powerful) and SolveSpace (an 80/20 sort of tool -- nowhere near as powerful, but vastly easier to use).
Yeah I learned SketchUp like 17 years ago it's crazy. But I want to make more complex round shapes and ensure it is a solid (for 3D printing) so time to make the jump.
SketchUp uses direct modelling, not parametric modelling. I think they even got some patents on direct modelling.
Not to crap on this project too much, but this, and most of the other small CAD projects that get posted here, always have a condescending, "Look how easy I've made this" vibe to them, and then they're always light years behind modern CAD software.
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.
Curious to how well LLM's work in this context! (mentioned as one of the reasons to embed CAD in Rust)
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?
I've found LLMs perform surprisingly well here if you target CSG or OpenSCAD. It seems to frame the 3D modeling challenge as a logic and syntax problem rather than a spatial one, which plays to the model's strengths. You avoid the spatial hallucinations common in image generation because it's effectively just writing code.
Amazing work! This is what I was looking for, I thought of this few months ago and didn't have the time to create it myself. Thanks will explore it and give my feedback!
Based on a geometry engine written in C++ ...
https://github.com/elalish/manifold
I am constantly designing parts myself. I just wish that instead of having many unfinished, unpolished products we had something with the level of Solidworks / Onshape / whatever.
FreeCad is getting somewhere but it is still way behind. The last thing I care about is what language was it implemented with.
OpenSCAD is quite polished (for a programmatic mesh modeler).
There is a soft-fork which adds Python:
https://pythonscad.org/
which I've found quite useful: https://github.com/WillAdams/gcodepreview in particular, working up a facility to write out DXFs w/ arcs
Why not use OpenSCAD?
Because it is not written in Rust, I suppose.
Anyway, I think using only code for designing 3D objects is a poor design choice. You really need something that is between pure code and pure GUI.
That is actually not so bad a reason. I use build123d, but want it in haskell, enough to look at how hard it would be to create something similar.
(I also totally agree about the gui being worth having sometimes, and would have loved the ability to fully mix. Code as the main driver, but gui to help choose it. For example to figure out faces and other attachment stuff)
I would really like to see someone work that up.
I suspect that Moment of Inspiration and Rhinoceros 3D are something along those lines, but I'm not aware of an opensource tool which hoes that row.
One thing in particular which it would be nice to see would be a facility where one could draw a piece of geometry, then all the coordinates/values which describe it could be displayed in a pane where they could then be named or re-arranged, or the values changed, or even the values changed into formulae.
Surprised no one is mentioning BRL-CAD. This is exactly how BRL-CAD works! https://brlcad.org/
This is not parametric CAD. Not useful anyway. You need much more complicated engine.
This approach is explored by OpenSCAD. No need to reinvent the wheel. But parametric CAD is much more than that.
Great work! Please consider adding a RSS/Atom Feed to your site. I would like to include it in my Tech Content Platform: https://insidestack.it
Done, thanks for the kind words!
Great, I already added you!
I wish there was a JSON representation of the geometry, so we don't have to code and compile. :P
I get the sense that this author is looking for a DSL (domain specific language) and landed quite close.
Note that one of the co-authors of the source is "Claude"
Interesting, because I am trying to learn OpenSCAD for some simple modeling.
definitely learn solidworks or something in that vein first
that, and as a prior skill, learn to draw by hand on paper orthogonal and isometric views of 3d objects.
cad is another theory building excercise, but instead of being about processes, its about objects. you want to start from a strong manual/first principles base
I liked CATIA, but can't afford it at the moment.
If you're more interested int the result than the process, Onshape or Fusion are great, free (with use restrictions) parametric CAD. And both support scripting, to some extent.
Both have really great documentation/examples.
for simple learning, I invite you to consider SolveSpace
Has there been any work on it to make it usable w/ touch or a stylus or a trackpad?
I'm on the verge of breaking down and buying a license for Moment of Inspiration 3D since it was designed for use on tablet computers (which is my preferred sort of hardware).
To rotate the view in SolveSpace, you need any one of these:
* a keyboard's shift key and a right mouse button, or * a middle mouse button, or * a 3D mouse.
I've done some work in SolveSpace with a Wacom tablet, by binding the stylus's buttons to the middle and right mouse buttons. SolveSpace is a pretty simple program, so you don't need to dig deep through the UI to get to all the functions. Lost of the often-used functions have keyboard shortcuts, but I don't think there is anything that is only accessible through the keyboard.
Depending on what you aim to do, you might be interested in keeping up with Blender's currently-in-development tablet mode:
https://code.blender.org/2025/07/beyond-mouse-keyboard/
Yeah, that's the problem --- Samsung colludes w/ Wacom to deny right-click functionality to their devices using the S-Pen --- really, really, really miss that some days.
I'll keep experimenting w/ this in mind for the next time I'm using my Wacom One attached to my MacBook.
Note: This is probably a dead-end; it is not on the same level as SolidWorks, Fusion etc.
Or Blender, pen and paper, bag of LEGO, etc. Text in context of geometric object is more or less an abstract classification tool, barely a descriptive one.
Everyone knows what a `dice` is. But that's a taxonomical label, not a definition of one. Anyone reading this can probably draw a representative `dice` using only standard stationery supplies in under a minute. Now describe one in English with such rigor and precision that it readily translates to a .gcode file to be printed. That requires a good amount of useful neurodivergence to pull off at all.
The great thing about OpenSCAD is that one can model anything which one can describe using mathematics and cubes, cylinders, spheres, and transformations/relocations of same.
The awful thing about OpenSCAD is that what one can model is bounded by one's fluency with mathematics and one's ability to place and transform cubes, cylinders, and spheres.
I wouldn't call a FOSS project that you compare to some 2,620 USD/year software a dead-end. It's good enough for simple modeling, especially when it comes to scripting, and has been for 10 years already.
Solidworks is $48/year for hobbyists though, and Fusion is free.
You're probably right, OpenSCAD seems to be limited both in speed and in exactness of the surfaces.
However purely programmatic interface allows doing surprising things which might be hard to achieve with a mouse.
If you're using one of the old stable builds, then the newer nightly builds are markedly faster --- hopefully there will be a new stable release presently.
How could I make it better?
Sorry about the confusion - I'm referring to OpenSCAD; not your project.
This reminds me of PoVRay... in a good way.
Note that OpenSCAD came about as a result of Art of Illusion.
I had Google Gemini 3 write me a part using human language about 3 weeks ago for a 3D printing project.
I specifcally had it spit out a FreeCAD macro, which is basically Python that looks like what you've made.
> Types prevent you from passing a radius where a diameter was expected. CAD files should be code. Code has tests, reviews, diffs, and CI. An STL file has... bytes.
Fucking A Right!
[dead]
[flagged]
[flagged]
GP perhaps did not say it in a polite manner, but their criticism is valid.
Please have a check on a different monitor and browser than you are currently using, as most of the article is unreadable. Code blocks are nigh unreadable, and the screenshots are washed out as if they were HDR with improper tone mapping (I tested both with Firefox on Linux and Safari on iOS).
It's a shame, because it made me gloss over the article.
Oh, and the screenshots have the same issue both on the blog post and on the main vcad.io website. Funnily enough, code snippets on vcad.io have proper readable colors as opposed to your blog (they're still too dim to be comfortable though, but they're readable).
[flagged]
I agree the UI on the screenshot is not very accessible. I'm also think that language and tone choice matter a lot when delivering (even constructive) criticism.
Thank for the feedback. Have a nice day.
Yet another rewrite-it-in-rust-just-because project. I'll stick with OpenSCAD