Interestingly, ttouch created browser-based CAD tool CADmium a few years ago based on Truck. Then, a few months ago, they created another one (CADara) based on OpenCASCADE: https://news.ycombinator.com/item?id=48070083.
Truck seems cool, but creating a b-rep kernel is a phenomenal amount of work. Given that, I'm curious how quickly SolidCraft will mature.
> Creating a b-rep kernel is a phenomenal amount of work
Well, I did it, took 6 months, and I think I'm ahead of Truck on that front since as far as I can tell Truck can still only do single edge fillets with Newton's method as their new fillet algorithm, whereas my kernel can do planar fillet chains fairly reliably.
I wish someone would wrap a frontend around it too considering I'm bad at designing UIs, and the architecture is too weird to put a conventional 3D CAD UI on it that I'm honestly hoping someone would throw their LLM at that task.
Also, sorry about the excessive self-promotion, but I think most people would be shouting from the mountaintop if they built a BREP geometry kernel from scratch solo too.
“ Dangerous operations which may generate degenerate/sliver/zero-dimension geometries are instead blocked from materializing to 3D at a compiler level.”
How is that achieved, or rather what does that mean? What defines a sliver?
A sliver is basically a tiny degenerate geometry in the micro/nanometer scale that's basically the result of ambiguous surface intersections. Basically, if you put two say, cylindrical surfaces against each other in NURBS form, floating point noise would generate these microscopic geometric noises, and a lot of what commercial kernel does is they use what they call "healing" operations to clean up those bad microscopic geometries from the models they generate.
Aetheris took a very obvious approach that not many have seemed to tried before: It throws an error when an operation that may create ambiguous intersections and refuses to materialize bad geometry in the first place, which is not really possible to do with traditional NURBS based kernels, whereas Aetheris can because it is analytical first.
You see slivers in 2D spatial operations as well. Imagine that you have two parcels represented as polygons that don’t perfectly spatially intersect. If you perform a boolean operation to, say, compute the union of these two polygons into a single one, any microscopic difference between the two boundaries below a certain tolerance (like 0.001 square meters) will manifest itself as tiny gaps and slivers. Most GIS engines will merge the two polygons appropriately beyond that tolerance (this is a way simpler problem in 2D space!) but if the data is bad enough you’ll definitely see it.
While this is technically correct behavior, users will interpret that as your software not being able to do something - or as a bug (because it works on one drawing but not another).
Well, this is more similar to a linter/borrow checker than anything else, because if you catch errors at compile time, the bad geometry doesn't persist in the STEP artifact that's being generated, so analogous to the philosophy of Rust vs C++ really.
The current design is meant to be import tolerant but export strict, it imported most STEP file I throw at it fine after a bunch of fixes, but I don't really have a big enough sample corpus know for sure how much real world STEP file it can handle.
Aetheris generates STEP AP242 BREP directly, the tessellated mesh generated is only used for display (although currently, I've switched to a WebGPU based SDF representation so the surfaces can be smooth). One of the key differences in the architecture Aetheris doesn't export rational b-splines outside of debug or STEP passthrough and instead tries to recover and export analytical and non-rational splines instead.
On screw thread, if you mean by "how do you make a screw thread in Aetheris", you can check out the actual code for a threaded bolt I built for a showcase here with the JSON like DSL called Firmament:
Which is why I said that it's really hard to think of an editor UI for Aetheris that's not just a text editor or a ComfyUI like graph visual programming or something.
If you mean compile speed wise, not great right now, it wasn't that much of an issue when running on RyuJIT natively since it's still acceptable, but currently WASM cold compile speed for a moderately sized assembly is around 4-5 minutes so there is a lot more work to be done before I'm ready to put it on a cloud server.
I'm not trying to tear this down but if your geometry kernel can't be compiled into a .dll or .so file and then included inside the CAD program I'm not sure people will be interested in running your software.
I'm not critiquing the language choice, it's just that I basically have a thing that is big on dynamic linking and I would rather farm out the geometry kernel to someone else and at this rate I'm kind of forced to port yours over so it works for me and I think that would be a bad outcome for both of us.
Also your .firmament files are good because I'm working on something like that too.
Yes? It's a back and forth discussion, where the model's output (that is much more pluridisciplinary than Terrance will ever be and therefore benefits from the common knowledge of not just an entire field, but thousands of fields over thousands of cultures) actively drives his responses and verifications. Literally, the entire set of messages is "you said X. Does that therefore entail Y in what you said ?". Terrance being an expert knows how to drive the conversation in angles which he explored, but it remains that the bulk of the work is done by Claude.
If I keep asking clarifying questions to Albert Einstein, that doesn't make me the inventor of relativistic physics, no matter how much I know about the subject.
I'm not contradicting OP's expertise on the subject: they seem to at the very least know what they're talking about. But saying "I" did this when all you did is prompt the funny slot machine and approximately none of the code is reviewed (6 commits per day, each being 50+ files on average is not something you have reviewed or understood.) is lying to others and to yourself.
I couldn't build this even with Claude Mythos, I have no freaking clue what this stuff is, and I'm a full time software developer that understands performance optimization and even has used SketchUp a lot.
I'm telling you, I simply couldn't do it. Unless the prompt is "copy every single feature in AutoDesk Fusion 360" and sit back, and even then, I wouldn't even know where to start with testing it, knowing whether it works properly, and whether the various tools are useful, performant, etc.
Let's not assume that the code is the most important part, it's important, but domain knowledge is still very important.
Yes for some reason people are really bad at being honest. For that reason all my AGENT.MD files instruct the AI to write a disclaimer at the end what kind of involvement I had and how much the AI did.
Most of the documents have something like this at the bottom:
"Primarily written by AI based on human design discussions."
And I don't feel ashamed to let the AI do the writing because the output is reasonably good because I let it generate a TOC then I rework the TOC by hand, then for each TOC chapter I just have a discussion giving it the information and then I let it generate the text. I didn't even directly tell it what to write about. Instead there is a loose discussion that contains all the needed information to convey.
So it is really silly to then slap your own name on the final end product and claim you did all of it, even if it took weeks of prompting to finish the document.
If the experiment does work out and the library NVIDIA open-sourced proves to be mathematically robust enough for standalone CAD use, it would leapfrog OpenCASCADE kernel for open-source CAD (solved math that was previously propriety, graceful failures without crashes, multiple CPU threads, running smoothly on web browsers).
Are you running with this port because of the slowness that Truck has had in merging new code from outside contributors? It seems like that was the reason for the MonsterTruck fork of Truck, which also has some promising features that aren't present in Truck.
Personally, I've been planning out work to create a build123d-like python scripting environment which wraps the Truck kernel, in the hopes that one day Truck will be mature enough (so many problems with fillets!) to surpass OpenCASCADE.
As much as I hate Design By Committee, a CAD kernel is a massive undertaking and it would be nice to not have 20 different projects all working on cool features that are not compatible with others because every project took its own path. It might be worth finding others actively working in this space and see if there could be a shared vision that we could all work towards together. Things like fillets, solutions to the topological naming problem, etc., are gonna take a lot of smart minds working together to really solve.
I'd gladly shell out a bunch of tokens to help create that vision, but I'd have to say I'm not exactly the person to architect that vision myself.
So far it is a straight port of the recently open-sourced smlib, it covers A LOT of what we need. Feel free to point an agent at it, there's like a "take a ticket" triage-like system for who's working on what functions
FWIW I don't think it makes sense to copy anyone's CAD program, and I am negatively disposed to the ArtCraft thing as a general position. I think it's fully the wrong approach.
But I am here for LLMs, if they really can be used to solve maths, to solve CAD maths, which is, as you say, the really difficult stuff.
I am still not going to use an early-stage CAD package, but this actually would be a meaningful contribution to society. The rest is a bit AI NIH.
People don’t get the super high value proposition in having these all *Craft packages controlled (automated) by AI. Most of the companies who are the kingmakers in the given area, do not allow it easily or are hard to integrate (costly) with, or did allow back in time and don’t now.
Given much can be automated in 2026, these (promoted goodies) may come as the missing link in innumerable automation chains, and particularly where commercial agents aim for when they sell costly licensing.
It also indirectly fights piracy and the risks which come with pirated copies (sidelined with funny stuff).
this stuff is a game changer for implementing workflows with some user-facing interaction. I was working on a desktop publishing webapp with a specific slant, the previous iteration of the graphical editor UI was not very good, in order to build anything you have to specifically instruct the agent how every little interaction works, and my recollection and description was often different from how the "standard" desktop publishing flow works (i.e.: this is the sequence of actions to expand a selected entity preserving the aspect ratio, here's how to preserve the center-point, here's how to multi-select, etc). I told the agent "take the frontend from vectorcraft, adopt this specific subset of tools, build it for wasm, and plug in my agent tools and storage backend" - and within a day of deciding to adopt it, I had a much higher quality editor interface that anyone with desktop publishing experience will immediately know how to use, plugged into my storage format.
This is indeed the most exciting thing. It feels a bit scary how good the frontier models are at creating stuff with these apps (that are like a few days old and very incomplete pre alpha stage yet already somewhat functional). The future is happening and I just spent a day rethinking my whole life.
There's also the side effect that, just like with Libreoffice, they will be integrated into future harnesses for AI by anthropic and openai and others so that their platforms will be able to run these programs locally and spit out the results.
yes, and you can do alike. no need to wait for big boys to integrate this stuff. but the game changer is that few years ago one had to comply with weird Python 2.x running within Blender/Scribus/QGIS/etc. and most of the times only some of the functionalities are properly wired/exposed. the actual promise of these packages would be to be able to fully script the whole thing, and this is something that people behind ArtCraft should look into - expose the Rust magic to some common automation layer.
In all honesty - COM+ is a very smart thing, sadly not everyone understood it, and most new software packages are cloud-native before all else and dont' have it. Using the integrated (internal) scripting layers is not always so easy. But what does even 'easy' mean in 2026 automated coding. It was hard 5 years ago and 9 years ago when I last did such automations, nowadays this all has a very different perspective.
And let me remind you - there are dozens of "background removal" websites, and many of them are profitable. So you can imagine the level of comprehension for technology the general population has (at this moment, perhaps will advance rapidly also).
all the artcraft apps have mcp servers that are just a port on your local machine with an api so theyre very scriptable. Ive been doing a ton with them to test them out, including with deterministic scripts driving them
I don't see this moving very fast. On Solvespace we recently had a bunch of commits by Claude to fix NURBS boolean issues. The analysis was actually very impressive and most of the fixes were accepted after a lot of review by multiple experts on the code. I don't see this project getting far on the hard problems they still have open.
IMHO they should have had AI convert OCCT kernel to rust, or just wrap it and use as-is.
BTW we are on the verge of solvespace 3.3 with those AI fixes. After that I'm adding the named parameters that have been prototypes 12 times already. There are also a couple forks out there with MCP server added, but I want to focus on missing features.
Thanks for your work on Solvespace. I have been using it for years. When I no longer had access to commercial CAD programs I tried all the open source stuff. My conclusions were:
* OpenSCAD -- cool idea, good for a few types of highly procedural parts, but most of the time I'd rather a parametric sketch-based interface over pure code.
* FreeCAD -- the most features of any open source CAD, but poor UI, tendency to crash, and the advanced features like loft kind of fall flat compared to commercial equivalents. You think you'll be able to model a part, but it becomes extremely frustrating if you actually need the advanced tools.
* SolveSpace -- pretty stable and reliable. Fast, compact, great sketching interface, good discoverable UI. You can predict what types of parts you can model with it and what types you can't. Doesn't try to do everything but is good at what it does.
You can tell which one is my favorite! N features done to a good level of polish and with somebody making sure it all "makes sense together" beats 10xN features all 80% done and haphazardly mashed together in different menus/workbenches, for any tools I want to rely on.
I am noodling around with a slopcoded CAD tool of my own these days, just out of curiosity to see how far Opus5.5/GPT6 can get doing it in F# and to experiment with some workflow concepts that match the way I like to design parts. But like you said, progress is slow. For stuff I actually want to get done, SolveSpace remains my go-to, and I greatly admire its coherent design.
I am already doing that, the new kernel will be called martensite, for now it lives here: https://github.com/Oblikovati/RustyCADKernel, I am about 70% of all OCCT apis ported with ported rust tests and using OCCT as oracle.
In about a week of two i expect to finalise the porting, then I will remove all the porting harnessing to decouple from OCCT. that will the basis for new innovation, after the cleanup the new kernel will live on this repo, where i already started to create a roadmap with my vision for improvements: https://github.com/Oblikovati/Martensite/milestones
I think I've seen ports of OCCT to Rust as well as Rust wrappers for OCCT floating around Github once or twice already.
However, OpenCascade being C++ instead of Rust is the least of its problems, the main issue is OCCT's boolean/blend engines aren't really as robust as the commercial kernels, and handling arbitrary 3D boolean edge cases one by one correctly is one of the main difficulties of a geometry kernel.
Very interested in SolveSpace's progress on this really.
>> Very interested in SolveSpace's progress on this really
Its good progress but still too easy to have a failed boolean. Previously you had to know how to work around bugs to cut a fillet off an edge. Now thats pretty easy and robust, but as soon as you do two of them that intersect there may be a problem. Like you said, the list of corner cases never end. I suspect a bit more Claude use might fix that one too.
Thanks for making this! I tried some hobby level modelling and it seems very capable. I've been a heavy user of fusion360 in the past but I've been longing for an open alternative.
I played around with Freecad mcp, and then also with having an agent generate some openscad before.
For the Freecad mcp I didn't like it at all. The agent didn't work in a way that would let me easily modify things. I hadn't given it instructions, but it didn't really create sketches and then extrude them (after checking they're all fully parameterized.)
For openscad the problem was just that while the model could do it, the lack of "visual reasoning" (for want of a better word) really held it back. There was a nice workflow there though by giving it a little "generate_image" of part tool and it could make a nice iterative loop.
Overall for both approaches it was slower than if I'd done it myself (and I'm not particularly good at 3d modelling). Now, that's not that surprising given that I was trying something new, but without being able to edit things generated by the AI myself I wouldn't want to try it again.
Now, maybe this solution can work in the way I'd want to. I may give this a go next time I have something I want to make.
About a year ago I challenged folks to move solvespace from GTK3 to GTK4. People here were highly skeptical as I was. A couple people tried and the PRs I got were terrible. A few months ago someone did it with Claude and we now have a very nice GTK4 branch which I hope to merge soon. AI has come a long way.
I've had a lot of success with FreeCAD, no need for MCP when the LLM can just write Python code to generate the file.
Interestingly enough I was trying to make a simple(ish) workbench project using that and LLM made both the "generate the project" program and "run thru the checks" program, where it encoded stuff I asked it to fix (like making sure the bench feet are sitting under the posts, or that there is no holes in the floor).
Ended up building it and on one side I was impressed that it mostly was fine, on other there were clear issues that wouldn't happen if someone actually experienced with it designed it, it just wasn't designed to be put together easily
Very interesting. Looking at the images I'm not sure if this is based on Autodesk Inventor (plausible since they already imitated AutoCAD), or in Solid Edge (given the name).
Fusion is the main idea behind solidcraft as far as I know. But it is NOT aiming to be a copy of anything featurewise unlike most stuff associated with artcraft (and solidcraft is not an official artcraft app despite the name, at least not yet).
There are two, maybe three levels of support for 3D printing:
- exporting an STL so that a Slicer may be used to prepare the file for 3D printing --- https://github.com/bherbruck/solidcraft notes "Export to STEP...3MF...STL and OBJ
so that basic support is there, but the further levels of:
- slicing a 3D model
- sending a model/managing a 3D printer/farm
do not seem to be --- given that there are quite robust solutions for those, I feel that the Unix philosophy of chaining small tools makes sense here.
yeah slicing is very printer/filament-dependent too... prusa and others have done TONS of research on this and have very good solutions. we can have a button to open you selected component in those programs as a mesh, will NOT implement in solidcraft
Looks like this uses the Truck modeling kernel: https://github.com/ricosjp/truck
Interestingly, ttouch created browser-based CAD tool CADmium a few years ago based on Truck. Then, a few months ago, they created another one (CADara) based on OpenCASCADE: https://news.ycombinator.com/item?id=48070083.
Truck seems cool, but creating a b-rep kernel is a phenomenal amount of work. Given that, I'm curious how quickly SolidCraft will mature.
> Creating a b-rep kernel is a phenomenal amount of work
Well, I did it, took 6 months, and I think I'm ahead of Truck on that front since as far as I can tell Truck can still only do single edge fillets with Newton's method as their new fillet algorithm, whereas my kernel can do planar fillet chains fairly reliably.
I wish someone would wrap a frontend around it too considering I'm bad at designing UIs, and the architecture is too weird to put a conventional 3D CAD UI on it that I'm honestly hoping someone would throw their LLM at that task.
https://github.com/yuechen-li-dev/Aetheris/
Also, sorry about the excessive self-promotion, but I think most people would be shouting from the mountaintop if they built a BREP geometry kernel from scratch solo too.
Fascinating repo, thank you for making it!
I’m curious, what does this part mean?
“ Dangerous operations which may generate degenerate/sliver/zero-dimension geometries are instead blocked from materializing to 3D at a compiler level.”
How is that achieved, or rather what does that mean? What defines a sliver?
A sliver is basically a tiny degenerate geometry in the micro/nanometer scale that's basically the result of ambiguous surface intersections. Basically, if you put two say, cylindrical surfaces against each other in NURBS form, floating point noise would generate these microscopic geometric noises, and a lot of what commercial kernel does is they use what they call "healing" operations to clean up those bad microscopic geometries from the models they generate.
Aetheris took a very obvious approach that not many have seemed to tried before: It throws an error when an operation that may create ambiguous intersections and refuses to materialize bad geometry in the first place, which is not really possible to do with traditional NURBS based kernels, whereas Aetheris can because it is analytical first.
You see slivers in 2D spatial operations as well. Imagine that you have two parcels represented as polygons that don’t perfectly spatially intersect. If you perform a boolean operation to, say, compute the union of these two polygons into a single one, any microscopic difference between the two boundaries below a certain tolerance (like 0.001 square meters) will manifest itself as tiny gaps and slivers. Most GIS engines will merge the two polygons appropriately beyond that tolerance (this is a way simpler problem in 2D space!) but if the data is bad enough you’ll definitely see it.
While this is technically correct behavior, users will interpret that as your software not being able to do something - or as a bug (because it works on one drawing but not another).
Well, this is more similar to a linter/borrow checker than anything else, because if you catch errors at compile time, the bad geometry doesn't persist in the STEP artifact that's being generated, so analogous to the philosophy of Rust vs C++ really.
The current design is meant to be import tolerant but export strict, it imported most STEP file I throw at it fine after a bunch of fixes, but I don't really have a big enough sample corpus know for sure how much real world STEP file it can handle.
Thanks for the explanation, appreciate it!
Sorry for asking for definitions - since Aethris is such a different architecture, I want to make sure we’re using the same language.
When you say “models they generate” do you mean the the nurbs representation, or the tessellated geometry for rendering?
On a related topic how does Aetheris perform when defining a screw thread? Or a nut thread?
Aetheris generates STEP AP242 BREP directly, the tessellated mesh generated is only used for display (although currently, I've switched to a WebGPU based SDF representation so the surfaces can be smooth). One of the key differences in the architecture Aetheris doesn't export rational b-splines outside of debug or STEP passthrough and instead tries to recover and export analytical and non-rational splines instead.
On screw thread, if you mean by "how do you make a screw thread in Aetheris", you can check out the actual code for a threaded bolt I built for a showcase here with the JSON like DSL called Firmament:
https://github.com/yuechen-li-dev/Aetheris/blob/master/fixtu...
So, the high-level surface language of defining a screw thread is basically a struct/record that looks like:
Which is why I said that it's really hard to think of an editor UI for Aetheris that's not just a text editor or a ComfyUI like graph visual programming or something.If you mean compile speed wise, not great right now, it wasn't that much of an issue when running on RyuJIT natively since it's still acceptable, but currently WASM cold compile speed for a moderately sized assembly is around 4-5 minutes so there is a lot more work to be done before I'm ready to put it on a cloud server.
I'm not trying to tear this down but if your geometry kernel can't be compiled into a .dll or .so file and then included inside the CAD program I'm not sure people will be interested in running your software.
I'm not critiquing the language choice, it's just that I basically have a thing that is big on dynamic linking and I would rather farm out the geometry kernel to someone else and at this rate I'm kind of forced to port yours over so it works for me and I think that would be a bad outcome for both of us.
Also your .firmament files are good because I'm working on something like that too.
> if they built a BREP geometry kernel from scratch solo too.
But you didn't, Claude did. Your commits display it.
A lay person doesn't have the skill-set to tell Claude how to do something like this. Experts extract much more value out of a domain than amateurs.
Would you tell Terrance Tao that they didn't produce [this conversation](https://chatgpt.com/share/6a5fdc7a-d6f8-83e8-bbea-8deb42cfed...), the model did?
Yes? It's a back and forth discussion, where the model's output (that is much more pluridisciplinary than Terrance will ever be and therefore benefits from the common knowledge of not just an entire field, but thousands of fields over thousands of cultures) actively drives his responses and verifications. Literally, the entire set of messages is "you said X. Does that therefore entail Y in what you said ?". Terrance being an expert knows how to drive the conversation in angles which he explored, but it remains that the bulk of the work is done by Claude.
If I keep asking clarifying questions to Albert Einstein, that doesn't make me the inventor of relativistic physics, no matter how much I know about the subject.
I'm not contradicting OP's expertise on the subject: they seem to at the very least know what they're talking about. But saying "I" did this when all you did is prompt the funny slot machine and approximately none of the code is reviewed (6 commits per day, each being 50+ files on average is not something you have reviewed or understood.) is lying to others and to yourself.
I couldn't build this even with Claude Mythos, I have no freaking clue what this stuff is, and I'm a full time software developer that understands performance optimization and even has used SketchUp a lot.
I'm telling you, I simply couldn't do it. Unless the prompt is "copy every single feature in AutoDesk Fusion 360" and sit back, and even then, I wouldn't even know where to start with testing it, knowing whether it works properly, and whether the various tools are useful, performant, etc.
Let's not assume that the code is the most important part, it's important, but domain knowledge is still very important.
Yes for some reason people are really bad at being honest. For that reason all my AGENT.MD files instruct the AI to write a disclaimer at the end what kind of involvement I had and how much the AI did.
Most of the documents have something like this at the bottom:
"Primarily written by AI based on human design discussions."
And I don't feel ashamed to let the AI do the writing because the output is reasonably good because I let it generate a TOC then I rework the TOC by hand, then for each TOC chapter I just have a discussion giving it the information and then I let it generate the text. I didn't even directly tell it what to write about. Instead there is a loose discussion that contains all the needed information to convey.
So it is really silly to then slap your own name on the final end product and claim you did all of it, even if it took weeks of prompting to finish the document.
They are working on a Rust port for the SMLib geometric kernel subset that NVIDIA open-sourced yesterday as part of their new USD BRep library:
https://github.com/bherbruck/solidcore
If the experiment does work out and the library NVIDIA open-sourced proves to be mathematically robust enough for standalone CAD use, it would leapfrog OpenCASCADE kernel for open-source CAD (solved math that was previously propriety, graceful failures without crashes, multiple CPU threads, running smoothly on web browsers).
If anyone wants to help out, feel free to point an agent at it. The tests are supposedly deterministic
Are you running with this port because of the slowness that Truck has had in merging new code from outside contributors? It seems like that was the reason for the MonsterTruck fork of Truck, which also has some promising features that aren't present in Truck.
Personally, I've been planning out work to create a build123d-like python scripting environment which wraps the Truck kernel, in the hopes that one day Truck will be mature enough (so many problems with fillets!) to surpass OpenCASCADE.
As much as I hate Design By Committee, a CAD kernel is a massive undertaking and it would be nice to not have 20 different projects all working on cool features that are not compatible with others because every project took its own path. It might be worth finding others actively working in this space and see if there could be a shared vision that we could all work towards together. Things like fillets, solutions to the topological naming problem, etc., are gonna take a lot of smart minds working together to really solve.
I'd gladly shell out a bunch of tokens to help create that vision, but I'd have to say I'm not exactly the person to architect that vision myself.
https://crates.io/crates/monstertruck
So far it is a straight port of the recently open-sourced smlib, it covers A LOT of what we need. Feel free to point an agent at it, there's like a "take a ticket" triage-like system for who's working on what functions
FWIW I don't think it makes sense to copy anyone's CAD program, and I am negatively disposed to the ArtCraft thing as a general position. I think it's fully the wrong approach.
But I am here for LLMs, if they really can be used to solve maths, to solve CAD maths, which is, as you say, the really difficult stuff.
I am still not going to use an early-stage CAD package, but this actually would be a meaningful contribution to society. The rest is a bit AI NIH.
People don’t get the super high value proposition in having these all *Craft packages controlled (automated) by AI. Most of the companies who are the kingmakers in the given area, do not allow it easily or are hard to integrate (costly) with, or did allow back in time and don’t now.
Given much can be automated in 2026, these (promoted goodies) may come as the missing link in innumerable automation chains, and particularly where commercial agents aim for when they sell costly licensing.
It also indirectly fights piracy and the risks which come with pirated copies (sidelined with funny stuff).
this stuff is a game changer for implementing workflows with some user-facing interaction. I was working on a desktop publishing webapp with a specific slant, the previous iteration of the graphical editor UI was not very good, in order to build anything you have to specifically instruct the agent how every little interaction works, and my recollection and description was often different from how the "standard" desktop publishing flow works (i.e.: this is the sequence of actions to expand a selected entity preserving the aspect ratio, here's how to preserve the center-point, here's how to multi-select, etc). I told the agent "take the frontend from vectorcraft, adopt this specific subset of tools, build it for wasm, and plug in my agent tools and storage backend" - and within a day of deciding to adopt it, I had a much higher quality editor interface that anyone with desktop publishing experience will immediately know how to use, plugged into my storage format.
This is indeed the most exciting thing. It feels a bit scary how good the frontier models are at creating stuff with these apps (that are like a few days old and very incomplete pre alpha stage yet already somewhat functional). The future is happening and I just spent a day rethinking my whole life.
There's also the side effect that, just like with Libreoffice, they will be integrated into future harnesses for AI by anthropic and openai and others so that their platforms will be able to run these programs locally and spit out the results.
yes, and you can do alike. no need to wait for big boys to integrate this stuff. but the game changer is that few years ago one had to comply with weird Python 2.x running within Blender/Scribus/QGIS/etc. and most of the times only some of the functionalities are properly wired/exposed. the actual promise of these packages would be to be able to fully script the whole thing, and this is something that people behind ArtCraft should look into - expose the Rust magic to some common automation layer.
In all honesty - COM+ is a very smart thing, sadly not everyone understood it, and most new software packages are cloud-native before all else and dont' have it. Using the integrated (internal) scripting layers is not always so easy. But what does even 'easy' mean in 2026 automated coding. It was hard 5 years ago and 9 years ago when I last did such automations, nowadays this all has a very different perspective.
And let me remind you - there are dozens of "background removal" websites, and many of them are profitable. So you can imagine the level of comprehension for technology the general population has (at this moment, perhaps will advance rapidly also).
all the artcraft apps have mcp servers that are just a port on your local machine with an api so theyre very scriptable. Ive been doing a ton with them to test them out, including with deterministic scripts driving them
Oh my God you are right.
I don't see this moving very fast. On Solvespace we recently had a bunch of commits by Claude to fix NURBS boolean issues. The analysis was actually very impressive and most of the fixes were accepted after a lot of review by multiple experts on the code. I don't see this project getting far on the hard problems they still have open.
IMHO they should have had AI convert OCCT kernel to rust, or just wrap it and use as-is.
BTW we are on the verge of solvespace 3.3 with those AI fixes. After that I'm adding the named parameters that have been prototypes 12 times already. There are also a couple forks out there with MCP server added, but I want to focus on missing features.
Thanks for your work on Solvespace. I have been using it for years. When I no longer had access to commercial CAD programs I tried all the open source stuff. My conclusions were:
* OpenSCAD -- cool idea, good for a few types of highly procedural parts, but most of the time I'd rather a parametric sketch-based interface over pure code.
* FreeCAD -- the most features of any open source CAD, but poor UI, tendency to crash, and the advanced features like loft kind of fall flat compared to commercial equivalents. You think you'll be able to model a part, but it becomes extremely frustrating if you actually need the advanced tools.
* SolveSpace -- pretty stable and reliable. Fast, compact, great sketching interface, good discoverable UI. You can predict what types of parts you can model with it and what types you can't. Doesn't try to do everything but is good at what it does.
You can tell which one is my favorite! N features done to a good level of polish and with somebody making sure it all "makes sense together" beats 10xN features all 80% done and haphazardly mashed together in different menus/workbenches, for any tools I want to rely on.
I am noodling around with a slopcoded CAD tool of my own these days, just out of curiosity to see how far Opus5.5/GPT6 can get doing it in F# and to experiment with some workflow concepts that match the way I like to design parts. But like you said, progress is slow. For stuff I actually want to get done, SolveSpace remains my go-to, and I greatly admire its coherent design.
I am already doing that, the new kernel will be called martensite, for now it lives here: https://github.com/Oblikovati/RustyCADKernel, I am about 70% of all OCCT apis ported with ported rust tests and using OCCT as oracle. In about a week of two i expect to finalise the porting, then I will remove all the porting harnessing to decouple from OCCT. that will the basis for new innovation, after the cleanup the new kernel will live on this repo, where i already started to create a roadmap with my vision for improvements: https://github.com/Oblikovati/Martensite/milestones
I think I've seen ports of OCCT to Rust as well as Rust wrappers for OCCT floating around Github once or twice already.
However, OpenCascade being C++ instead of Rust is the least of its problems, the main issue is OCCT's boolean/blend engines aren't really as robust as the commercial kernels, and handling arbitrary 3D boolean edge cases one by one correctly is one of the main difficulties of a geometry kernel.
Very interested in SolveSpace's progress on this really.
>> Very interested in SolveSpace's progress on this really
Its good progress but still too easy to have a failed boolean. Previously you had to know how to work around bugs to cut a fillet off an edge. Now thats pretty easy and robust, but as soon as you do two of them that intersect there may be a problem. Like you said, the list of corner cases never end. I suspect a bit more Claude use might fix that one too.
Thanks for making this! I tried some hobby level modelling and it seems very capable. I've been a heavy user of fusion360 in the past but I've been longing for an open alternative.
Interesting, I thought this was part of the *Craft family but that one is called CadCraft. I do prefer the take on using Fusion as the UI base.
Interested to try this out.
I played around with Freecad mcp, and then also with having an agent generate some openscad before.
For the Freecad mcp I didn't like it at all. The agent didn't work in a way that would let me easily modify things. I hadn't given it instructions, but it didn't really create sketches and then extrude them (after checking they're all fully parameterized.)
For openscad the problem was just that while the model could do it, the lack of "visual reasoning" (for want of a better word) really held it back. There was a nice workflow there though by giving it a little "generate_image" of part tool and it could make a nice iterative loop.
Overall for both approaches it was slower than if I'd done it myself (and I'm not particularly good at 3d modelling). Now, that's not that surprising given that I was trying something new, but without being able to edit things generated by the AI myself I wouldn't want to try it again.
Now, maybe this solution can work in the way I'd want to. I may give this a go next time I have something I want to make.
About a year ago I challenged folks to move solvespace from GTK3 to GTK4. People here were highly skeptical as I was. A couple people tried and the PRs I got were terrible. A few months ago someone did it with Claude and we now have a very nice GTK4 branch which I hope to merge soon. AI has come a long way.
I've had a lot of success with FreeCAD, no need for MCP when the LLM can just write Python code to generate the file.
Interestingly enough I was trying to make a simple(ish) workbench project using that and LLM made both the "generate the project" program and "run thru the checks" program, where it encoded stuff I asked it to fix (like making sure the bench feet are sitting under the posts, or that there is no holes in the floor).
Ended up building it and on one side I was impressed that it mostly was fine, on other there were clear issues that wouldn't happen if someone actually experienced with it designed it, it just wasn't designed to be put together easily
FreeCad had problems for years with certain functions when changing parameters. Does this avoid those problems from the start?
IIRC, FreeCad has at least partially addressed the remaining problems with that recently.
What concerns me about moving to AI-generated software is that CAD files have extreme longevity. Will the project be active in 5 years?
Looks awesome, for some reason I liked that much more then FreeCAD. Fingers crossed that will actually be supported and survive DMCA
Very interesting. Looking at the images I'm not sure if this is based on Autodesk Inventor (plausible since they already imitated AutoCAD), or in Solid Edge (given the name).
Fusion is the main idea behind solidcraft as far as I know. But it is NOT aiming to be a copy of anything featurewise unlike most stuff associated with artcraft (and solidcraft is not an official artcraft app despite the name, at least not yet).
It looks a lot like Fusion, where Autodesk took all the passable UI and UX from Inventor and replaced it with absolute garbage.
Interesting product and will try this.
Could you please confirm if 3D printing functionality is supported? This feature would be very useful for professionals. Thank you.
There are two, maybe three levels of support for 3D printing:
- exporting an STL so that a Slicer may be used to prepare the file for 3D printing --- https://github.com/bherbruck/solidcraft notes "Export to STEP...3MF...STL and OBJ
so that basic support is there, but the further levels of:
- slicing a 3D model
- sending a model/managing a 3D printer/farm
do not seem to be --- given that there are quite robust solutions for those, I feel that the Unix philosophy of chaining small tools makes sense here.
yeah slicing is very printer/filament-dependent too... prusa and others have done TONS of research on this and have very good solutions. we can have a button to open you selected component in those programs as a mesh, will NOT implement in solidcraft
Got it, a useful feature. Thanks a lot.
Would this post get as much attention as it is getting if it wasn't for the "in Rust" in the title?
I think having these abundance of alternatives is positive, overall. We need a way to find good ones.
Running in the browser is the best part. Can actually use it at work without asking IT.
Ok CAD is great but I want CAM