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