make chamfers as easy as fillets

Right now, it is easy to draw a basic geometry that represents the core function of a piece, and then add fillets for strength, looks, etc., using tangent arcs. For chamfers, there doesn't seem to be an easy way to do the same, i.e., to rapidly apply them as refinements. It would be nice if such a function could be added.

A simple work around is to create a tangent arc, change the arc to a construction line, then make a segment connecting the points at the ends of the arc. This will form a chamfer of sorts. It's not clear to me how the distance from the original corner should behave but constraints could be added.

A couple of years ago I was also commenting on this somewhere, probably the Solvespace forum. It's one of the main reasons I was forced to used FreeCAD. When a 2D profile is created in a plane, then 'sharp' corners can be avoided in a number of ways. But very often, after performing an extrusion, which is a frequent operation in Solvespace, you now have a 3D object with some rounded\chamfered edges in the direction of the extrusion, and some 'sharp' edges on the front and back faces. Consider how to create a dice with every edge and corner rounded off.

Solvespace seems not to provide a 'natural' way to apply a chamfer/fillet to an arbitrary edge. What I want to be able to do is to select a 3D edge ( not a vertex or a 2D entity ), and have a syntax for applying a chamfer or fillet to that edge. The only workaround I have come up with is to create a special shape corresponding to each edge to be rounded, and perform boolean operations to add/remove the necessary material. This is feasible for simple things like the dice, but generally too much work.

For my purposes, because I'm often creating things that have to be held or manipulated and sharp edges are not appreciated, having the ability to do this would significantly enhance the usefulness of Solvespace.

Everyone agrees with this :-) It is just hard to implement in SolveSpace.

@mderouss

The original open issue here appears to want a 2D chamfer similar to the rounded corner tool. That's completely possible - someone just has to implement it.

@mderouss A general purpose chamfer or fillet tool that can be applied to any edge is often requested but not planned. SolveSpace does not currently allow doing any operations on the 3D model other than boolean operations. However I am hoping to add the ability to add a Fillet or Chamfer to either end of an extrusion for version 4.0. that will probably cover 80-90 percent of the cases where people need it. You can see a picture of early concept here: #453 (comment) Oh right, that also say I was working on draft angles.

As for dice with rounded edges, SolveSpace 3.0 can do that with a little effort. No differences or intersections are used in the creation of this sketch:
rounded_cube.zip

You can resize the entire cube and the radius by dragging the base-sketch points that are still visible in the final group. There seems to be a NURBS issue showing up depending on the radius @ruevs might want to see ;-)

BTW I made a 10 minute video (real time) of creating that cube but have not decided to start a YouTube and post it.

Thanks for the quick and through responses ! The cube is very helpful. I have some time on my hands, and 30+ years of C++ experience, so I've started to nose around in the codebase in case I feel like solving my own problems :). But I strongly suspect my almost complete lack of 3D modelling experience will prove the limiting factor there.

…

On Sun, Dec 6, 2020 at 11:22 PM phkahler ***@***.***> wrote: The original open issue here appears to want a 2D chamfer similar to the rounded corner tool. That's completely possible - someone just has to implement it. @mderouss <https://github.com/mderouss> A general purpose chamfer or fillet tool that can be applied to any edge is often requested but not planned. SolveSpace does not currently allow doing any operations on the 3D model other than boolean operations. However I am hoping to add the ability to add a Fillet or Chamfer to either end of an extrusion for version 4.0. that will probably cover 80-90 percent of the cases where people need it. You can see a picture of early concept here: #453 (comment) <#453 (comment)> Oh right, that also say I was working on draft angles. As for dice with rounded edges, SolveSpace 3.0 can do that with a little effort. No differences or intersections are used in the creation of this sketch: rounded_cube.zip <https://github.com/solvespace/solvespace/files/5649717/rounded_cube.zip> [image: rounded_cube] <https://user-images.githubusercontent.com/14852918/101295896-4e47bb00-37ee-11eb-86b9-01bc6fee8d96.png> You can resize the entire cube and the radius by dragging the base-sketch points that are still visible in the final group. There seems to be a NURBS issue showing up depending on the radius @ruevs <https://github.com/ruevs> might want to see ;-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#149 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AILEP2VBDWK5ONFFIXZXACDSTQG2XANCNFSM4C3W3ZHA> .

Is it at all possible to create fillets for a body like a chopped of pyramid (like a cube but without the constrain that all angles between the adjacent surfaces are 90 degrees)?

You could sketch one face of the cube with sloped sides and extrude that. Then set up a workplane 90 degrees from that to draw the slopes for the other 2 sides. Extrude the second sketch as intersection or difference depending how you draw it. This should produce what you want.

There should be more construction tools in the future to allow this to be done in fewer steps.

However I am hoping to add the ability to add a Fillet or Chamfer to either end of an extrusion for version 4.0. that will probably cover 80-90 percent of the cases where people need it. You can see a picture of early concept here: #453 (comment) Oh right, that also say I was working on draft angles.

I agree that this would 80-90 of the cases, especially for 3D printing where you want to strengthen edges by fillets. Definitely looking forward to seeing this working in SolveSpace. And thanks for such a great project!

Chamfering should exist as a modifier, not a real modification model. Like Blender's modifier, we can then hide the modifier and show the modifier. Modifiers are applied only when the model is exported, so this has no effect on the assembly.

@jwesthues

@jwesthues When new sketch entities are created by making an extrusion, they get put in the remap table correct? So we may do a REMAP_POINT_TO_LINE or REMAP_LINE_TO_FACE which allows the new entities to be used in constraints even after doing regeneration. Would it be possible to do a remap where something is based on two parents? I'm thinking of edges formed by intersection of faces in booleans. If we could at least tag them with a consistent ID based on where they came from it might help with being able to select edges for the fillet/chamfer stuff. Does that make sense?

@phkahler

@phkahler That makes sense, and the ability to generate sketch entities from solid model edges would be valuable even independently of the chamfer feature discussed here, for example to permit constraining against new edges created by the Booleans. The current struct EntityKey contains just one parent entity, plus the integer copy number. The copy number is used in the obvious way for step and repeats, and also with special values like REMAP_PT_TO_LINE for extrusions.

To support multiple parents, you could add more entities (I guess two more entities, to support points from three surfaces?) to that struct, and modify the file format to save those. It would also be possible to support multiple parents without changing that data structure (e.g., by repurposing copyNumber, or by taking a hash over all the parents, risking collisions with nonzero but very low probability), but uglier.

@phkahler

@phkahler That makes sense. In cases where more than three surfaces intersect, I believe it would be reasonable e.g. to take the three surfaces with the lowest handles (or any other stable set of three), and ignore the others. That would behave consistently as long as the topology doesn't change, and when the topology changes there's no clear correct behavior anyways.

Note that faces don't currently all get Entitys, just planes. So your first step might be to assign those, which is mostly straightforward except in Booleans between shells with coincident surfaces (which should get merged; though lots of coincident-surface cases are of course already broken differently).

For anyone following along, the last few comments here are related to what FreeCAD calls the Topoligical Naming Problem

SolveSpace is very good at handling those issues, but also somewhat limited. We do not currently create a sketch entity where boolean operations create new edges (intersection of planes for example). What you see is edges of the solid model which can not be constrained against. In order to have a general fillet or chamfer tool the user needs to be able to select which edges to apply the change to, but you can't actually select any edges on the solid model - only sketch entities which are often (but not always) created in addition to the solid model. To see the difference, hide the solid for a group, try this for a revolve group as well.

When extruding a sketch, new entities are created in the 3D group. These are tracked by an internal "remap" mechanism to identify "where they came from". A point in the sketch becomes a line in an extrusion for example, or a line in the sketch becomes a face in the extrusion. Those new features use the "remap" functionality to create their handle (programmer speak for ID). We might say to remap point123 to line and the remap function returns the handle for the line. When a sketch is regenerated (due to changes in previous groups) the remap function is given the same handle from point123 and will return the same entitiy ID for the line regardless of any other changes. Constraints in subsequent groups use these IDs, so this mechanism prevent constraints from braking when things are moved around and regenerated.

My point 4 comments up is that when faces intersect in a boolean operation, a new line is created. It's "parent" is... well it has 2 parents - the two faces - so we should modify the remap mechanism to allow 2 parents. As JW points out the end of one of these edges is a point which my have 3 parents.

The bottom line is that topology is hard, and tracking geometric elements that are created - sometimes incidentally - by boolean operations can be a very hard problem to address. SolveSpace is very good at it because it doesn't actually handle some of the harder cases at all (yet).

Getting back to chamfers. There are two problems. One is to allow the selection of arbitrary edges, the other is to create the new geometry. We need the first before being able to do the second. That is unless we take a shortcut as suggested by this comment But that has limitations as well.

:) Yes, following along. Thanks for the summary. But I think @jwesthues kind - of nailed it three years ago when he noted : Commercial CAD tools general have "draft" and "round/chamfer" as separate

tools that work on surfaces, not properties of the initial extrusion. I suspect that may be what you really want here, like as separate "draft" and "round/chamfer" groups acting on the existing solid model. That's a huge amount of work to implement completely

So what I think I understand is that boolean operations create 'implicit' edges which are not included in the internal model. Those edges may be 'reverse engineered' from the solid model, but they have characteristics which are not catered for by a particular internal representation used for constraint management. Extending that representation may allow constraint management to function correctly with these edges. But the question that pops into my mind here, being ignorant of the way the code actually works, is this - an implicitly created edge is never going to have a user-supplied constraint attached to it, so although it does need to be selectable does it actually need to take part in the 'internal "remap" mechanism' ?

…

On Mon, May 2, 2022 at 6:59 PM Paul Kahler ***@***.***> wrote: For anyone following along, the last few comments here are related to what FreeCAD calls the Topoligical Naming Problem <https://wiki.freecad.org/Topological_naming_problemurl> SolveSpace is very good at handling those issues, but also somewhat limited. We do not currently create a sketch entity where boolean operations create new edges (intersection of planes for example). What you see is edges of the solid model which can not be constrained against. In order to have a general fillet or chamfer tool the user needs to be able to select which edges to apply the change to, but you can't actually select any edges on the solid model - only sketch entities which are often (but not always) created in addition to the solid model. To see the difference, hide the solid for a group, try this for a revolve group as well. When extruding a sketch, new entities are created in the 3D group. These are tracked by an internal "remap" mechanism to identify "where they came from". A point in the sketch becomes a line in an extrusion for example, or a line in the sketch becomes a face in the extrusion. Those new features use the "remap" functionality to create their handle (programmer speak for ID). We might say to remap point123 to line and the remap function returns the handle for the line. When a sketch is regenerated (due to changes in previous groups) the remap function is given the same handle from point123 and will return the same entitiy ID for the line regardless of any other changes. Constraints in subsequent groups use these IDs, so this mechanism prevent constraints from braking when things are moved around and regenerated. My point 4 comments up is that when faces intersect in a boolean operation, a new line is created. It's "parent" is... well it has 2 parents - the two faces - so we should modify the remap mechanism to allow 2 parents. As JW points out the end of one of these edges is a point which my have 3 parents. The bottom line is that topology is hard, and tracking geometric elements that are created - sometimes incidentally - by boolean operations can be a very hard problem to address. SolveSpace is very good at it because it doesn't actually handle some of the harder cases at all (yet). Getting back to chamfers. There are two problems. One is to allow the selection of arbitrary edges, the other is to create the new geometry. We need the first before being able to do the second. That is unless we take a shortcut as suggested by this comment <#453 (comment)> But that has limitations as well. — Reply to this email directly, view it on GitHub <#149 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AILEP2UYHRQCPFEOOYP53QDVIAJWNANCNFSM4C3W3ZHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

@mderouss

an implicitly created edge is never going to have a user-supplied constraint attached to it, so although it does need to be selectable does it actually need to take part in the 'internal "remap" mechanism' ?

@mderouss There are definitely times when it would be good to constrain against implicitly (or incidentally) created edges.

Anything that the user can select must have a valid handle (ID) as that is the only way the operations can be repeated during regeneration. Regeneration essentially replays all user operations starting from some past point in the construction tree. When you modify an earlier sketch to change or add features, and then subsequent groups all change, they are actually discarded and regenerated. That means any sketch entity used in a constraint or other operation has to have its handle stored along with the request to do the operation. Without a proper identifier it cannot regenerate.

It's not sufficient to assign new or random IDs either. If you extrude a sketch of a triangle, you get some prism in 3d. suppose you then make a sketch on one of the new side faces and do some other things. Then you go back to the underlying sketch and make it a pentagon instead. Everything you kept in the underlying sketch, and everything built on those elements will be able to keep their IDs because 1) each line was created by a specific user request and 2) each new element in the extrude group "came from" some specific element in the sketch. During regeneration, point 3 will be extended to a line for example. The remap function takes "point3, pt-to-line" and returns a new handle (ID) for the line. If no such handle exists - the first time its created - an arbitrary one is assigned, but if "point3, pt-to-line" already exists, the previously chosen handle is reused for the regenerated entity.

Suppose you make an extrusion and then select some arbitrary edge with the mouse and make a fillet. Now you go back and modify the underlying sketch. The 3d model is regenerated and Solvespace goes to apply the fillet operation... To which edge? The one the user selected with a mouse? We threw out the old model and regenerated it, so which edge would that be? The only way to know is with the remap function, which can be used to identify "the edge created when point3 was extruded to a line". Or more specifically it allows us to reassign the same handle for a regenerated line created by the same operation.

I hope that clarifies things a little more.

We can add chamfers. After modifying the sketch, the chamfer is automatically reapplied if the chamfered edge can be identified. If the beveled edge cannot be identified, discard the bevel, let the user reselect the edge, and re-bevel manually

You can use Boolean operations to achieve the chamfer effect, but it is very troublesome. If the code implementation of chamfering is also very troublesome, can you do some automated encapsulation of chamfering implemented in Boolean? On the surface it's a chamfered button, but underneath it's still Boolean.

@phkahler

@phkahler - any chance you could post the video (of creating the cube) somewhere?

I'm kind of hoping this is solvable with some kind of macro to create supporting geometry - so far the lack of easy fillets and chamfers is the one thing keeping me from using this for anything but the simplest parts.

FYI, I moved on to dune3d. It has a similar workflow to solvespace, uses even solvespace's solver but utilizes the OpenCascade CAD kernel that FreeCAD also happens to use. It does chamfering, and fillets.

So, is anyone feeling brave enough to pick this up during the days off? With a bit of AI help, it could be a pretty fun challenge.

Believe me, if it could be done by AI alone it would be done by now. It requires quite a lot more forethought and edge case handling than current models can handle.

Believe me, if it could be done by AI alone it would be done by now. It requires quite a lot more forethought and edge case handling than current models can handle.

I understood that, but I couldn't resist provoking a little. ;-)

The best provocation would be when you just do it ;-)

Navigation Menu

Repository navigation

make chamfers as easy as fillets #149

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

📋 Server Request & Proxy Logs

⚙️ Pengaturan Proxy Target

make chamfers as easy as fillets #149

Description

Activity

phkahler commented on Apr 9, 2019

mderouss commented on Dec 6, 2020

ruevs commented on Dec 6, 2020

phkahler commented on Dec 6, 2020

mderouss commented on Dec 8, 2020

wucke13 commented on Aug 25, 2021

phkahler commented on Aug 25, 2021

nanoant commented on Aug 31, 2021

yueduz commented on Apr 28, 2022

phkahler commented on Apr 28, 2022

jwesthues commented on Apr 29, 2022

1 remaining item

jwesthues commented on Apr 30, 2022

phkahler commented on May 2, 2022

mderouss commented on Oct 11, 2022

phkahler commented on Oct 11, 2022

yueduz commented on Dec 7, 2022

yueduz commented on Nov 28, 2023

silverdr commented on Jan 14, 2024

rcarmo commented on Apr 23, 2025

wucke13 commented on Apr 23, 2025

dodox1 commented on Dec 28, 2025

rcarmo commented on Dec 28, 2025

dodox1 commented on Dec 29, 2025

mkyral commented on Jan 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions