This is quite a simple model with a generous tolerance, and yet simple FilletEdge generates gaps:
The left was set at 10 and the right was set to 13.5. Why did Rhino have trouble with this?
edge-blend-gaps.3dm (604.3 KB)
Tolerances need to be TIGHT for FilletEdge to work most reliably, not “generous.” I rebuilt the one end with 0.001mm/0.1 degree tolerances and the 10mm fillet worked fine.
1 Like
That’s interesting. Is that the official stance of McNeel as well, I wonder?
you can also query your objects with
_what
command
already before fillet there are edges that are beyond tolerance
Edge Tolerances: 0.000 to 0.021
median = 0.000 average = 0.002
Vertex Tolerances: 0.000 to 0.010
median = 0.000 average = 0.001
so the edges already are not precise.
and also you have those nearly co-planar faces:
(would make sense to avoid)
so they vary 0.4 Degree, but your documents angle tolerance set to 0.5
also be aware, that those 4-surface - corners are problematic regarding a precise geometry:
it s not said, that you always (for all combinations of angles) get a precise point where the fillets meet.
your 180mm long Object is for sure a “small objects mm”
because of above detail ( 180.4 degree) you may set 0.1 degree or even less.
in general it s a good idea not to change document tolerances.
if you change them - make the tolerance rougher / higher values.
best / most precise solution would be, to build the initial polysurface again and make sure, it fits the 0.001 tolerance (edges / vertices)
Hello- offsets and intersections (big parts of filleting and trimming etc) are more accurate at smaller tolerances. In general Rhino is happiest if 0.01 units >= tolerance >= 0.000001 units. In general try to keep tolerance at least 10x smallwer than the smallest ‘features’ on the model - skinny faces etc.
https://wiki.mcneel.com/rhino/faqtolerances
-Pascal
2 Likes
Rhino always struggled with fillets. I wonder whether Rhino 8 ShrinkWrap command can be modified to solve this problem. The ShrinkWrap command seems to be useful because it never fails to fill holes. The fillets made by the modified ShrinkWrap command may not be perfectly cylindrical, but who cares about perfection?
Thanks for the What command tip!
However, at the other end of the model where the fillet fails on the entire edge, the surface reports this:
Edge Tally:
6 boundary edges
Edge Tolerances: 0.000 to 0.002
Edge Tally:
4 boundary edges
Edge Tolerances: 0.000 to 0.008
Also:
But yes, if I unstitch the top from the bottom (bottom being where you found the “problem”), the fillet works, so are you saying that if there’s a tolerance problem in one end of the model, a Rhino fillet can fail at the opposite side?
Ok, that is the file tolerance. But I noticed one thing now:
The fillet actually IS within tolerance! It’s just that the diagnostic (note the purple highlight) reports it as out of tolerance… but if I explode the object and then join everything again, it goes away. So is it actually just the ShowEdges command that doesn’t understand what the current file tolerance is, or is it the implicit join that happens in FilletEdge that misses it?
For this very reason I suggest the following request:
1 Like
i am quite sure, it is a geometrical problem.
it s one of those 4 surface corners, filletedge is doing hard to solve.
i showed the problem already in my first post:
for the given geometry it looks like this:
the fast impression / expectation is, that the 3 red lines / edges meet in one point (x)
but zoomed in they form a triangle, the marked (<->) distance is 0.017 mm
somehow filletedge is a “instant meal” that is doing some cheating under the hood…
but fails and comes up with this nice hole:
(zoomed in from initial posted file:)
at least it would be great, if filletEdge could detect / feedback those issues and tell the user to improve them, maybe marked with a dot ( like Booleans sometimes do)
in this case, the detail is 0.017mm so the document tolerance should be 0.001mm as already pointed out above. - then filletEdge will do the job.
I must admit that I ended up filleting it in a different CAD package, and it didn’t exhibit any of the issues you point out…
I mean it’s a super simple model. I’d expect it to “just work”.
Of course your screenshot doesn’t tell us if it actually did a better job or just mushed everything together with questionable tolerances.
2 Likes
Hello - the input object does have a number of edges that are out of tolerance, and this is a fairly fat tolerance -
Edge Tolerances: 0.000 to 0.021 <<<<<<<<<<<<<<
median = 0.000 average = 0.002
Vertex Tolerances: 0.000 to 0.010
median = 0.000 average = 0.001
my guess is the problem lies there, most likely. I’d build this at .001 with all edges staying within tolerance.
in addition, though I do not think this is the problem here, just fyi, this face:
is trimmed from a very much larger underyling surface
The grim truth is, Rhino often behaves better where the trimmed face and the underlying surface do not differ too much. Hm- that is one of the faces with out of tolerance edges.
Also, just fyi. the open side is not quite planar.
-Pascal
As was already stated in this thread, filleting with a smaller tolerance is a solution.
rhinopython/spb_Brep_createFilletEdges.py at master · CADacombs/rhinopython · GitHub ,
which uses RhinoCommon’s Brep.CreateFilletEdges, trials various tolerances until a solution is found or tolerance extremes are met.