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.

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.

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 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 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.

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.

@jwesthues if we do 3 parents I think it may be a good idea to sort the parent IDs prior to using in the key. For example, an intersection curve may be clipped at another surface to create a point. We could say the point has a curve and a surface as parents, but there will likely be more curves ending at that point. Only by using the 3 surfaces and being independent of their order will we identify it as the same point. OTOH there can always be more surfaces meeting at a given point so I'm not sure where this ends.

@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.

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 - any chance you could post the video (of creating the cube) somewhere?