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.
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.
>corners where 3 fillets meet
* 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.
>that’s not good enough for real world manufacturing and simulation
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.
^1: Which I really appreciate, but let's be real, it is far behind eg. parasolid.
There are many geniuses on HN for tacking up challenge
As noted elsethread, there's only one geometric kernel which is decently far along and opensource and it's over 1 million LOC --- I doubt it's being included in any training data, and I doubt that an LLM could regurgitate such a large project which would then compile w/o errors and then work as expected --- the number of tokens required to get such a project to an initial state is a marked hurdle as well.
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.
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 ;-)
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.
I've been thinking about trying to implement this in freecad but I'm still exploring the idea.
Anytime I try to jump into Fusion or FreeCAD I immediately hit a wall (like trying pirated Maya when I was a kid).
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:
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.
Major caveat! Also online access required.
And if you decide to upgrade, the next tier is 1,410€ per year.
For that amount of cash, FreeCAD can abuse and torture me quite a bit. Lol.
Also at the rate FreeCAD is developing and improving now, if more people would drop just 1k€/ donations into FreeCAD/OCCT, chances are your pains will ease rather sooner than later.
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.
Dune3D is more like Solvespace with a few improvements and bug fixes vs being anywhere near FreeCAD in terms of capability. Improvements include using STEP files in assemblies and having some ability to make Fillets or Chamfers. Bugs fixes would be due to using OCCT for NURBS surfaces - solvespace frequently fails with NURBS boolean operations.
As for overall capability, FreeCAD does everything these others do but also supports lofting and other modeling options, BIM for architecture, I think it does pre- and post- processing for FEA, and maybe some other "big tool" things.
0: https://github.com/solvespace/solvespace/issues/149
1: https://dune3d.org/