Show HN: SolidCraft – Open-Source Parametric CAD in Rust (With MCP Support)

> 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.

    Thread MainThread {
        Surface: face(Bolt.Shank)
        MajorDiameter: 8mm
        Pitch: 1.25mm
        Length: 47.5mm
        StartOffset: 1.5mm
        }

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).

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.

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.

Oh my God you are right.

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.

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

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 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.

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.

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.