Excellent. This works quite well for the common case where the base surfaces have good tangency.
As I assume you know, it has problems when it run into a fillet surface with the same size radius. In your video it all works as long as your asked for radius went up to 1.9mm, but if you had pushed it to 2mm it would fail. When the fillet string encounters a same size radius it either fails or when it does make a surface the surface is not tangent to the base surface and also not tangent to the adjoining surfaces.
Another problem is when the base surfaces are not quite tangent. When the base surfaces are not precisely tangent it does not play nice with the extend and trim options. It will make the correct fillets, but turning on the extend option makes a mess. And trimming isn’t going to work without extending the end fillets.
Here is an example file. Try making fillets with radius of .125" :
[Fillet_breaks.3dm|attachment](upload:// Fillet_breaks.3dm (545.2 KB)
In the above file if you turn on the layer named “corrected” you will find .125" fillets with end gaps fixed which will make extending and trimming work.
@Gijs
would be nice to split the topic to separate @jim s great work from @menno s Wip / V9 -Development.
here is a (ugly) - but simple edge case, a simple extrusion, where the filletSrf fails because the in initial picked surface is no longer part of the (expected) result…
I know its a special case… but if it is not fixed now it will become a bug report after V9 is released
If I was a fresh-faced person new to Rhino, I’d think that surface contiguity should be handled by adjacency cases. Especially in the cases where the surfaces share both identical edge definitions.
Perhaps this is some form of thing that should be optionally handled by some form of graph-like connectivity definition behind a GUI switch.
i try to mimic the behaviour / expectations of my students and clients - and i would love to get fillets more robust.
And if i combine 2 infos:
the slider allows you to search a visually nice Radius
filletSrf will “swap over to” tangent neighbours
i would expect above example to work.
especially if i search a radius, that is close to some (one or two) surfaces might need to be skipped…
i would expect the new algorithm to figure out the correct portion of a set of joined tangent surfaces - that s the promise.
ok - and - to make it more a buggy special case - and many bug s are special cases:
The new tools are more than fine, but they should work not only in simple cases, but in more complex ones, otherwise they remain only half-hearted, “lame” commands. The road is well traced, but still long (for example, a command that works with radius 1, but as soon as you enter 1.1 it no longer works, it has no reason to exist).