Been playing with SMLib since it went open source and figured I'd share how I got it doing useful things, beacuse I wasted a whole evening learning the hard way. Big thing to know up front: this is nothing like OpenSCAD. OpenSCAD works by mashing shapes togather and letting the slicer sort out the mess. This kernel wants you to think in surfaces and edges, proper solid modeling where you define a body and then modify it. That mental shift took me longer than the setup did. Setup itself was quick, the repo ships with build files that just worked on my machine, no fiddling required. Where I got stuck was the docs, they're pretty thin. What saved me was the example programs sitting in the repo. Copy one, change one thing, rebuild, repeat. That loop taught me more in an hour than staring at header files ever did. If you're hoping to hook it into OpenSCAD or anything similar, don't try to rewrite the tool. Write a thin layer that takes whatever geometry you allready have and passes it across as calls. That way if the project goes quiet for a year, your work still stands on its own.
Tips for actually using an open source CAD kernel, from someone who fumbled through it
Oct 17, 2026
Last reply: 1 day ago
4 Replies
I came at it from the other end, mostly wanting to clean up scanned meshes before slicing. Spent a weekend on it with a broken ankle so plenty of couch time. What I found is that if your input is already a mess of triangles, the kernel fights you the whole way, because it relly does want proper closed bodies with clean edges. I ended up doing the cleanup in Meshmixer first, then passing the result over, and only then did the boolean stuff behave. On the docs, my expirience was a bit better than yours. The header comments are sparse but the naming is consistent enough that after a week I coud guess most function purposes and be right maybe eight times out of ten. Slow going though.
Your point about keeping a thin layer between your code and the library is the part I wish I had heard earlier. I wired a first version directly in and then had to untangle it when I changed how my printer profiles handled units. Kept the interface, threw out the rest, much happier now.
Tried it for making parametric brackets and enclosure parts, and that's where it clicked for me. I keep a little text file of dimensions for each project, feed it into my script, and it spits out a solid I can export and slice. Redid a cabinet hinge spacer three times in ten minutes once the template was working. One thing that tripped me up was fillets, if you round an edge before the part is fully shaped, later cuts eat the rounding and you get ugly results. Order of operations matters more than I expected.
My problem was silent failures, booleans quietly returning garbage with no error message anywhere. The thing that got me unstuck was dumping every intermediate solid to an STL file and eyeballing each one in my slicer before moving to the next step. Found a body with a flipped face inside a wall in about ten minutes that way, after two days of guessing. It felt clunky at first but now I kind of like having the checkpoint files, they double as a record of how a part came together.
This whole thing takes me back to the late 90s when we paid serious money for kernels like this and the license server was always down on a Friday afternoon. Getting the same capability for free still feels strange. I've been running it on some old STEP files I kept from a job years ago and most of them come in clean, wich surprised me. One thing I'd tell anyone: keep your models simple early on. I loaded a big assembly first thing and it chewed through memory like nothing I'd seen since the old days. Build one part, get it right, then grow from there.
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required