PR #3456 - Adding chamfer angle field to PartDesign

[wmayer]

The common vertex of edges 7 and 12 of a box are the both end points. This means when chamfering with two distances then for the commonly shared face for one edge the long and for the other edge the short distance is applied.

This is an issue that cannot be solved in general. The only option is to extend the PD chamfer tool and allow to set two distances for each edge individually. Then the user can set long distance + short distance for edge 7 and short distance + long distance for edge 12.

[uwestoehr]

The common vertex of edges 7 and 12 of a box are the both end points. This means when chamfering with two distances then for the commonly shared face for one edge the long and for the other edge the short distance is applied.

I see. I thought, however, then when selecting a face, the situation is better. But also then I get this:

chamfered face

FreeCAD_lMvyFH9eQw.png (31.36 KiB) Viewed 2446 times

This is an issue that cannot be solved in general. The only option is to extend the PD chamfer tool and allow to set two distances for each edge individually. Then the user can set long distance + short distance for edge 7 and short distance + long distance for edge 12.

I don't think this is doable. In my real-life documents I often have chamfers for several 10 edges.
Therefore I now add 2 chamfer features, each with the direction I want. This works, but it is not clear in advance what edge will get what long/short distance.

[wmayer]

I don't think this is doable. In my real-life documents I often have chamfers for several 10 edges.
Therefore I now add 2 chamfer features, each with the direction I want. This works, but it is not clear in advance what edge will get what long/short distance.

The Part chamfer supports exactly this. At the bottom there are two spin boxes that set the distances of all selected edges but for each edge you can still set a different value.

[adrianinsaval]

that would be nice to have, what would be the best approach to keep it compatible? I'm interested because I would like to make the fillet feature support variable radious and make it able to set per edge too.

[wmayer]

that would be nice to have, what would be the best approach to keep it compatible? I'm interested because I would like to make the fillet feature support variable radious and make it able to set per edge too.

What I can imagine is when double-clicking on an edge item in the list view a dialog comes up where you have the same options like in the task panel (i.e. switch between the different modes).

However, we then need a new property list class that stores the information for each edge.

[adrianinsaval]

I was thinking about a tickbox to choose to set it per edge then the controls would apply to whatever edge is selected in the list. Or maybe a QTableWidget with columns for the different radious/distance/angle. With one those we don't need a popup.
Anyway, I was asking about to how to manage the properties:
Should the old properties be replaced with lists with the same name? Would that make it incompatible with previous version?
Would we need a propertyList of edges? What is the best method to reference the corresponding edge with the corresponding values? Part workbench stores it as a list of tuples in the form (edge#, dsistance1, distance2)
Should we take into account the upcoming toponaming algorithm? How?

[uwestoehr]

The Part chamfer supports exactly this. At the bottom there are two spin boxes that set the distances of all selected edges but for each edge you can still set a different value.

I know and I don't like this dialog layout much.

What I can imagine is when double-clicking on an edge item in the list view a dialog comes up where you have the same options like in the task panel (i.e. switch between the different modes).

That's a good idea.

However, let's come to an end with new features. Last weekend I had a look at the Wiki file with its new features and they are already impressive. It is time to get the release done. As far as I can see there are other, more important construction works. (And implementing this idea would be fun for me.)

I feared my report would cause new actions despite I advertise here since a while to the get the 0.19 release done. So shame on me. I put this issue now on my todo list but won't touch it before 0.19 is out.

[chrisb]

I am all for postponing further development to after 0.19.

The idea of the Part chamfer dialog seems to be "one chamfer operation for the whole object", with all their different lengths or even not including edges at all.
The current idea of the PartDesign chamfer is "one chamfer operation for one size" which now should be extended to "one set of sizes". A possibility to keep the latter, but provide a user decision for the direction of of asymmetric chamfers could be an additional "reversed" flag for each edge (a better name should still be found).

[wmayer]

Should the old properties be replaced with lists with the same name?

No, that would be a nightmare to support. Things only work if all property lists have the same size but this cannot be guaranteed under all circumstances, e.g. for undo/redo. If we have a new property list type where for each element we define mode, size and size2 it's always well-defined.

Would that make it incompatible with previous version?

When using an old version to load a file created with a new version it will simply ignore the new property.

Loading an old file with the new version can be easily supported.

Would we need a propertyList of edges? What is the best method to reference the corresponding edge with the corresponding values? Part workbench stores it as a list of tuples in the form (edge#, dsistance1, distance2)

For the Part chamfer/fillet feature I once implemented the class PropertyFilletEdges. Something like this I would suggest for PD as well.

Should we take into account the upcoming toponaming algorithm? How?

I would ignore this for now as I don't know how the solution will look like.

I am all for postponing further development to after 0.19.

+1