Hi, V5
see file attached, a series of V lines…A
B. apply Fillet 0.01 one at a time
C. move result up to top line and some go beyond the line.
why ?
Surely it should be accurate and consistent in result ?
What method is more accurate ?
Fillet accuracy.3dm (59.5 KB)
Cheers
Steve
What is your file tolerance?
You’re looking at differences on the order of 0.0002 with a file tolerance of 0.001.
hi,
absolute tolerance is 0.001 units
relative tolerance 1%
Steve
You can’t expect the accuracy to be better than your file tolerance.
Relative tolerance doesn’t exist anymore in V6 and later.
If its a repeatable function surely any difference should be the same or can it enter drunken mode ?
what tolerance setting would make this match ?
Cheers
Steve
I used FilletCorners at 0.01 on the polyline and all look pretty much perfect. But I did it in V7, haven’t checked in V5. I don’t know how you made yours.
Fillet accuracy-msh-V5.3dm (1.7 MB)
Now I checked in V5, also perfect with FilletCorners.
Hi,
Maybe Fillet fails at corners, and why filletCorners is made as a command then ?
I used tan tan rad and copied it across to get the others, and won through !
Steve
FilletCorners fillets all the corners (kinks) in the selected object(s) with the same radius.
Yes you are correct. Filleting 2 planar lines should never produce inaccurate results.
And for the most part it never does, but there is something going on with your file.
I tried making the .01" fillets numerous times and was only able to get it to mess up only a couple times. If it had not happened the first time I tried i would not have tried so many times to see if it can be repeated consistently.
I’m glad you proved later in the thread that statement was incorrect.
There is no good reason why the result of filleting two line segments that are positioned exactly on the same plane should be affected by the users tolerance setting.
Do you think Rhino uses 3.1 for the value of Pi if the user tolerance is set to .1?
Do you think Rhino moves the geometry around randomly to make the accuracy match the user tolerance?
Why would Rhino intentionally introduce error into operations that can be done with precision just as easily?
It is not in this case. You can try it yourself…
First I did exactly as he indicated he did - filleted all the vertices one-by-one at 0.01 - at the existing 0.001 file tolerance. The resulting fillets varied all over the place, like his. Actually not all, just the first few from the left. I then undid all, went and changed the file tolerance to 0.0001 and redid the fillets. They were much better. In both V5 and V7.
So in this empirical experiment, with this particular case, the tolerance setting does play a role. I don’t know why FilletCorners produces a more correct, accurate result. This looks like a bug because the results should be the same and yes, in theory Rhino should calculate this kind of stuff to the maximum possible accuracy - but apparently it doesn’t and tightening the file tolerance helps.
My general rule is not to expect stuff to end up more accurate than your set file tolerance.
Edit- I went back and redid the one-by one fillet, and then exploded the result. I set the display precision as far as it could go (8 decimal places) and started measuring. All the radii were 0.0100000 inches. However the first four straight sections were:
0.0172699 inches
0.0181150 inches
0.0175904 inches
0.0175252 inches
Thereafter all the rest were 0.0175252 inches…
I had filleted from left to right in the first try, I went back and tried going from right to left. The results were different and rather more of the straight segments were not exactly the same length value.
Running FilletCorners on it instead and exploding gave me all the same line segment lengths.
A guess, and only a guess at one is happening here. First a couple of observations.
For a circular arc fillet between straight lines there is an exact, closed form solution for the center of the fillet, the angle of fillet and the starting and ending points of the fillet, which an all be calculated “exactly”.
For a circular arc fillet bewtween two general NURBS curves there is not a simple closed form solution for the fillet, and the location of the center of the fillet, etc may not be able to be calculated exactly. Instead iterative, approximate methods need to be used. Thus there may be come variation in the fillet which will be dependent on the tolerance.
It may be that FilletCrv recognizes straight lines and uses the exact solution where possible, while Fillet considers all input as general curves and uses the approximate solution.
What you are describing is called a BUG.
As I said in my previous post I also got the wonky results but only sometimes. Sometimes the result was dead nuts accurate -as it should be
There is no good reason for the file tolerance to play any role in calculating the fillet between coplanar lines.
I can export the lines to Rhino2 and it will will create the fillets accurately to 13 decimal places regardless of the tolerance setting. I can set the tolerance to 1 (100 times bigger than the fillet size) or set it to .000001 and the result is identical in Rhino2
Yes it is playing a random inconsistent role when, if things were working properly, it should play no role at all.
I’m puzzled by why you think its OK that fillet corners can get it right, but filleting individually sometimes gets it right but sometimes is off by a bunch.
In my experience Rhino usually makes fillets generally pretty dang accurate even if the inputs are curvy nurbs. I just tried with 2 curvy curves (one degree3 and one degree2) made with Curve command and the center points of the fillets were the same to 14 decimal places (according to List) with tolerance set to .01, .001 and .0001.
What’s really horrible about the example being discussed is that when it messes up the continuity is off by almost 3 degrees (according to Gcon). How can you make surfaces from curves that are off by that much?
Just to lower the blood pressure: doing Steve’s original test in the R8 Beta (without altering the tolerance settings) gives matching fillets at all the peaks.
Yes indeed it does seem to work in Rhino8.
I just tried again in Rhino7 and it made all 9 fillets flawlessly to an accuracy of 13 decimal places in Rhino7. So, I don’t know what’s going on. Sometimes it works and sometimes not.
Sorry, that was the first thing I tested yesterday and V8 does NOT fix the problem. I just did it again in the freshly installed Beta from yesterday (8.0.23285.13303, 2023-10-12) and here is the result…
Fillet accuracy.3dm (59.5 KB)
I don’t believe I ever said otherwise.
Rhino 2 was based on a completely different code stream (AGLib)…
No, it’s playing a consistent role in the sense that it seems - I haven’t tested 100 times in a row - that tightening the tolerance by one order of magnitude prevents the ‘bug’ consistently. Not arguing whether it should be like that, simply observing what actually happens.
What’s interesting to note is that this bug has been around since at least Rhino 5 and probably earlier - maybe even since V3 - and for 10+ years, maybe 20, nobody has reported it until now. So that means that it only happens in a peculiar combination of circumstances. It’s possible that most people modeling these kinds of things either used tighter tolerances, or, being how small it actually is, simply did not notice the error.
Fillet accuracy2.3dm (109.4 KB)
It seems to have to do with where you pick the curves. The closer to the points where the fillet will end you pick, the more likely it will fail. Notice the curve jumping away from the point when it fails.
In Rhino 8 it fails differently:
@Helvetosaur it looks the curves also jump, though less, when lowering the tolerance to 0.0001, when clicking close to those points
RH-77716 Filleting curve result is dependent on clicked point.
