the intention of this topic is to collect examples, where fillets fails. Please post screenshots and .3dm files or links to other topics.
the idea of this topic is NOT to discuss single cases - but provide a nice overview / COLLECTION of the fails…
@Joshua_Kennedy asked for this -
somehow rhino does get into struggle, if a surface is completely removed by
_filletEdge
fillet_surface_not_earsed.3dm (3.0 MB)
this is a nice challenge about filleting - and shows how complicated this is compared to other modellers (Creo, Solidworks, …)
_filletSrf / _filletEdge will fail…
(Creo / Solidwork can do it !!!)
most issues:
i really recommend this example to learn filleting and to get to know the rhino-fillet-bugs / challenges…
Yep… Many, if not most of the fillet edge failures are due to the fillet needing to end past the far edge of the face attached to the selected edge… I would say this likely falls into that category even though it is not strictly past
-Pascal
2 years later, no bugtrack, still not working
Mac os x, Version 7 (7.27.23032.13002, 2023-02-01)
already posted somewhere… can t find it.
maybe _filletEdge should check for coplanar Faces ?
(Edit:(
Result in Rhino mac Version 7 (7.27.23032.13002, 2023-02-01)
… i get a hole
That one seems fixed here…
-Pascal
a nice one from above fillet-challenge
fillet_nirvana.3dm (451.3 KB)
(EDIT)
expected result - on layer revolve … the surface is an revolve)
Mitch s second fillet Challenge from 2007
https://wiki.mcneel.com/rhino/foursrfangle
FilletEdge appears to work for this producing the same fillet for both objects unless I’m going crazy. What is it you expect to happen here? Do you want some of the new faces to merge?
I tried this model when you first posted it and FilletSrf in the WIP seemed to work more elegantly albeit maxing out around a fillet radius of 10 instead of the 15 you want. Now I’m getting strange results. I opened this issue for you.
Maybe @chuck can chime in why these Fillets are difficult
dear @Joshua_Kennedy
thanks for having a look at this.
to get the fancy result (in mac os Version 7 (7.27.23032.13002, 2023-02-01)) it is really important to click close to the dot s …
and yes i expect a revolve-like surface - also in the file - edit the post above
I do not get a nice result in Rhino-mac, V7 (see edit)
I think it would be nice, or might avoid some errors, if filletEdge would look at a version of the brep, where the coplanarfaces are merged. - without changing the typology / facedesign of the original brep - just to get the fillets rails / trims / …
Hidden in the abstract art is the correct answer, which isn’t quite as nice as the revolved surface. The other stuff is an added bonus. I guess you’d rather not have it there, and I’ll figure out what’s going wrong. If you just delete it, you’ll be left with this.
as long as you don t tag this topic with “AI”…
… but the algorithm somehow generates points far beyond anything that makes sense, no change to have some kind of test to stop it doing this ?
some kind of simple boundingbox - check at the end of the algorithm… ?
follow by some conditional clean up ?
or some user interaction … (which part do you want to keep ?)
Yeah, it shouldn’t be hard to figure out that this mess doesn’t belong. The problem is due to the edge on the left having the same radius as the fillet, which shoots rapidly up the side.
if i would have studied geometry / mathematic instead of design i would head for a paper:
“traces of spheres in foggy circumstances”. (but maybe this is more a novel…)
for fillets i always imagine a path of a sphere movement…
and as soon as the radius / curvature of the target surface is (nearly) the same (“foggy”) the trajectory should be more careful, more stable, have more inertia…
same for “pointy” fillets - that should and in one point.
sometimes i think, rhinos problematic fillets are also linked to problems of intersect, offset-Surface and Pull…
this is a nice unsolved issue:
there was another crazy example.
(Edit - i found it:)
Yes,well said.
The problem with Rhino’s pointy fillets and pull and intersect commands is that when there is a plethora of possible solutions Rhino picks the worst one instead of the best.
The best solution of course is not the solution best for Rhino developers but the one is best for the user. In other words, its not the solution that the developer can claim is correct (in this case all the possible solutions are correct), it is the solution that doesn’t sabotage the users efforts to create a sound 3d model.
So when Rhino’s Intersect command is generating a set of points that will be used to create an output curve and the algorithm arrives at an area where both surfaces are tangent (i.e. have the same surface normal direction) it should not dive for the nearest boundary. That strategy may be the easy way out for the developer, but is disastrous for the user. What the algorithm should do is pick that next point that is closest to being in a straight line with the last 2 points the algorithm generated.
The same thing applies for the pointy fillets. The problem with pointy fillets just like the intersect command is that when it gets close enough to an edge it gets sucked to that edge instead of proceeding in the direction closest to which it is currently going. If any edge is going to be involved in the algorithm then it should only be at the point where the edge of both surfaces are closest.
as soon as there is another surface close to the edge and is part of the fillet - but not part of the edge.
rhino s filletEdge Fails…
even if the the Surface is part of the
workaround of course is
to use_filletSrf
or - if possible (like here) build a single surface / split at tangents = no.
see also here
noFillet_close_to_edge.3dm (4.9 MB)
