You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It should be possible to select an arbitrary set of edges in 3D, and then click "chamfer/fillet", and have it nicely modified. Sometimes you can do this in a sketch with arcs, but often it is very tedious or impossible.
Most professional CAD tools include these as basic operations. For some reason they are usually separate tools but I think it makes more sense to have it as one tool with a "chamfer style" option which is "straight" or "rounded" (and a radius option).
Reacted by Foad S. Farimani, Pablo Ovelleiro Corral, tjareson, Valentyn Berezin, Ariel and Ryan Ross
This is unlikely to ever happen. The only open-source backend that natively supports chamfers and fillets is OpenCASCADE, and it (a) has an incompatible license, and (b) is a rather poor quality codebase, since it exists to sell consulting services.
Although it would be technically possible to integrate OCE, it would create a situation where instead of a single version of SolveSpace limited in functionality there would be two versions of it, each inferior in its own regard, and so I am against doing so.
I've looked into extending SolveSpace's NURBS backend a few years ago, and my conclusion was that the amount of work was prohibitive for a volunteer-run open-source project, requiring several people employed full-time for multiple years.
Yes, it's really unfortunate. A few years ago I was working much more closely on SolveSpace together with one full-time developer (@Evil-Spirit), and based on our discussions back then, I believe this is just not feasible for this project at this time.
Mostly it's just a lot of work to handle every possible case, and it's also work that needs to be done either with someone specializing in NURBS, or someone willing to invest a lot of time to learn the necessary math. I'm really happy to have @phkahler on board, who has been able to make very nice improvements to the NURBS code, but features like chamfers or fillets require a lot more effort to work well.
@Timmmm I can suggest reading the entire thread for issue #453 to get a little understanding of the issues.
There are several problems, the primary one being the way surfaces and entities are represented internally be SolveSpace. Surfaces are completely separate from the editable/constrainable entities you can interact with. When you do an extrude or other operation that creates a solid volume, the new entities are created separately from the surfaces. When entities are dragged new surfaces are created. This disconnect means that the first problem for a generalized fillet or chamfer tool is to identify which surfaces are going to be modified by the operation - it might be possible, but internally it's not set up for that.
The more conventional challenges are defining how existing surfaces need to be trimmed for the new edge features, figuring out what to do at corners (there are many special cases and different ways to cut there), and making sure there is proper continuity along the chamfer with regard to the U,V coordinates interpolated along both edges. There are a lot of papers written on this stuff, so we could pick something and try but then we end up facing the problem of SS internal representation that makes these things harder.
Having said all that, I was working on some new tools that may work for some of the more common use cases. These will all work at the time of extrusion and include: adding draft angles to an extrusion, adding a chamfer of fillet to the top or bottom of an extrusion, and possibly a frustum tool. The issues with those (except frustum) is that the entities will not take on the new geometry of the surfaces. In some cases that's fine while in others it's not. I hope to get back to that effort to see what can be worked out.
Reacted by Tim Hutt, ruevs, Steve Kelly, Michaël Fortin, Weitian LI and datamaskinen
For my personal (beginner) maker needs, it looks like fillets and chamfers are the only tools missing in Solvespace for me to make the designs I have in mind, which is mostly small objects and mechanical parts for 3D printing. That's too bad because I like Solvespace quite a bit! Much nicer to use (and more stable) than FreeCAD in my opinion. The workflow and keyboard shortcuts are just great.
@phkahler I'd be very interested in tools to provide some fillet / chamfer capability even if it's not the "real deal". Consider this a +1 from me! Are you still working on this to some extent?
Reacted by Théo Reichel, Pablo Ovelleiro Corral, Tanel Liiv, Ariel, Electra Sto-Helit and datamaskinen
@fortinmike After v3.0 is done I want to get back to making new construction tools. I'm not sure which ones will make it but everything I've mentioned in various threads is still on my mind.
@fortinmike After v3.0 is done I want to get back to making new construction tools. I'm not sure which ones will make it but everything I've mentioned in various threads is still on my mind.
3.1 is out, any news on adding fillet/chamfer tools?
Looking at this more - the person doing this @g19fanatic definitely knows what they are doing - I'm totally unable to set up the (mixture of experts?) LLMs and prompt them correctly to generate all this... And the token budget must be pretty big as well...
@ruevs . The token budget isn't large at all. i think i've spent $15 in tokens on this so far. I use these toolsets for a lot of my development and have some custom tooling setups that enable quick turnarounds.
I think i'm almost to an mvp (have been iterating through bugs). The screenshot you show is already some ways behind too.
I'll clean everything up after the mvp is there.
I wasn't going to mention anything or put in a PR until a felt it was useful just after the simple cases.
Ya exposed me! hah
@ruevs I looked at a few of the documentation files it generated. Wish we had some good documentation like that, but they're also full of things I'd want to correct, or add detail. Then the code seemed really long for what it's seems able to do.
@g19fanatic Did you see my PR #1501 ?? It contains an outline of how I was starting to approach this. As I was getting into it, it turns out there are some details missing. A lot of book keeping is necessary too, and if planned out I think it can be done fairly simply.
One thing to not is that a chamfer will create two new curves offset within the surfaces joined by the original curve. A fillet will need those same two new curves, and can use the points of the original curve as the control points for the "middle" of the fillet (with proper weight modification).
All of this needs to be tested with some kind of fake decision about which edges to apply changes to. Having the capability and plumbing it into solvespace are IMHO two very separate projects. I don't think AI is up to the task in either case, but I'm curious to see how it goes.
I have a rudamentory understanding of NURBs geo math and its been more of a hobby of mine ever since I got into 3d printing 10 years ago. I kicked off these AI session by specifically looking at other repo's codebases that execute these functions. The long/functions are almost direct clones translated to use solvespace's internal math libs. This obviously is missing the tedious book-keeping that is necessary as solvespace does it a little different than others.
Almost all of those "findings" files are usually thrown away after a feature is in and documented for me. I usually keep the project_info folder in a separate branch for continuing to do more LLM work (or recreate it).
I've been slowly working through the book-keeping bugs as they are found and continue to expand on the features.
For simple cases, they're working pretty well atm. We'll see how far I can go and how much they can be cleaned up before I put in an actual PR.
#1501 — "WIP add functions for creating chamfers and fillets to the NURBS kernel" (Draft PR, Dec 10, 2024) C:\PAR\Projects\SolveSpace\git\findings\14-github-community-requests.md 123 6
| #1501 | WIP add functions for creating chamfers and fillets to the NURBS kernel | Draft PR | Dec 2024 | phkahler | C:\PAR\Projects\SolveSpace\git\findings\14-github-community-requests.md 242 4
The SolveSpace community has clearly wanted chamfer/fillet since at least 2017. The feature is officially listed as "commonly requested" by maintainer ruevs. The core contributor phkahler has attempted an implementation (PR #1501, Dec 2024), identified the key algorithmic challenges, and offered architectural guidance. His final advice: "Next time I try I might limit myself to flat surfaces only just to get the basics down." This suggests the MVP strategy should be: C:\PAR\Projects\SolveSpace\git\findings\14-github-community-requests.md 248 226
Critical decision: phkahler's failed PR (#1501) revealed that using the standard C:\PAR\Projects\SolveSpace\git\findings\21-chamfer-group-design.md 56 47
From phkahler's PR #1501 (the only prior attempt): C:\PAR\Projects\SolveSpace\git\findings\21-chamfer-group-design.md 564 21
PR #1501 — "WIP add functions for creating chamfers and fillets to the NURBS kernel" C:\PAR\Projects\SolveSpace\git\findings\28-solvespace-chamfer-attempts.md 14 9
This is the complete content of the new file created in PR #1501: C:\PAR\Projects\SolveSpace\git\findings\28-solvespace-chamfer-attempts.md 38 65
Confirmed Working in PR #1501 C:\PAR\Projects\SolveSpace\git\findings\28-solvespace-chamfer-attempts.md 243 30
equivalent to SolveSpace's MakeFromBoolean, but the key insight from phkahler's PR #1501 C:\PAR\Projects\SolveSpace\git\findings\30-cgal-and-geometric-algorithms.md 375 90
The reason: the standard MakeFromBoolean/MakeFromDifferenceOf pipeline fails for chamfer because the chamfer surface is coincident with the adjacent original faces, causing COINC_OPP degeneracy in the boolean classifier (confirmed by phkahler's crashed PR #1501). C:\PAR\Projects\SolveSpace\git\findings\36-synthesis-part1.md 164 262
Direct topology injection (NOT boolean pipeline): The standard MakeFromBoolean/MakeFromDifferenceOf cannot be used due to COINC_OPP degeneracy when the chamfer/fillet surface is coincident with adjacent faces. Confirmed by phkahler's crashed PR WIP add functions for creating chamfers and fillets to the NURBS kernel #1501. C:\PAR\Projects\SolveSpace\git\findings\38-synthesis-part3.md 39 256
analysis, community discussions (phkahler PR #1501), and analogous implementations in C:\PAR\Projects\SolveSpace\git\findings\39-risk-assessment.md 7 47
I've been slowly working through the book-keeping bugs as they are found and continue to expand on the features.
For simple cases, they're working pretty well atm. We'll see how far I can go and how much they can be cleaned up before I put in an actual PR.
I'm EXTREMELY curious how far the LLMs will get this... I've been following the field (of AI), as а side interest/hobby, for 26 years... the last 8 have been the most interesting by far :-)
@g19fanatic In case you have not found this problem yet ;-)
@ruevs
Thank you!
rect -> extrude -> rect on edge -> extrude difference -> fillet internal edge.
Got it!
Actually the fix i'm working on right now might take care of this issue too.
If you want to start an issue on my clone so that we don't continue to jam up this thread w/ this feature issue?
That'll help keep this thread cleaner.
Re-AI - I've been in military distributed aircraft simulations for almost 17 years. c++ heavy environment. AI is relatively new for me though I've written my collection of toy CNNs in the past.
It will definitely be interesting to see how far I can take this. I have a good feeling that we'll something pretty useful by the end.
Now maintainable? thats the real question but I believe with enough documentation and distillation, it can be good.
@ruevs that looks like it's not limiting the surface to the trim portion of the SCurve. Something I'd realized yesterday is a single curve can have multiple trims which need to create separate fillets. Or in this case, only the segment that actually has a trim. For example, cut a box out of a box so it forms a U shape. the top edge will have 2 trims along the same edge with the center cut out between them. This was something I think I hadn't realized when I started looking at this. That means to "corners" of the fillets/chamfers are at the ends of the trims, not necessarily at the ends of the underlying curves. It sounds like @g19fanatic and his LLM pair programmer figured that out too.
BTW I also thought edge features need to be applied after the boolean as is clearly happening here.
@g19fanatic since issues on your fork are not enabled I'll post this here: #1410 (comment)
It's a model with many corner cases (pun intended :-D ) but with only flat surfaces (I created it while implementing the intersection boolean operation, and as you see both union and intersection still have bugs).
You can change the second extrusion group g005_extrude to difference mode. It should provide plenty of fun corners to fillet and chamfer for you and the LLM ;-)
Activity
whitequark commentedon Mar 31, 2020
This is unlikely to ever happen. The only open-source backend that natively supports chamfers and fillets is OpenCASCADE, and it (a) has an incompatible license, and (b) is a rather poor quality codebase, since it exists to sell consulting services.
Although it would be technically possible to integrate OCE, it would create a situation where instead of a single version of SolveSpace limited in functionality there would be two versions of it, each inferior in its own regard, and so I am against doing so.
I've looked into extending SolveSpace's NURBS backend a few years ago, and my conclusion was that the amount of work was prohibitive for a volunteer-run open-source project, requiring several people employed full-time for multiple years.
ruevs commentedon Mar 31, 2020
Hmm... I've personally "seen" you answer this twice. Perhaps a FAQ is in order?
whitequark commentedon Mar 31, 2020
Good idea.
Timmmm commentedon Mar 31, 2020
That is a shame!
whitequark commentedon Mar 31, 2020
Yes, it's really unfortunate. A few years ago I was working much more closely on SolveSpace together with one full-time developer (@Evil-Spirit), and based on our discussions back then, I believe this is just not feasible for this project at this time.
Timmmm commentedon Apr 1, 2020
What were the main problems, just out of interest?
whitequark commentedon Apr 1, 2020
Mostly it's just a lot of work to handle every possible case, and it's also work that needs to be done either with someone specializing in NURBS, or someone willing to invest a lot of time to learn the necessary math. I'm really happy to have @phkahler on board, who has been able to make very nice improvements to the NURBS code, but features like chamfers or fillets require a lot more effort to work well.
phkahler commentedon Apr 3, 2020
@Timmmm I can suggest reading the entire thread for issue #453 to get a little understanding of the issues.
There are several problems, the primary one being the way surfaces and entities are represented internally be SolveSpace. Surfaces are completely separate from the editable/constrainable entities you can interact with. When you do an extrude or other operation that creates a solid volume, the new entities are created separately from the surfaces. When entities are dragged new surfaces are created. This disconnect means that the first problem for a generalized fillet or chamfer tool is to identify which surfaces are going to be modified by the operation - it might be possible, but internally it's not set up for that.
The more conventional challenges are defining how existing surfaces need to be trimmed for the new edge features, figuring out what to do at corners (there are many special cases and different ways to cut there), and making sure there is proper continuity along the chamfer with regard to the U,V coordinates interpolated along both edges. There are a lot of papers written on this stuff, so we could pick something and try but then we end up facing the problem of SS internal representation that makes these things harder.
Having said all that, I was working on some new tools that may work for some of the more common use cases. These will all work at the time of extrusion and include: adding draft angles to an extrusion, adding a chamfer of fillet to the top or bottom of an extrusion, and possibly a frustum tool. The issues with those (except frustum) is that the entities will not take on the new geometry of the surfaces. In some cases that's fine while in others it's not. I hope to get back to that effort to see what can be worked out.
fortinmike commentedon Dec 7, 2020
That is indeed a shame :(
For my personal (beginner) maker needs, it looks like fillets and chamfers are the only tools missing in Solvespace for me to make the designs I have in mind, which is mostly small objects and mechanical parts for 3D printing. That's too bad because I like Solvespace quite a bit! Much nicer to use (and more stable) than FreeCAD in my opinion. The workflow and keyboard shortcuts are just great.
@phkahler I'd be very interested in tools to provide some fillet / chamfer capability even if it's not the "real deal". Consider this a +1 from me! Are you still working on this to some extent?
phkahler commentedon Dec 7, 2020
@fortinmike After v3.0 is done I want to get back to making new construction tools. I'm not sure which ones will make it but everything I've mentioned in various threads is still on my mind.
pinpox commentedon Mar 8, 2023
3.1 is out, any news on adding fillet/chamfer tools?
2 remaining items
ruevs commentedon Apr 6, 2026
Looking at this more - the person doing this @g19fanatic definitely knows what they are doing - I'm totally unable to set up the (mixture of experts?) LLMs and prompt them correctly to generate all this... And the token budget must be pretty big as well...
g19fanatic commentedon Apr 6, 2026
@ruevs . The token budget isn't large at all. i think i've spent $15 in tokens on this so far. I use these toolsets for a lot of my development and have some custom tooling setups that enable quick turnarounds.
I think i'm almost to an mvp (have been iterating through bugs). The screenshot you show is already some ways behind too.
I'll clean everything up after the mvp is there.
I wasn't going to mention anything or put in a PR until a felt it was useful just after the simple cases.
Ya exposed me! hah
phkahler commentedon Apr 6, 2026
@ruevs I looked at a few of the documentation files it generated. Wish we had some good documentation like that, but they're also full of things I'd want to correct, or add detail. Then the code seemed really long for what it's seems able to do.
@g19fanatic Did you see my PR #1501 ?? It contains an outline of how I was starting to approach this. As I was getting into it, it turns out there are some details missing. A lot of book keeping is necessary too, and if planned out I think it can be done fairly simply.
One thing to not is that a chamfer will create two new curves offset within the surfaces joined by the original curve. A fillet will need those same two new curves, and can use the points of the original curve as the control points for the "middle" of the fillet (with proper weight modification).
All of this needs to be tested with some kind of fake decision about which edges to apply changes to. Having the capability and plumbing it into solvespace are IMHO two very separate projects. I don't think AI is up to the task in either case, but I'm curious to see how it goes.
g19fanatic commentedon Apr 6, 2026
I have a rudamentory understanding of NURBs geo math and its been more of a hobby of mine ever since I got into 3d printing 10 years ago. I kicked off these AI session by specifically looking at other repo's codebases that execute these functions. The long/functions are almost direct clones translated to use solvespace's internal math libs. This obviously is missing the tedious book-keeping that is necessary as solvespace does it a little different than others.
Almost all of those "findings" files are usually thrown away after a feature is in and documented for me. I usually keep the project_info folder in a separate branch for continuing to do more LLM work (or recreate it).
I've been slowly working through the book-keeping bugs as they are found and continue to expand on the features.
For simple cases, they're working pretty well atm. We'll see how far I can go and how much they can be cleaned up before I put in an actual PR.
ruevs commentedon Apr 6, 2026
Indeed me too. But at the same time I would NEVER spend the time and effort to write this kind of documentation.
The LLM saw it ;-) And "thought" about it a lot :-)
Details
Code File Line Column#1501 — "WIP add functions for creating chamfers and fillets to the NURBS kernel" (Draft PR, Dec 10, 2024) C:\PAR\Projects\SolveSpace\git\findings\14-github-community-requests.md 123 6
URL: #1501 C:\PAR\Projects\SolveSpace\git\findings\14-github-community-requests.md 124 56
Key technical insights from PR #1501 discussion: C:\PAR\Projects\SolveSpace\git\findings\14-github-community-requests.md 157 35
8 ❤️ reactions on PR WIP add functions for creating chamfers and fillets to the NURBS kernel #1501 from multiple community members including maintainer ruevs C:\PAR\Projects\SolveSpace\git\findings\14-github-community-requests.md 184 25
The phkahler:fillet branch (PR WIP add functions for creating chamfers and fillets to the NURBS kernel #1501) has only 3 commits, last of which says "Will crash" C:\PAR\Projects\SolveSpace\git\findings\14-github-community-requests.md 197 35
| #1501 | WIP add functions for creating chamfers and fillets to the NURBS kernel | Draft PR | Dec 2024 | phkahler | C:\PAR\Projects\SolveSpace\git\findings\14-github-community-requests.md 242 4
The SolveSpace community has clearly wanted chamfer/fillet since at least 2017. The feature is officially listed as "commonly requested" by maintainer ruevs. The core contributor phkahler has attempted an implementation (PR #1501, Dec 2024), identified the key algorithmic challenges, and offered architectural guidance. His final advice: "Next time I try I might limit myself to flat surfaces only just to get the basics down." This suggests the MVP strategy should be: C:\PAR\Projects\SolveSpace\git\findings\14-github-community-requests.md 248 226
Critical decision: phkahler's failed PR (#1501) revealed that using the standard C:\PAR\Projects\SolveSpace\git\findings\21-chamfer-group-design.md 56 47
From phkahler's PR #1501 (the only prior attempt): C:\PAR\Projects\SolveSpace\git\findings\21-chamfer-group-design.md 564 21
GitHub PR WIP add functions for creating chamfers and fillets to the NURBS kernel #1501 by phkahler (findings/14-github-community-requests.md) C:\PAR\Projects\SolveSpace\git\findings\21-chamfer-group-design.md 595 14
Finding 14 — GitHub community requests (phkahler PR WIP add functions for creating chamfers and fillets to the NURBS kernel #1501 analysis) C:\PAR\Projects\SolveSpace\git\findings\22-fillet-group-design.md 826 56
PR #1501 — "WIP add functions for creating chamfers and fillets to the NURBS kernel" C:\PAR\Projects\SolveSpace\git\findings\28-solvespace-chamfer-attempts.md 14 9
This is the complete content of the new file created in PR #1501: C:\PAR\Projects\SolveSpace\git\findings\28-solvespace-chamfer-attempts.md 38 65
Confirmed Working in PR #1501 C:\PAR\Projects\SolveSpace\git\findings\28-solvespace-chamfer-attempts.md 243 30
equivalent to SolveSpace's
MakeFromBoolean, but the key insight from phkahler's PR #1501 C:\PAR\Projects\SolveSpace\git\findings\30-cgal-and-geometric-algorithms.md 375 90The cleanest approach (as phkahler confirmed via PR #1501) is: C:\PAR\Projects\SolveSpace\git\findings\32-group-generate-trace.md 262 54
Result: boolean failure (as confirmed by phkahler in PR WIP add functions for creating chamfers and fillets to the NURBS kernel #1501) C:\PAR\Projects\SolveSpace\git\findings\32-group-generate-trace.md 634 64
phkahler (PR WIP add functions for creating chamfers and fillets to the NURBS kernel #1501): "Trim polygon update is the hard part" C:\PAR\Projects\SolveSpace\git\findings\32-group-generate-trace.md 648 17
The reason: the standard
MakeFromBoolean/MakeFromDifferenceOfpipeline fails for chamfer because the chamfer surface is coincident with the adjacent original faces, causingCOINC_OPPdegeneracy in the boolean classifier (confirmed by phkahler's crashed PR #1501). C:\PAR\Projects\SolveSpace\git\findings\36-synthesis-part1.md 164 262| #1501 | Draft PR: WIP chamfer/fillet implementation | Dec 2024 | C:\PAR\Projects\SolveSpace\git\findings\37-synthesis-part2.md 156 4
PR #1501: The Only Implementation Attempt C:\PAR\Projects\SolveSpace\git\findings\37-synthesis-part2.md 158 9
Confirmed: phkahler's PR #1501 crashed using boolean approaches. C:\PAR\Projects\SolveSpace\git\findings\37-synthesis-part2.md 250 31
Direct topology injection (NOT boolean pipeline): The standard
MakeFromBoolean/MakeFromDifferenceOfcannot be used due to COINC_OPP degeneracy when the chamfer/fillet surface is coincident with adjacent faces. Confirmed by phkahler's crashed PR WIP add functions for creating chamfers and fillets to the NURBS kernel #1501. C:\PAR\Projects\SolveSpace\git\findings\38-synthesis-part3.md 39 256New file
src/srf/chamfer.cpp: Modeled after phkahler's PR WIP add functions for creating chamfers and fillets to the NURBS kernel #1501 structure, containsSShell::MakeFromChamferOf()andSShell::MakeFromFilletOf(). C:\PAR\Projects\SolveSpace\git\findings\38-synthesis-part3.md 49 6920. Phkahler PR #1501 Lessons Applied C:\PAR\Projects\SolveSpace\git\findings\38-synthesis-part3.md 930 21
The architecture above directly addresses the root causes of PR #1501's crash: C:\PAR\Projects\SolveSpace\git\findings\38-synthesis-part3.md 932 66
| PR #1501 Problem | This Architecture's Solution | C:\PAR\Projects\SolveSpace\git\findings\38-synthesis-part3.md 934 7
analysis, community discussions (phkahler PR #1501), and analogous implementations in C:\PAR\Projects\SolveSpace\git\findings\39-risk-assessment.md 7 47
phkahler confirmed in PR WIP add functions for creating chamfers and fillets to the NURBS kernel #1501 that vertex caps are extremely difficult C:\PAR\Projects\SolveSpace\git\findings\39-risk-assessment.md 119 29
phkahler's
filletbranch (PR WIP add functions for creating chamfers and fillets to the NURBS kernel #1501): Contains 112 lines ofsrc/srf/chamfer.cppC:\PAR\Projects\SolveSpace\git\findings\39-risk-assessment.md 387 39ruevs commentedon Apr 6, 2026
I'm EXTREMELY curious how far the LLMs will get this... I've been following the field (of AI), as а side interest/hobby, for 26 years... the last 8 have been the most interesting by far :-)
@g19fanatic In case you have not found this problem yet ;-)
InsideFilletOnDoubleSidedDifferenceExtrude.zip
g19fanatic commentedon Apr 6, 2026
@ruevs
Thank you!
rect -> extrude -> rect on edge -> extrude difference -> fillet internal edge.
Got it!
Actually the fix i'm working on right now might take care of this issue too.
If you want to start an issue on my clone so that we don't continue to jam up this thread w/ this feature issue?
That'll help keep this thread cleaner.
Re-AI - I've been in military distributed aircraft simulations for almost 17 years. c++ heavy environment. AI is relatively new for me though I've written my collection of toy CNNs in the past.
It will definitely be interesting to see how far I can take this. I have a good feeling that we'll something pretty useful by the end.
Now maintainable? thats the real question but I believe with enough documentation and distillation, it can be good.
phkahler commentedon Apr 6, 2026
@ruevs that looks like it's not limiting the surface to the trim portion of the SCurve. Something I'd realized yesterday is a single curve can have multiple trims which need to create separate fillets. Or in this case, only the segment that actually has a trim. For example, cut a box out of a box so it forms a U shape. the top edge will have 2 trims along the same edge with the center cut out between them. This was something I think I hadn't realized when I started looking at this. That means to "corners" of the fillets/chamfers are at the ends of the trims, not necessarily at the ends of the underlying curves. It sounds like @g19fanatic and his LLM pair programmer figured that out too.
BTW I also thought edge features need to be applied after the boolean as is clearly happening here.
ruevs commentedon Apr 7, 2026
@g19fanatic since issues on your fork are not enabled I'll post this here:
#1410 (comment)
It's a model with many corner cases (pun intended :-D ) but with only flat surfaces (I created it while implementing the
intersectionboolean operation, and as you see bothunionandintersectionstill have bugs).You can change the second extrusion group
g005_extrudetodifferencemode. It should provide plenty of fun corners to fillet and chamfer for you and the LLM ;-)g19fanatic commentedon Apr 7, 2026
@ruevs sorry about that! issues and discussions are now enabled there.
I'll take a look at 1410 too. my previous bugfix did not fix the above inside fillet example. working that now!
g19fanatic commentedon Apr 8, 2026
@ruevs
works for both chamfers and fillets!
Still have more to do though