AutoFillet should ignore edges where faces have tangential continuity

[relikd]

Auto-fillet selects all edges which are perpendicular to the chosen direction. Instead, the script should ignore edges which are tangent to their neighbors. E.g. in the example below, the script also adds a fillet to the circle. This issue happens everywhere, e.g. rounded rects and on already fillet-ed edges.

[Rahix]

Hi,

yes, currently we do not analyze the edges beyond their direction. This works well enough because even though those edges with surface continuity are included, the fillet operation ignores them.

Since the AutoFillet command is mainly meant for quick modelling rather then precision design, it wasn't a priority so far to be more smart about this.

But if anyone wants to contribute code to filter edges with continuous faces, I'm happy to accept a PR :)

[relikd]

I'll look at it once I have spare time. But "the fillet operation ignores them" is incorrect. They are still applied but you wont see any change because the existing radius is likely already larger than the fillet radius. Yet, it will still become a problem if two of those edges are closer than 1mm apart. The whole fillet operation will fail and you would need to look through all edges, incl. those useless ones. In those few times I tried this feature, I ended up selecting all edges from scratch.

Another question: are there any design decision to consider? For example, I love the fact that FFD creates plugin-independent models. ... is there also a hard requirement to not use extenal geometry? I've seen that counterbore holes are referenced extensively with dimensions and would like to simplify that (if allowed).

[Rahix]

Yet, it will still become a problem if two of those edges are closer than 1mm apart. The whole fillet operation will fail and you would need to look through all edges, incl. those useless ones.

Hmm, I cannot reproduce this. This works fine for me:

Can you share an example where it fails?

are there any design decision to consider? For example, I love the fact that FFD creates plugin-independent models

Yes, at least for now the goal is to keep relying only on base FreeCAD features.

is there also a hard requirement to not use extenal geometry? I've seen that counterbore holes are referenced extensively with dimensions and would like to simplify that (if allowed).

For example the AutoFillet command does reference geometry already (because there really isn't another way here).

But whereever possible, I want to try really hard to avoid that. Yes, with latest FreeCAD things got more stable but you still won't have super robust models when you rely on geometry. And ideally the features generated by FFD should be built such that they can be used without worry in highly parametric designs.

What would be the advantage of referencing geometry over the current approach?

[relikd]

Sure, here you go: sample.FCStd.zip

I just threw together two rounded-rects and a circle. In theory, no edges would need fillets here.

What would be the advantage of referencing geometry over the current approach?

Mostly a cleaner editing view. If I open the sketch I get bombarded with references (which may reduce editability, or at least willingness to do so).

But thats why I ask if the referencing is also a design requirement. I could still improve the current state, without relying on external references. For example, instead of constraining the sides of the rect, we could change it to a center point and construct the rect around it. I havent tried, but I assume the lengths would be cleaner. Also, I'd use equal constraints within the same sketch if possible. But these were just a few thoughts, idk if there are other reasons why it is the way it is.

[Rahix]

The design of the constraints in the generated sketches is very deliberate. When referenced locations/dimensions change, the sketches will be re-solved. This can lead to the solver finding flipped solutions with totally different shape. We need to avoid this by designing the constraints such that only the correct solution is possible.

The other option here is to design the sketches at the origin and then use a load of shapebinders to place them in the appropriate locations. This also blows up the feature tree quite a bit so it is not much better.

Mostly a cleaner editing view. If I open the sketch I get bombarded with references (which may reduce editability, or at least willingness to do so).

At least in my eyes, the generated sketches are not meant to be edited. If you need something custom, you are better off designing the feature entirely on your own.

[Rahix]

Sure, here you go: sample.FCStd.zip

I just threw together two rounded-rects and a circle. In theory, no edges would need fillets here.

The fillet in your sample file just fails because no edges remain to apply the fillet to. As soon as you add a sharp corner (e.g. a second rectangle cutout without rounded corners), it works as intended.

[relikd]

The design of the constraints in the generated sketches is very deliberate.

Perfectly fine, thats why I asked. And I am more than happy if the current solution is more robust in terms of re-calculating the shape. Thank you.

The fillet in your sample file just fails because no edges remain to apply the fillet to.

Indeed it does. Thank you for showing that those edges are ignored. Here is the same example with a more intricate cutout: sample.FCStd.zip

The operation will fail because two of the edges are too close together. Normal FC behaviour. But contrary to the normal workflow, I do not get to see a live preview of the changes and instead the part disappear completely (with an error message). If I open the Fillet operation, I see a very long list of edges even though only 6 edges are relevant in this case. This makes finding the culprit very hard because there could be edges very close together, yet they are ignored if the edges are tangential to each other.

[Rahix]

Hope I did not come across as doubting your point! Thanks for raising the discussion :)

You are totally right, the user experience of AutoFillet is worse then PartDesign_Fillet when edges are included that break, since we don't have the nice preview. And indeed, this would be better if we would only select relevant edges so you at least have to work through less to find the problematic ones.

I played with it a bit, but it seems the PartDesign_Fillet we generate unfortunately doesn't lend itself to debugging broken edges after it already attempted recomputing. I'd have hoped we can somehow trigger the broken edge preview again, but it seems not.

So only selecting edges without tangential continuity as a first measure seems very sensible to me, too.