[schiffern]

  >corners where 3 fillets meet

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?

It certainly gets complex quickly!

[0] center, where the cubes all intersect https://entitleblogdotorg3.files.wordpress.com/2015/02/esche...

[throwup238]

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.

[hnben]

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

[throwup238]

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.

[schiffern]

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

[throwup238]

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.

[ruevs]

Join SolveSpace development? ;-)

[schiffern]

This is why geometric kernels are the gateway to madness. ;) Thanks for the clarification.