I've been tapering off maintenance since 2016 or so, but it has a more actively-maintained fork over at https://github.com/nsfm/stibium (albeit with heavy LLM assistance, because it's 2026!)
YMMV – I haven't used it or closely inspected the changes, but have corresponded with the author, who seems genuinely dedicated in the success of the project.
Lots of stuff – my favorite part about implicit surfaces is that they're a microcosm of CS as a whole, so there's a huge number of directions to explore.
libfive [1] was the follow-up kernel, written in C++, with a big emphasis on fast evaluation and robust meshing. It's also in maintenance mode, but was shipped in a handful of commercial CAD tools.
In 2020, I wrote a SIGGRAPH paper [2] about doing implicit surface rendering on the GPU. This was a fun and exciting experience! This used libfive for the frontend, then did all of the compute-heavy rendering work on the GPU.
I then got tired of dealing with C++ and rewrote everything in Rust, which is what I've been using ever since: Fidget [3] is the new kernel and Halfspace [4] is the new IDE. This is what I'm actively working on – the Halfspace blog post just went up a few weeks ago, and I've been implementing / improving a GPU rendering backend in Fidget (with a backlog of several more blog posts).
In between, I nerd-sniped a bunch of people into writing their own f-rep evaluation engines [5] and gave a talk about the whole "independent research" thing [6].
Raymarching is great, and I love the work being done by the demoscene / Inigo Quilez / etc! I don't talk about it as much because my libraries usually have slightly different goals.
Most common raymarching strategies put limitations on your function, e.g. you need Lipschitz continuity to guarantee that you don't hit the model when doing ray steps. This property are pretty easy to break by accident (e.g. just scaling the model requires a correction factor), so you have to be careful with how you bend and twist the underlying math expression. If you're doing a single demo (or have a known library of good shapes), you can get away with it, but there's less flexibility.
The goal of my infrastructure is to support basically any math expression, no matter how poorly-behaved (although I really would appreciate C0 continuity), so I like the guarantees [1] of interval arithmetic.
That being said, the boundary is fuzzy. On one side, you can do raytracing with interval math [2], instead of point samples. From the other side, my more recent GPU rendering uses Z-sorting of spatial regions, so still using 3D intervals but walking them from the camera backwards (no blog post yet, sorry).
[1] Fidget doesn't actually change FPU rounding modes, so it's not absolutely guaranteed, but ehhhhhhh
Oh my gosh I'm terrible with names so I didn't catch that that Siggraph paper and Antimony were from the same person! Both are so neat. You do great work!
Thanks for replying; big fan of your work. I thought that Halfspace and Fidget were a different project. You're saying its a direct continuation of libfive & the SIGGRAPH paper? How stable or production ready is the rust reimplementation?
They are all part of the same broad "research program" and implement similar algorithms, but don't share any code with libfive (that would be hard, given the language change!).
The Rust code is being used by a few people other than me, but is not especially stable – one of the goals is to find the "right APIs", so I'm not shy about breaking things as I find better abstractions. Meshing is also not quite as polished as libfive, because I haven't yet found an algorithm that meets all my requirements, and have spent less time papering over issues in the chosen algorithm (manifold dual contouring).
I first found your work exactly at those years and it blew my mind as I had no idea how these things worked, only to forget and rediscover it yesterday. It was a lovely find back then and changed my mind so much, thanks for it!
I love OpenSCAD and code-based CAD, but even I must admit it's really only good for simple things and is more of a toy than a tool to solve real world problems. The main issue is fundamental, which is that CSG operations change topology in unpredictable ways, and there is no reliable way to refer to the components of the result. This is already bad for a few operations, but becomes exponentially problematic for more complicated models. Even in 2D, suppose I want to make a C-shaped thing out of a box and subtracting a different box out of it. You don't know how many edges the result will have, or even how many connected components the result will have, so how do you go on to perform the next step "on that one part that I want" if it even exists? Of course for a single concrete instantiation this is not really a problem, but the whole point is to have the shape tunable based on parameters, and once you allow that all hell breaks loose.
Yeah, I oscillate a ton between code-based CAD (OpenSCAD, Build123d) and Fusion 360 and they require very different ways of thinking about things, with different things being easier/harder with each approach.
I hesitate a bit to call code-based CAD "a toy", but there are a lot of times where what I think I actually want is some kind of, sorry for the phrasing here, fusion of Fusion 360 and OpenSCAD. The Fusion timeline is pretty phenomenal and having the ability to do something like code steps and manual "click on all of the edges you want to put a fillet on" steps interwoven seems like it has a lot of potential for my "ultimate CAD workflow". The timeline part is kind of the magic that unlocks the whole thing:
- update a parameter or a piece of code, triggering a recompute
- see that the fillet operation is now missing an edge
- rewind the timeline, tweak the fillet edge set
- fast-forward the timeline to let the rest of the code blocks re-execute
Things like MakerWorld let you upload parametric OpenSCAD files and that's cool and all, but for my own uses I don't care if I need to use the "insert a manual step in the timeline" feature occasionally. OpenSCAD on its own doesn't have that and the idea of trying to do "operations as code" in Fusion (there is a scripting interface) is not super appealing as-is.
Being able to use hand-created objects as function inputs seems pretty powerful too. As an example, instead of needing to manually specify all of the points to make a polygon that I'm going to do a bunch of OpenSCAD extrudes with, just referencing a sketch earlier in the timeline. My current OpenSCAD "hack" for that is to draw those in FreeCAD as DXFs and then import them, but it's not a smooth workflow at all.
I could have written this same comment! For the most part I stick with Fusion, although my experience with build123d has also been great.
At the risk of spamming this thread, check out FluidCad. It has excellent GUI based cad tools, and those same tools generate the equivalent 'code cad' for each operation. Of course you can also use 'code first' instead.
I think it's really exciting, and while it's early in development it is already very usable.
The great thing about OpenSCAD is that it makes it easy to model objects which may be represented by positioning/stretching/adding/subtracting cubes, spheres, cylinders, and cones using mathematics.
The awful thing about OpenSCAD is what one can model in it is directly limited to ones fluency and facility with using math to position, stretch, add, and subtract cubes, spheres, cylineders, and cones.
There is an entire book series on using it didactically:
Software like OpenSCAD are mesh models, for engineering purposes they are pretty much useless for design maintenance and accuracy. I'd take them more seriously if they could output STEP files.
I come from the side of being an experienced user in multiple traditional Parametric CAD systems, the code paradigm just makes no sense for how I design parts/systems and I think most CAD users will have similar feelings.
do you know of a traditional CAD program which could be used to drive such designs/projects in a useful fashion? I'm currently contemplating a re-write to use a Domain Specific Language....
Would you be interested in evaluating (or having your LLMs check out) my geometry kernel Aetheris for your project? I already have DSL (called Firmament) parser/lexer/AST part down, and it is designed to be easy to extend, so you don't have to write everything from scratch.
One of my goals when I built the kernel is I want to make building a pro grade CAD software as easy as wrapping a web frontend around the Aetheris libraries. It's still very much an aspirational goal though.
Use Forge.Host for integration and call boundaries with Python. The Firmament DSL is probably a lot lower level than what most Code CAD is used to, because it's closer to LLVM IR of "build your own language frontend over kernel operation" type of deal.
It's not really useless though. Yes, in some dimensions it is terrible compared to GUI parametric CAD. But in other dimensions it is far more powerful and lets you build really complex stuff quickly and easily.
OpenSCAD is useless for almost all of the things that people actually use CAD for. There are a few minor exceptions like fasteners, gears and procedural art. Most CAD is more like a motorbike or a vacuum cleaner. Good luck with that.
To anyone else who had to parse early KiCad file formats, where the parentheses and quoting on S-expressions was more of a guideline than a rule, I salute you.
I thought early KiCad was non or only partially S-expressions, but new KiCad is all S-expressions? Anyway haven't had parsing issues in years and exports to MCAD work very well.
How much is Balkanization going to matter with these programs? Is everyone going to split into using dozens of different design tools?
I don't want to create files using some application that's just vibe-coded and won't be supported for very long. I'm sure that's not the case for some of these, but the prospect of finding the best software and verifying that it's here to stay seems like more work than just sticking with Fusion and OnShape.
Maybe I'm wrong about this, but I see multiple posts about some new drafting or design tool every day, and the cost of integrating them into any existing workflow seems high.
There is already a common exchange format between all the 3D parametric CAD had converged to: STEP files, and Parasolid x_t files to a lesser extent due to it being the dominant kernel on the market.
So, integration isn't really the difficult part if everybody generates files in the same format.
Step files are just "dumb" solids and are not useful if you actually want to edit a model's features or relationships. Almost all CAD software keeps the actual editable model info in proprietary file types. Some CAD programs can generate a part file from a step file with varying degrees of success, the professional CAD packages (CREO, CATIA) being the best at it, but even then they often fail to produce a complete part for anything that is remotely complex. Step files are mostly used to export a final product to production (CNC, 3D printing, etc), or sometimes used incorporate common hardware into a larger assembly, like a simple bracket or something.
>Step files are just "dumb" solids and are not useful if you actually want to edit a model's features or relationships.
Until now.
I've spent the last 7 months working on my Aetheris geometry kernel because I wanted to have a CAD software that uses STEP, specifically, AP242, as its native format instead of just an exchange format. Very happy to say that I've succeeded, as you can add dimensions and GD&T to STEP 203/214 files and convert them to 242 directly.
Directly editing an existing STEP file is still limited to moving through holes around though, but there is no reason why more advanced editing couldn't be done.
How would one apply a fillet to an edge, in this model?
I haven't really used the constructive geometry approaches to CAD, but I've been learning CAD recently through OnShape, and really appreciated how easy were all the operations I wanted to do with it. I've heard that the purely constructive geometry approaches of the OpenSCAD type can make certain operations more complicated to implement.
Sadly CAD is similar to the GIMP and Photoshop situation, depending on the software you use you might want to aim lower in your goals. Though it's not all doom and gloom because things have been improving and keep improving at a steady shape i.e. see FreeCAD's latest updates.
I've been using AI to create CAD models. Results often are close to my intent, but I also have to spend much effort on tweaking parameters and features to fit parts in the real word. AI does help, but doesn't solve CAD modeling problems, unlike GenAI image/video for entertainment.
I'm not great with 3D modeling since I do it less than once a year. I wanted to model something, so I described it with Astra and it got it quite close to what I wanted. But it took like 40 minutes of total processing time to generate something quite simple. If I were good with Fusion I would have been done much sooner than the time Astra took.
CAD generally has a steep learning curve, but once you're adept at it it can be easy to create surprisingly complex parts in very little time. Professional CAD packages can make this even faster with more complicated built-in tools. But time spent designing in CAD is usually focusing on figuring out some particular dimension...or dealing with the thousand obscure bugs, crashes, and constraint failures that seem to plague all CAD software.
>Antimony is a computer-aided design (CAD) tool from a parallel universe in which CAD software evolved from Lisp machines rather than drafting tables
That's an ironic take in that the most prolific CAD software in use, AutoCAD, has supported a a lisp dialect, named AutoLISP[0], natively as an alternative runtime for more than four decades. It is so prolific in the CAD industry, that other vendors have even adopted compatibility with the language.
It is heartening to see CAD referenced in relation to drafting tables. I spend much of my time trying to educate new CAD users about the different solutions offered between the 'drafting table' metaphor and the 'world model' metaphor present in most CAD applications.
Ivan Sutherland's Sketchpad (1963) [1] greatly antedates Lisp Machines (but not Lisp!) and is still the best model imnsho for CAD.
[1] https://en.wikipedia.org/wiki/Sketchpad
The first Lisp machines at MIT were mid 1970s, and by that time Evans & Sutherland had been founded and were on their second or third generation CAD products.
I'm less sure about this chronology but I think the Evans & Sutherland CAD systems were some of the first examples of multiple graphics coordinate systems that were the progenitor of overlapping windows and the desktop metaphor.
my father was a draftsman and so I grew up with blueprints and a drafting table in the home. He was also a user of the earliest CAD systems, including AutoCAD (by a vendor named Autodesk). It had a Lisp-like language built-in named AutoLISP. It was the first Lisp running in my home that I can remember or at least the first I interacted with. CAD systems were clearly meant as a software tool for the kind of workflow previously done by hand, by draftsman, involving printed blueprints. And a Lisp was exposed for user interaction about as early as you can get.
So I am not clear if the OP is just ignorant of CAD's history, or they are making an intentionally baiting and misleading claim.
61 comments
[ 2.7 ms ] story [ 18.9 ms ] threadI've been tapering off maintenance since 2016 or so, but it has a more actively-maintained fork over at https://github.com/nsfm/stibium (albeit with heavy LLM assistance, because it's 2026!)
YMMV – I haven't used it or closely inspected the changes, but have corresponded with the author, who seems genuinely dedicated in the success of the project.
libfive [1] was the follow-up kernel, written in C++, with a big emphasis on fast evaluation and robust meshing. It's also in maintenance mode, but was shipped in a handful of commercial CAD tools.
In 2020, I wrote a SIGGRAPH paper [2] about doing implicit surface rendering on the GPU. This was a fun and exciting experience! This used libfive for the frontend, then did all of the compute-heavy rendering work on the GPU.
I then got tired of dealing with C++ and rewrote everything in Rust, which is what I've been using ever since: Fidget [3] is the new kernel and Halfspace [4] is the new IDE. This is what I'm actively working on – the Halfspace blog post just went up a few weeks ago, and I've been implementing / improving a GPU rendering backend in Fidget (with a backlog of several more blog posts).
In between, I nerd-sniped a bunch of people into writing their own f-rep evaluation engines [5] and gave a talk about the whole "independent research" thing [6].
[1] https://libfive.com
[2] https://www.mattkeeter.com/projects/siggraph/
[3] https://www.mattkeeter.com/projects/fidget/
[4] https://www.mattkeeter.com/projects/halfspace/
[5] https://www.mattkeeter.com/projects/prospero/
[6] https://www.youtube.com/watch?v=UxGxsGnbyJ4
I'm certainly not an expert in these fields, but what's your angle on techniques like raymarching?
Raymarching is great, and I love the work being done by the demoscene / Inigo Quilez / etc! I don't talk about it as much because my libraries usually have slightly different goals.
Most common raymarching strategies put limitations on your function, e.g. you need Lipschitz continuity to guarantee that you don't hit the model when doing ray steps. This property are pretty easy to break by accident (e.g. just scaling the model requires a correction factor), so you have to be careful with how you bend and twist the underlying math expression. If you're doing a single demo (or have a known library of good shapes), you can get away with it, but there's less flexibility.
The goal of my infrastructure is to support basically any math expression, no matter how poorly-behaved (although I really would appreciate C0 continuity), so I like the guarantees [1] of interval arithmetic.
That being said, the boundary is fuzzy. On one side, you can do raytracing with interval math [2], instead of point samples. From the other side, my more recent GPU rendering uses Z-sorting of spatial regions, so still using 3D intervals but walking them from the camera backwards (no blog post yet, sorry).
[1] Fidget doesn't actually change FPU rounding modes, so it's not absolutely guaranteed, but ehhhhhhh
[2] https://arxiv.org/abs/2202.02444
The Rust code is being used by a few people other than me, but is not especially stable – one of the goals is to find the "right APIs", so I'm not shy about breaking things as I find better abstractions. Meshing is also not quite as polished as libfive, because I haven't yet found an algorithm that meets all my requirements, and have spent less time papering over issues in the chosen algorithm (manifold dual contouring).
If you could add support for SolveSpace's 2D sketcher, and also bevels/fillets, then this might actually be useful.
I hesitate a bit to call code-based CAD "a toy", but there are a lot of times where what I think I actually want is some kind of, sorry for the phrasing here, fusion of Fusion 360 and OpenSCAD. The Fusion timeline is pretty phenomenal and having the ability to do something like code steps and manual "click on all of the edges you want to put a fillet on" steps interwoven seems like it has a lot of potential for my "ultimate CAD workflow". The timeline part is kind of the magic that unlocks the whole thing:
- update a parameter or a piece of code, triggering a recompute - see that the fillet operation is now missing an edge - rewind the timeline, tweak the fillet edge set - fast-forward the timeline to let the rest of the code blocks re-execute
Things like MakerWorld let you upload parametric OpenSCAD files and that's cool and all, but for my own uses I don't care if I need to use the "insert a manual step in the timeline" feature occasionally. OpenSCAD on its own doesn't have that and the idea of trying to do "operations as code" in Fusion (there is a scripting interface) is not super appealing as-is.
Being able to use hand-created objects as function inputs seems pretty powerful too. As an example, instead of needing to manually specify all of the points to make a polygon that I'm going to do a bunch of OpenSCAD extrudes with, just referencing a sketch earlier in the timeline. My current OpenSCAD "hack" for that is to draw those in FreeCAD as DXFs and then import them, but it's not a smooth workflow at all.
At the risk of spamming this thread, check out FluidCad. It has excellent GUI based cad tools, and those same tools generate the equivalent 'code cad' for each operation. Of course you can also use 'code first' instead.
I think it's really exciting, and while it's early in development it is already very usable.
The awful thing about OpenSCAD is what one can model in it is directly limited to ones fluency and facility with using math to position, stretch, add, and subtract cubes, spheres, cylineders, and cones.
There is an entire book series on using it didactically:
- Geometry: https://www.goodreads.com/book/show/58059196-make
- Trigonometry: https://www.goodreads.com/book/show/123127774-make
- Calculus: https://www.goodreads.com/book/show/61739368-make
and there is a new book on Physics: https://www.makershed.com/products/make-physics
I come from the side of being an experienced user in multiple traditional Parametric CAD systems, the code paradigm just makes no sense for how I design parts/systems and I think most CAD users will have similar feelings.
https://studio.flet.dev/run/bicQWc3Aul
do you know of a traditional CAD program which could be used to drive such designs/projects in a useful fashion? I'm currently contemplating a re-write to use a Domain Specific Language....
https://github.com/yuechen-li-dev/Aetheris
One of my goals when I built the kernel is I want to make building a pro grade CAD software as easy as wrapping a web frontend around the Aetheris libraries. It's still very much an aspirational goal though.
I will note the following projects which have made recent advancements:
- OpenSCAD --- the hopefully final Release Candidate for the long-awaited update is now available: https://openscad.org/downloads.html#rc
- PythonSCAD --- for folks who want variables which change and so forth: https://www.pythonscad.org/
- CADquery --- https://cadquery.github.io/
- Build123D --- https://github.com/gumyr/build123d
Longer list/discussion at: https://github.com/Irev-Dev/curated-code-cad
Also, a more recent project by Matt Keeter, Halfspace was announced recently but didn't get much discussion here:
https://news.ycombinator.com/item?id=49881890
https://github.com/cadmpeg/cadmpeg
I don't want to create files using some application that's just vibe-coded and won't be supported for very long. I'm sure that's not the case for some of these, but the prospect of finding the best software and verifying that it's here to stay seems like more work than just sticking with Fusion and OnShape.
Maybe I'm wrong about this, but I see multiple posts about some new drafting or design tool every day, and the cost of integrating them into any existing workflow seems high.
So, integration isn't really the difficult part if everybody generates files in the same format.
Until now.
I've spent the last 7 months working on my Aetheris geometry kernel because I wanted to have a CAD software that uses STEP, specifically, AP242, as its native format instead of just an exchange format. Very happy to say that I've succeeded, as you can add dimensions and GD&T to STEP 203/214 files and convert them to 242 directly.
Directly editing an existing STEP file is still limited to moving through holes around though, but there is no reason why more advanced editing couldn't be done.
I haven't really used the constructive geometry approaches to CAD, but I've been learning CAD recently through OnShape, and really appreciated how easy were all the operations I wanted to do with it. I've heard that the purely constructive geometry approaches of the OpenSCAD type can make certain operations more complicated to implement.
Sadly CAD is similar to the GIMP and Photoshop situation, depending on the software you use you might want to aim lower in your goals. Though it's not all doom and gloom because things have been improving and keep improving at a steady shape i.e. see FreeCAD's latest updates.
That's an ironic take in that the most prolific CAD software in use, AutoCAD, has supported a a lisp dialect, named AutoLISP[0], natively as an alternative runtime for more than four decades. It is so prolific in the CAD industry, that other vendors have even adopted compatibility with the language.
It is heartening to see CAD referenced in relation to drafting tables. I spend much of my time trying to educate new CAD users about the different solutions offered between the 'drafting table' metaphor and the 'world model' metaphor present in most CAD applications.
[0]https://en.wikipedia.org/wiki/AutoLISP
Discussion of FreeCAD adding it here: https://forum.freecad.org/viewtopic.php?t=49989
I'm less sure about this chronology but I think the Evans & Sutherland CAD systems were some of the first examples of multiple graphics coordinate systems that were the progenitor of overlapping windows and the desktop metaphor.
https://www.shapr3d.com/content-library/history-of-cad
I make RapidCAM.app so have an appreciation for the amount of work Antimony must have been to get to that point.
So I am not clear if the OP is just ignorant of CAD's history, or they are making an intentionally baiting and misleading claim.