SolveSpace is a wonderfully different take on parametric CAD, but development has really slowed, and it seems fundamentally incapable of some pretty rudimentary features (like chamfers[0]). Dune 3D[1] seems like a pretty effective spiritual successor.
Chamfers and Fillets are my next major undertaking. Don't expect them any time soon, but they've moved to the top of my list. They are extremely difficult to do in the general case - so we will not cover all cases. Several years ago I tried an experiment:
That could only do the top or bottom of a straight extrusion. This time will be a more general than that. Not looking forward to doing corners where 3 fillets meet ;-)
Aren't there licesing issues with porting a proprietary implementation into an open-source one that could open up the project to legal issues with the proprietary vendor?
Hi! Thanks for your hard work! I just want you to know it's definitely worth it!
I am using SolveSpace for my 3D prints because I just don't have time to learn anything else. With SolveSpace I've been productive in like 2 hours after launching it the first time.
So far you've saved me like $500 in things I've printed instead of bought. Just last week I've printed nasal manifold for my DIY sleep monitoring setup. Replacement specs legs a month ago.
If you really make fillets and chamfers a reality, please don't forget to open donations.
I would imagine there are a few different possible options (preferably a settable parameter):
* Intersection. Conceptually the simplest, the chamfers would just be joined by the solid addition of all three fillet surfaces, creating three new sharp corner edges that meet at a single vertex.
* Rolling sphere. Imagine an idealized spherical "thumb" smoothing out caulk. The middle would be joined by a new spherical concave surface, tangent to all three fillets. Also generalizable to convex fillet intersections, smoothing out sharp corners.
* NURBS, with adjustable parameters or even control points, eg when you want a little more "meat" in a corners for strength of a part.
* Flat corners, for chamfers (what do do when N>3 corners meet?)
* What else?
Ideally you might be able set the corner type separately for inside vs outside corners, or on a per-vertex or (in the most granular case) per-incoming-edge basis? Is that crazy?
How do saddle corners[0] behave? Does it just "work out" and (by some miracle) uniquely resolve for all permutations and corner types?
That’s not even the complex part. Most of what you describe is a user interface issue, not a geometric kernel issue.
The hard part of 3 corners fillets is the tolerances. Each of those fillet operations has its own compounding float errors and when they meet, the intersection is so messy that they often do not intersect at all. This breaks almost every downstream algorithm because they depend on point classification to determine whether an arbitrary point is inside the manifold, outside, or sitting on an edge or vertex.
And that description of the problem is just scratching the surface. Three corner filets create a singularity in UV space at the common vertex so even when you find a solution to the tolerance problem you still have to deal with the math breaking down and a combinatorial explosion of special cases, almost each of which has to be experimentally derived.
when i did openscad, i just did a minowski hull with a 4sided bipyramid (aka rotated cube) to get chamfers for my cubes.
bonus: minowski hull with a round pyramid adds chamfers in the vertical and fillets in the horizontal, which is what i want for 3d printing most of the time. additionally it closes small overhangs, and it makes fonts smoother (i.e. fonts don't extrude in a 90degree angle, and get 45degree instead, and print better on vertical faces)
disclaimer: I havent used openscad for about a year and my memory may be fuzzy
edit: i am not saying minowsky hull would directly solve your problem, but maybe the algorithm gives you inspiration to solve your numerical issues
OpenSCAD is mesh based so it's not even in the same universe as a proper brep geometric kernel. Everything is easier when you give up on the math entirely, but that’s not good enough for real world manufacturing and simulation.
All of the major commercial geometric kernels have been working on these problems for thirty years and I’m sorry, but your five minutes experience with a glorified tessellator isn’t going to make progress on long standing computational geometry problems.
>that’s not good enough for real world manufacturing and simulation
Dumb question: why not?? It's working for that guy and his 3D printer apparently, which is "real world" (though one could certainly argue it's not proper "manufacturing").
In theory pi has infinite places, sure . In real-world practice (vs math-lympics) you never need more than 100 digits, and indeed you rarely ever actually need more than 5.
Why doesn't it work to "just" throw more bit-width and more polygons at it? Who out there actually needs more than that (vs who just thinks they do)?
The answer boils down to “floating point math” and “discontinuities”.
> indeed you rarely ever actually need more than 5.
That’s not how math works. With every operation the precision falls, and with floats the errors accumulate. What was five digits quickly becomes 3 digits and now you’ve got three surfaces that are supposed to, but don’t technically intersect because their compounding errors don’t overlap even though the equations that describe them are analytically exact. Modern geometric kernels have 3 to 7 tolerance expansion steps that basically brute force this issue when push comes to shove.
Once you have these discontinuities, a lot of critical math like finite element modeling completely breaks down. The math fundamentally depends on continuous functions. Like I mentioned above, three corner filets create a singularity in parametric space by default, so even the core algorithms that kernels depend on to evaluate surfaces break on a regular basis on basic every-day operations (like a box with smoothed edges - aka almost every enclosure in existence)
> Who out there actually needs more than that (vs who just thinks they do)?
I can’t stress this enough: almost everyone. CAD isn’t one of those fields where you can half ass it. Even the simplest operations are bound to create pathological and degenerate cases that have to be handled, otherwise you have a pile of useless garbage instead of a 3d model.
Slicers deal with meshes, like video game renderers, not boundary representations like CAD kernels. There is effectively zero overlap. Even just tessellation, the step that converts brep to mesh, is significantly harder than anything 3d printing software has to do.
>> I'm curious why you didn't go with OCCT for Solvespace.
I didn't start Solvespace, but Jonathan was apparently in a DIY mode after developing his take on constraint-based sketching. It's also very easy to go from NURBS curves to NURBS surfaces, the challenge begins at boolean operations which continue to be a source of bugs for us. This is really the only option other than OCCT and the code is small and approachable so I try to make it better.
Yeah. To quantify, OCCT is >1M lines of code, and SolveSpace's NURBS kernel is <10k. This general smallness is what subsequently made stuff like the browser target feasible, though it obviously comes with downsides too.
We'd welcome contributions, and it's much easier to contribute to the smaller codebase. I think there's potential for coding agents to accelerate this work since robust point-in-shell and shell-is-watertight tests are mostly sufficient to judge correctness, allowing the agent to iterate; loosely you could define your geometric operation as a function of whether a point should lie within the output region, then ask the agent to convert that to b-rep. I wouldn't currently expect useful progress without deep human effort and understanding though.
Would it be worthwhile to consider switching to OCCT (or make it optional)? It would make certain things such as fillets/chamfers much easier, I suppose, and it would make those boolean operation bugs go away. And exporting to various formats would be easy.
>> Would it be worthwhile to consider switching to OCCT
It would, and it has been considered. The sketch elements in solvespace are significantly decoupled from the solid model. That means we could substitute (via wrapper maybe) an OCCT object instead of our SShell class. Then you'd have to change a set of solvespace curves to OCCT curves to make extrusions from them and such. But that would be most of the work.
We do tag all triangles in the mesh with a sketch entity handle for flat surfaces so you can constrain points to a face. I'm not sure how that would be handled. We will also be tagging edges of the solid with sketch entity handles in the future so we can do chamfers and fillets - say by selecting a line entity and applying a modifier to it which gets applied to the NURBS shell. I'm not sure how that would go with OCCT.
Perhaps you could create both the shell and the OCCT object. Then when an edge is chamfered, you could look it up in the OCCT object (simply find all segments which are sufficiently close to the chamfered edge). And then call the OCCT chamfer function. Or something along those lines.
I’m looking for a recommendation to get beyond TinkerCAD (for 3d printing). I learned it in 2019 and came back in 2025 when I got my own printer. It is comfortable and fine for my purposes but lacks basic things like chamfer and fillets.
Anytime I try to jump into Fusion or FreeCAD I immediately hit a wall (like trying pirated Maya when I was a kid).
Try FreeCAD one more time, if you haven't tried 1.0+, and it might stick. I've finally, in the past 6 months moved all my work to FreeCAD and KiCad after trying both many times over the past decades.
I highly recommend watching one of MangoJelly's beginner videos for FreeCAD, even if you have CAD experience. It made it very clear how to adapt my Fusion360 skills.
OnShape is pretty approachable, and has lots of good tutorial videos. They offer free accounts for non-commercial use with the caveat that all of your documents must be public.
If you haven't tried FreeCAD recently, it's gotten a lot better in the past couple of years. It seems to have hit escape velocity, so to speak, and is improving rapidly in a way it hadn't for a long time.
I would recommend pirating SOLIDWORKS and learning with that. It has the easiest UX of the parametric CAD modellers, and once you know the general sketch-extrude methodology you will find the others a lot easier.
Actually I think they have a hobbyist subscription which isn't totally extortionate now if you want to stay legal. Maybe get it for a year.
You may try onshape that is supposed to have a better accessibility than fusion 360, but unfortunately it doesn't seem that a CAD software with a complexity intermediate between tinkerCAD and FreeCAD an dthe pro CAD software exists
Some years ago I tried to learn CAD by doing some FreeCAD tutorials, and failed. But I hear 1.0 was a big step forward, and the recently released 1.1 is also a big step, and it should be somewhat decent nowadays. Maybe I need to try again one day.
I love solvespace, it is hard to describe but despite it's limitations and problems (and there are many) it feels joyous to use if that makes sense. Something about it's simple and straightforward interface just makes it fun. To the point that my biggest gripe is the modal dialogs that pop when a constraint is deleted or it's conditions cannot be met. It is quite awkward compared to the rest of the workflow.
Anyhow, salutes to the author of this web port, very slick.
Minor nit: why does the rendered in-window text use a really awful pixelated font? It looks like what happens when a font gets rendered onto a pixel grid without any hinting or snapping.
Looking at stream events, the event type is so long and often repeated for each event with little extra payload it could be potentially easy win for Anthropic to optimize system bandwidth by using shorthands.
I’ve wondered how feasible it would be to start building browser-based CAD/design products to replace our expensive and poorly supported paid plugins and niche products. Seems promising!
Does this use its own backend/engine? I've been working on LLM to CAD tool[0] and have realised there are so many backends and options to choose from. Since the realisation I'm trying to find the best representation for an LLM. I think OpenSCAD is currently the best and most feature complete choice, but I definitely need to dig a bit deeper. If anyone has any pointers I welcome them!
128 comments
0: https://github.com/solvespace/solvespace/issues/149
1: https://dune3d.org/
https://github.com/solvespace/solvespace/issues/453#issuecom...
That could only do the top or bottom of a straight extrusion. This time will be a more general than that. Not looking forward to doing corners where 3 fillets meet ;-)
I also appreciate the difficulty of generalizing chamfers/fillets. There's a reason that basically all FOSS CAD packages have struggled with it.
> difficulty of generalizing chamfers/fillets. There's a reason that basically all FOSS CAD packages have struggled with it.
Could you decompile CAD, run it through an LLM, and call it a day?
Never presume that a thing is legal (or will not later be punished) on the basis that someone is already doing it.
All software that isn't delivered over client/server to thin clients is now subject to being trivially cloned.
I am using SolveSpace for my 3D prints because I just don't have time to learn anything else. With SolveSpace I've been productive in like 2 hours after launching it the first time.
So far you've saved me like $500 in things I've printed instead of bought. Just last week I've printed nasal manifold for my DIY sleep monitoring setup. Replacement specs legs a month ago.
If you really make fillets and chamfers a reality, please don't forget to open donations.
* Intersection. Conceptually the simplest, the chamfers would just be joined by the solid addition of all three fillet surfaces, creating three new sharp corner edges that meet at a single vertex.
* Rolling sphere. Imagine an idealized spherical "thumb" smoothing out caulk. The middle would be joined by a new spherical concave surface, tangent to all three fillets. Also generalizable to convex fillet intersections, smoothing out sharp corners.
* NURBS, with adjustable parameters or even control points, eg when you want a little more "meat" in a corners for strength of a part.
* Flat corners, for chamfers (what do do when N>3 corners meet?)
* What else?
Ideally you might be able set the corner type separately for inside vs outside corners, or on a per-vertex or (in the most granular case) per-incoming-edge basis? Is that crazy?
How do saddle corners[0] behave? Does it just "work out" and (by some miracle) uniquely resolve for all permutations and corner types?
It certainly gets complex quickly!
[0] center, where the cubes all intersect https://entitleblogdotorg3.files.wordpress.com/2015/02/esche...
The hard part of 3 corners fillets is the tolerances. Each of those fillet operations has its own compounding float errors and when they meet, the intersection is so messy that they often do not intersect at all. This breaks almost every downstream algorithm because they depend on point classification to determine whether an arbitrary point is inside the manifold, outside, or sitting on an edge or vertex.
And that description of the problem is just scratching the surface. Three corner filets create a singularity in UV space at the common vertex so even when you find a solution to the tolerance problem you still have to deal with the math breaking down and a combinatorial explosion of special cases, almost each of which has to be experimentally derived.
bonus: minowski hull with a round pyramid adds chamfers in the vertical and fillets in the horizontal, which is what i want for 3d printing most of the time. additionally it closes small overhangs, and it makes fonts smoother (i.e. fonts don't extrude in a 90degree angle, and get 45degree instead, and print better on vertical faces)
disclaimer: I havent used openscad for about a year and my memory may be fuzzy
edit: i am not saying minowsky hull would directly solve your problem, but maybe the algorithm gives you inspiration to solve your numerical issues
All of the major commercial geometric kernels have been working on these problems for thirty years and I’m sorry, but your five minutes experience with a glorified tessellator isn’t going to make progress on long standing computational geometry problems.
In theory pi has infinite places, sure . In real-world practice (vs math-lympics) you never need more than 100 digits, and indeed you rarely ever actually need more than 5.
Why doesn't it work to "just" throw more bit-width and more polygons at it? Who out there actually needs more than that (vs who just thinks they do)?
> indeed you rarely ever actually need more than 5.
That’s not how math works. With every operation the precision falls, and with floats the errors accumulate. What was five digits quickly becomes 3 digits and now you’ve got three surfaces that are supposed to, but don’t technically intersect because their compounding errors don’t overlap even though the equations that describe them are analytically exact. Modern geometric kernels have 3 to 7 tolerance expansion steps that basically brute force this issue when push comes to shove.
Once you have these discontinuities, a lot of critical math like finite element modeling completely breaks down. The math fundamentally depends on continuous functions. Like I mentioned above, three corner filets create a singularity in parametric space by default, so even the core algorithms that kernels depend on to evaluate surfaces break on a regular basis on basic every-day operations (like a box with smoothed edges - aka almost every enclosure in existence)
> Who out there actually needs more than that (vs who just thinks they do)?
I can’t stress this enough: almost everyone. CAD isn’t one of those fields where you can half ass it. Even the simplest operations are bound to create pathological and degenerate cases that have to be handled, otherwise you have a pile of useless garbage instead of a 3d model.
Slicers deal with meshes, like video game renderers, not boundary representations like CAD kernels. There is effectively zero overlap. Even just tessellation, the step that converts brep to mesh, is significantly harder than anything 3d printing software has to do.
>> I'm curious why you didn't go with OCCT for Solvespace.
I didn't start Solvespace, but Jonathan was apparently in a DIY mode after developing his take on constraint-based sketching. It's also very easy to go from NURBS curves to NURBS surfaces, the challenge begins at boolean operations which continue to be a source of bugs for us. This is really the only option other than OCCT and the code is small and approachable so I try to make it better.
We'd welcome contributions, and it's much easier to contribute to the smaller codebase. I think there's potential for coding agents to accelerate this work since robust point-in-shell and shell-is-watertight tests are mostly sufficient to judge correctness, allowing the agent to iterate; loosely you could define your geometric operation as a function of whether a point should lie within the output region, then ask the agent to convert that to b-rep. I wouldn't currently expect useful progress without deep human effort and understanding though.
>> Would it be worthwhile to consider switching to OCCT
It would, and it has been considered. The sketch elements in solvespace are significantly decoupled from the solid model. That means we could substitute (via wrapper maybe) an OCCT object instead of our SShell class. Then you'd have to change a set of solvespace curves to OCCT curves to make extrusions from them and such. But that would be most of the work.
We do tag all triangles in the mesh with a sketch entity handle for flat surfaces so you can constrain points to a face. I'm not sure how that would be handled. We will also be tagging edges of the solid with sketch entity handles in the future so we can do chamfers and fillets - say by selecting a line entity and applying a modifier to it which gets applied to the NURBS shell. I'm not sure how that would go with OCCT.
But yes I've given a bit of thought to it ;-)
Anytime I try to jump into Fusion or FreeCAD I immediately hit a wall (like trying pirated Maya when I was a kid).
I highly recommend watching one of MangoJelly's beginner videos for FreeCAD, even if you have CAD experience. It made it very clear how to adapt my Fusion360 skills.
If you haven't tried FreeCAD recently, it's gotten a lot better in the past couple of years. It seems to have hit escape velocity, so to speak, and is improving rapidly in a way it hadn't for a long time.
Actually I think they have a hobbyist subscription which isn't totally extortionate now if you want to stay legal. Maybe get it for a year.
There's also a soft-fork which some folks are funding:
https://www.astocad.com/
I've been thinking about trying to implement this in freecad but I'm still exploring the idea.
It's so sad most guys aren't comming together to build some great CAD engine which open source really needs!
Gimp is shame, photoshop is increasingly being lockdown and people who have smarts to fix that are doing nothing.
Neat that they got it working in the browser.
Anyhow, salutes to the author of this web port, very slick.
I implemented a full kernel in rust and compile it to wasm https://github.com/ecto/vcad
Minor nit: why does the rendered in-window text use a really awful pixelated font? It looks like what happens when a font gets rendered onto a pixel grid without any hinting or snapping.
Anyone having used both can share their thoughts about how solvespace and OnShape compare?
On my end I’ve been loving OnShape and find it pretty intuitive. I also tried fusion360 but closed it after 5 minutes, it felt too sluggish.
> {"type":"content_block_delta","delta":{"text":" search"}}
See https://news.ycombinator.com/item?id=47580583
[0]: https://GrandpaCAD.com
Is there an open-source "cleanroom" re-implementation of the Parasolid kernel? I just like the way Solidworks does things vs. Autodesk.
SolveSpace officially is supported on Windows (Vista-11), Linux and macOS, and compiles with Emscripten and runs in a browser.
However with a little effort it also compiles for and runs on Windows 2000.
https://github.com/solvespace/solvespace/issues/1036#issueco...
So it runs on all the majour platforms from the last 26 years (excluding MacOS 9).
SolveSpace officially is supported on Windows (Vista-11), Linux and macOS, and compiles with Emscripten and runs in a browser.
However with a little effort it also compiles for and runs on Windows 2000.
https://github.com/solvespace/solvespace/issues/1036#issueco...
So it runs on all the majour platforms from the last 26 years (excluding MacOS 9).