µcad: New open source programming language that can generate 2D sketches and 3D objects
21 points by lenny
21 points by lenny
This might be their most compelling landing page actually? https://microcad.xyz/index.php/2025/11/12/lego-bricks/
In broad strokes this seems similar to the widely-used OpenSCAD. Given the very incomplete state of documentation for this project, it's hard to make a comparison. What are the intended advantages?
poking through the documentation, it looks like there is (or will be) a way to measure features of objects, which is not part of the OpenSCAD language. (In recent builds on OpenSCAD, there is UI to manually measure distances and angles in objects, which is very helpful for creating complex models, or understanding and modifying models created by other people.)
https://docs.microcad.xyz/language/book/types/models/measures.html
It seems to me pretty close to scad, but with more rust-like syntax. I feel it's an upgrade, but at the same time I don't think theres much benefit creating something entirely new, as for example you can use Clojure to generate openscad objects
openscad is for me too slow once you make the design complex enough, perhaps this will have benefits w.r.t. speed?
Another abstraction on Manifold. Another non-BREP code CAD language. While more languages is great, I really wish resources would be spent on existing efforts... Recently Python has been included into OpenSCAD (after a lot of fighting, but still, it had to be proven).
I'm not convinced by the "our language is better". OpenSCAD has been used by some pretty insane projects. Yes, it can be hard to wrap your head at first, but it's not terrible.
While Manifold is absolutely incredible, I'd rather use FREP/SDF based kernels for my CSG fun. You can learn dual contouring or marching cubes & the SDF math in much shorter time than building anything else.
Obviously the best is using a BREP kernel.
Lately I've wondered if a surface modeling-only kernel would be more powerful for code CAD users while still being easier to build than a typical BREP one...
What is "Manifold", "BREP", "FREP", and "SDF"? :) An overview on this space would be amazing!
Manifold is a relatively recent library for dealing with "manifold triangle meshes": which can represent a fully solid object(handy for CAD and 3D printing) while the data itself is lists of triangles, the lowest-common denominator between Border-REPresentation and Function-REPresentation.
You can read some "why is this useful" background and basic concepts from the manifold author: Solid Geometry Representations, and Smoothing Triangle Meshes.
The history of the library is also a good read. Disclaimer: I've known the author even before he started working on this, and keep idle interest in the library even if I don't really work in this field anymore.
SDF are signed distance fields, I think. That's where you have a shape defined as a function "f(P)=distance from the point P to the nearest point one the surface of the shape". f() is positive for points outside the shape, negative for points inside the shape and zero for points exactly on the boundary. They are used often when people render fractals in 3D. Valve used them for rendering painted signs in Team Fortress 2 with sharp edges on all the text. https://cdn.akamai.steamstatic.com/apps/valve/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf is about the text rendering.
Another abstraction on Manifold. Another non-BREP code CAD language. While more languages is great, I really wish resources would be spent on existing efforts... Recently Python has been included into OpenSCAD (after a lot of fighting, but still, it had to be proven).
I'm not convinced by the "our language is better". OpenSCAD has been used by some pretty insane projects. Yes, it can be hard to wrap your head at first, but it's not terrible.
The thing is, OpenSCAD, as a language, is awful. It's not just hard. I'm not sure there's anything to salvage from it. Operations being prefix is certainly one of the worst aspects. This is a very basic example from SolidPython's documentation:
difference(){
union(){
cube(5);
translate( [5, 0,0]){
sphere(5);
}
}
cylinder(r=2, h=6);
}
When reading, you constantly need to find the leaves to get an idea of what's modelled and work upwards and downwards again. Variables improve the situation but then you end up with too many variables which is still not pleasant.
I guess the python into openscad stuff is probably https://www.guenther-sohler.net/openscad/tutorial/site/ , right? It looks like a big improvement and is probably a smarter move than coming up with a new language. If I get back to modelling, I'll certainly give it a shot.
Speaking as someone who has done only a little OpenSCAD, I've become aware of the rendering kernel limitations and I agree with you that, in an ideal world, that would be the priority focus area for pushing the state of the art forward. But it's a tough problem (isn't Jessie Frazelle working on this with some big-$$$ start up?)
That said it's not a zero-sum game: I have a lot of experience in an adjacent domain (procedural generation of 2D maps for DOOM) and coming from a functional, LISP/LOGO-like environment there is a lot of room for improvement in the language space. Someone with the skills to push the language side forward may not be able to contribute to the rendering kernel side. I doubt I could. So if some folks are able to improve the language space I think that's still a worthwhile contribution.
Edit to add: link to '21 article in ACM Queue re new kernels https://blog.jessfraz.com/pdf/a-new-era-for-mechanical-cad.pdf
A re-creation of their blocks demo in my Geoscript language: https://3d.ameo.design/geotoy/edit/68
Looks like you're missing the hollows and internal pegs that allow Lego bricks to stick together.
You're right - I forgot that. I updated it to include them.
EDIT: Actually I didn't realize that they made their blocks mostly hollow in that demo. I'll try to do that as well.
You might want to take a closer look at the bottom of a Lego brick or the source code for the µcad demo; your example is still not producing a similar part.
You're right again. I was over-eager to post, and it's been a very long time since I actually held or looked at a lego.
I've added in the tubes on the bottom which should mostly match what the Microcad demo is doing.
And to add a bit of substance to my original post so it's more than just a link to a clone, I construct the blocks using primarily CSG rather than the extrude-based workflow that Microcad uses. Geoscript also supports extrusion and similar operations, but I personally find that I find it easier to reason about geometric operations in terms of CSG for most cases.
That being said, Microcad seems to have a focus on CAD (not surprising given the name). It has native units like millimeters at the language level, and as far as I understand extrusion and working on things with a focus on machining, 3D printing, or some other kind of physical output.
Geoscript and its enclosing project Geotoy focus more on 3D rendering and smooth integration into triangle mesh rendering pipelines. It has more built in wrt. the material system and procedural elements for creative coding, games, and stuff like that.
That being said, as another user mentioned in a different comment, both Geotoy and Microcad make use of the same underlying Manifold kernel. Manifold is stunningly powerful and operates directly on meshes as well, so they probably have a similar internal setup at some level.
And yes I will say that just wrapping Manifold with a custom syntax isn't all that difficult when making use of modern tools for language development. Actually, it looks like both Microcad and Geotoy make use of the Pest parser, which isn't that much of a surprise given the fact that they're both written in Rust and the power Pest provides vs. the effort required to set it up.
From my experience, the difficulty comes in integration points with import/export, dealing with bad inputs and tool incompatibilities, maintaining good docs and tutorials, stuff like that. But that's the case for almost all software development anyway.
I'm not a CAD expert but I have some experience with GUI 3D CAD applications like OnShape and languages like OpenSCAD.
I'm wondering why this had to be a language instead of a library? In their lego brick example, the LegoBrick part could be a class/struct with a constructor for creating parts with given dimensions and a method to return the model. Would something like this not work?
Apologies in advance if I misunderstood what this is about..
As I was looking slowly at CAD in general, I am not sure what tools like this or OpenScad bring to the table vs GUI 2D/3D CAD software? Is there a type of design (I guess procedural based) that would favor a programming language based approach vs GUI?
Yep. Any models where you want adjustable parameters, and auto-readjusting, and being able to reason about how it's put together, code CAD is quite good.
For one-offs, GUI is preferable.
Many code CAD technologies are weaker than their GUI counterparts, missing many functional conveniences.