WIP add functions for creating chamfers and fillets to the NURBS kernel - #1501

@phkahler great to see you attempting this. Over the years I've been considering this - most recently at the time Dune3D started.

In my head it works similarly to what you started outlining with one more level of abstraction:

A chamfer/fillet is:

• An edge modifier class/module/cpp_file goes over the selected edges and duplicates them (in reality each visible edge is already two coincident edges so the code could "just" move them) - this is specific to the fillet/chamfer tool.
• A general purpose patch tool (with conditions as parameters - e.g. G1 continuity), which is a separate class, generates NURBS patches to close the holes between the edges created in the previous step.

In the future the patch class can be used to implement generic patch functionality - e.g. close a "random" hole outlined by a contour of any edges (not necessarily straight) in 3d.

A general purpose patch tool may/will have to generate new edges on it's own (imagine a corner where a few edges meet and they are all filleted) and I am not sure how this will be handled by this approach. Intersections of the newly created NURBS surfaces will be these new edges.

• in reality each visible edge is already two coincident edges so the code could "just" move them

Woops you're right. Curves are not duplicated, but there are two TrimBy, one for each surface that meets along a curve. These reference the same underlying curve but one is "backward". So I'll still need to generate 2 new curves, and move both Trims rather than creating a new one. Good news - the PWL points are not in the trims!

Assuming all fillets meeting at a point are the same radius, the surface we want there is spherical. It's really hard to find anything (with google) on spherical NURBS patches, never mind triangular ones. But that's for later. Chamfers first and Fillets with 1 or 2 per vertex. I'm both excited and dreading this...

I'm both excited and dreading this...

Indeed :-)

I very welcome the attempt to add this. :)

Getting back to this soon. Here is a sketch to visualize how fillets meet at a corner. Drag the green lines around.
corner_arcs.zip

For equal radius fillets it forms a spherical triangle.
Edit: This is not the new feature demo, it's a line sketch to aid understanding the geometry of corner fillets.

So, is anyone feeling brave enough to pick this up during the days off and actually push the development forward?

Haha @dodox1 brave is right. Anyone is welcome to attempt this, and I'm happy to answer questions on how the internals work. Such a person would become highly knowledgeable in the solvespace NURBS code. Unfortunately my attempt last year didn't pan out and I wasn't even able to make partial shell modifications without problems. It really takes a deep dive into it to make progress. Next time I try I might limit myself to flat surfaces only just to get the basics down.

Sorry about the delay. This is now turning into a monster project. With all the time I had to think about it the implementation is going well. The code is in a testing state. Every shell potentially gets modified. There is a function to determine which edges get modified and it is over 200 lines long in order to specifically modify certain edges of specific test models. If it returns a positive number, that is a radius to apply to an edge. If it is a negative number that will produce a chamfer that cuts as deep as the fillet with the absolute value of that number. If you want to play, just have it return +3 and do an extrusion, or even a skewed extrusion. A vertex with 3 chamfers will get a little triangle patch. A vertex with 3 fillets will get a little spherical triangle patch - my scheme for that works well and in all cases.

There is a lot not possible yet:
Fillets of differing radius meeting at a corner.
Convex and concave fillets meeting at the same corner (otherwise both work).
Any non-exact edge - those produced by intersecting weird sufaces (no exact 3rd order curve).
And so on.

I'd like to wrap up the shell modifier code this weekend, and then get to work on linking sketch entities to shell edges so we can implement the UI for selecting edges and modifying them.

You know you've always wanted to fillet text:

One option for the edge selection UI, from what worked for me in a fork:
don't store edge indices, they shift after any upstream edit and the fillet
lands on other edges. Select a face instead and store it as a point on it plus
its normal, then find it again on every regeneration and take its edges. It
stayed stable, is easier to pick, and reaches circular edges. Picking single
edges can still be offered next to it.

One option for the edge selection UI, from what worked for me in a fork: don't store edge indices, they shift after any upstream edit and the fillet lands on other edges. Select a face instead and store it as a point on it plus its normal, then find it again on every regeneration and take its edges. It stayed stable, is easier to pick, and reaches circular edges. Picking single edges can still be offered next to it.

Thanks @dodox1 I like the idea of face selection. Where did you store the face selection and radius info?

What I was planning to do is tweak the shell generation to tag edges with the handle of the sketch entity they were created from, or correspond to. There are two things to overcome first. One is that revolve groups don't create arc entites at all. #1631 is an attempt to add them. The bigger problem is that most 2D sketches generate redundant entities when you extrude, revolve, or lathe #1642, so we need to pick only one of the two points to create a line or curve from and apply its handle to the generated curve(s).

Beyond that, not all shell edges have entities over them - where surfaces intersect in booleans is an obvious one. Having the ability to select a face and fillet all its edges would be a nice feature and could cover some of these edges too! A less appealing option might be to have a group parameter "fillet radius" specifically for intersections during booleans.

Per group: a list of faces, each a point on the face plus its normal, and the
radius is the group's usual size parameter.
Both are saved with the group: the radius in the existing valA, the faces in
a new 'F' field, and single edges in a new 'E' field as indices.
The edges are recomputed from the faces on every regeneration. Single edges
are still index based in my fork, which is the fragile part, so tagging edges
with their sketch entity as you plan is the better fix for those.

For the booleans: faces should cover intersection edges too, since such an
edge belongs to a face. A per group radius for intersections would be a simple
fallback.

Here is how the face selection works in my fork: https://youtu.be/YbZ7HQgTWbs

An idea I arrived at for naming edges, just as a suggestion: store the entity
handle an edge was generated from instead of its index, since handles stay
stable across edits and save/reload. Edges without an entity (boolean
intersections, fillet edges themselves) would fall back to geometry, like the
face point + normal. FreeCAD ended up in the same place, naming elements from
their origin after years of positional "Edge12" names.

X Off topic and at the same time very much on topic :-)

CLICK ME

As I mentioned a while ago somewhere - once the the vibe coding starts "working" there will be many forks :-)

Here is another where fillets and chamfers are "implemented": https://github.com/joernfeuerabend/solvespace

This is better that the original vibe coded attempt by g19fanatic (#577 (comment)) but the "handle" in screen shot above is a bug (just like in the original vibe coded attempt) @joernfeuerabend.

@phkahler One interesting change in that fork joernfeuerabend/solvespace@2b096c7 may be here :

* Drop zero-length trim edges in NURBS Boolean

An intersection curve that touches a surface in a single point, as where
two fillets meet tangent to a face at a corner, left an edge of zero length
in the trim edge list of that surface. The trim polygon then failed to
assemble.

The involute gear in that fork is also rather interesting/amusing:

Who wants to draw all that stuff by hand anyway https://www.printables.com/model/84042-involute-gear-designed-in-solvespace. On the other hand this is a rather "high level" primitive for the SolveSpace "minimalist ideology" :-)

Since Claude Fable in May 2026 the LLMs have become truly interesting :-) My only "worry" is: "Who is ever going to read all that code?" :-)

@ruevs I know Open Cascade is getting very popular - some slicers even use it now to read STEP files. Almost every other open source project that handles STEP files uses it (gcad3d being an exception). I had no idea anyone vibe coded fillets for solvespace.

BTW A gear tool has also crossed my mind. I'll have to look at that one. There are a few other things on forks that we might want to bring upstream.

@ruevs I know Open Cascade is getting very popular - some slicers even use it now to read STEP files. Almost every other open source project that handles STEP files uses it (gcad3d being an exception).

It's the only "fully" functional option - until we end up with:

• NURBS - better at handling singularities then Parasolid ;-)
• Fillets and chamfers - This PR .
• STEP linking (if we are going to be vibe coding I think I'll pick this one up).
• Lofts.
• "Arbitrary" 3d NURBS patches with draggable control points and controllable continuity conditions (C1, C2) on the contour.

I had no idea anyone vibe coded fillets for solvespace.

You spend too much time vibe coding and not enough time snooping around, and I do the opposite ;-) :-D

SolveSpace Forks:

• https://github.com/g19fanatic/solvespace (chamfers and fillets in branches)
• https://github.com/brosilio/solvespace/tree/develop (generates pretty decent engineering drawings, a bit buggy)
• https://github.com/tucher/solvespace/commits/slvs-incremental-resolve/ (solver improvements)
• https://github.com/0xSeren/neosolve
  • https://github.com/dodox1/neosolve (OCCT, chamfers, fillets)
• https://github.com/chalkwalk/solvespace-ng (Web builds) (OCCT, chamfers, fillets, new UI, STEP linking - very ambitious, very buggy)
• https://github.com/joernfeuerabend/solvespace (chamfers and fillets)

Other vibe coded CAD:

• https://github.com/joachimhs/akse3d
• https://github.com/materializr-cad/materializr
• https://github.com/ayourk/hobbycad
• https://github.com/iffy/BearCAD (this one is very good)
• https://github.com/tangency-labs/solidcraft (Rust)
  • https://github.com/tangency-labs/solidcore (Rust)
    • https://github.com/NVIDIA-Omniverse/usd-brep/tree/main/source/SMLib (the month old original in C++)
      • https://nvidia-omniverse.github.io/usd-brep/latest/docs/gallery.html (the "X-ray" rendering mode is very nice)
  • https://github.com/mechvane/mechvane (https://mechvane.dev/)
• https://github.com/yuechen-li-dev/Aetheris

BTW A gear tool has also crossed my mind. I'll have to look at that one. There are a few other things on forks that we might want to bring upstream.

As I said - who is ever going to (carefully) read all that code :-)

I started contributing to SolveSpace because of the beautiful, clean, hand crafted, coherent, compact and "opinionated" code, that @jwesthues had written back in 2008. And the "control freak" in me wants to read (and undersyand, and agree with) every line of AI generetad code - to make sute it maintains the "vibe" (pun intended). But I don't have the bandwidth - I'm slow - my brain runs on only ~200W and the cache/RAM is too small (the HDD is OK) :-D

@ruevs When this is done I'm planning to squash it all into one or two commits. If you want to see the current state of it that way I have a separate squashed branch here

The file fillet_test.cpp will go away completely. That is just how claude is finding specific edges in our test files to apply fillets to.

Some of the changes are bug fixes or enhancements similar to what you put in a PR for proper handling of planar surfaces, and may even overlap.

I'm with you on the vibe code review problem. One of my claude logs without the tool calls is 135K, this is not just handing the task over to AI and forgetting about it, it's hours of interaction. That said, the code readability seems lower that human written.

This feature will be mostly located in a couple new files, so I think it'll be worth it. It reminds of when I wrote the IDF file linking code - I wasn't happy with it, but it's all contained in one file.

Also might be a good idea to push this before it's fully functional. Maybe some of the other vibe coders want to experiment with the UI for applying fillets and chamfers! This just modifies an existing shell, so if we don't call it, it won't do anything ;-)

This PR is still here for anyone wanting to see the step by step development via commit messages. But the squashed commits are now in PR #1815

I'm going to close this. Probably next week I'll move the other PR to a branch. Next steps will be figuring out topological naming for shell edges which will be all internal stuff, hopefully not very complicated.