Sorry, I am new to Rhino but I have a question about the accuracy of extrusions in Rhino. For example, I have a circle with a radius of 12 inch which makes out to 75.3982236861550377… inch length. I wrote a quick Python script that measured the floating point length and got 75.3982236861550 which corresponds to the 15 digits. I then used the ExtrudeCrv + Cap commands to make a cylinder. Then to test the radius I extracted the curves using ExtractWireframe then measured the the 12 inch radius circle again. But this time, the number was only accurate up to 8 digits and the rest was just totally off. Can anyone explain why this happens and how I can correct this?
I think this White Paper on tolerances will help your understanding:
https://wiki.mcneel.com/rhino/faqtolerances
1 Like
I thought that might the issue. However, I changed the tolerance to be lower that the default. I first tried 0.0 and 1.0x10^16 and nothing changed.
Changing the tolerance to very small, unrealistic values will have other unintended consequences.
Personally, I would never set Inches smaller than 0.00001 or mm smaller than 0.0001
Do you need to correct at all, at that level of precision? Eight decimal places gets you to the level of 10 billionths of an inch. (1 x 10^-8 inches). A high-precision machinist might be working in micrometres (about 4 x 10^-5 inches)- roughly three orders of magnitude less accurate than your 8th decimal place.
Well I do want to be able to convert between units and scaling introduces rounding errors and such. I also just an curious if modelling to such precision is possible in Rhino. There isn’t a great practical application.
1 Like
So would that mean extruding curves to the highest precision a double floating point value will allow is not possible? Maybe there is a coding solution?
@Joe_Garcia
What problem are you trying to solve?
Well the idea is just to get a model in Rhino to be represented in the highest precision it could represent. Meaning 15 digits right?
Can you give us an example file here so we can see what’s actually going on? We’re talking about the accuracy of calculating the length of a circle?
Yeah I can give that a go. Be aware you will need to go past Rhino’s display options because they only allow so many decimal places. I made a script but unfortunately I can’t share it at the moment.
I don’t think the Absolute tolerance setting has any effect on ExtrudeCrv.
Circle with radius 12
ExtrudeCrv the circle
ExtractWireframe
Delete all parts of the wireframe other than the edge which coincides with the input circle
SelDup selects the wireframe circle as duplicate of the input circle
List for the two circles shows values for the two circles are identical to 16 decimal digits
My guess is the difference in length from the Python script is created in the Python script.
Yeah, the tolerance settings are not going to change the accuracy of the radius of a curve.
We need to see an example of what “problem” you are actually seeing and trying to solve. You’re completely misunderstanding how Rhino’s tolerance options work, and the limitations of double-precision math.
Oh that’s interesting, I’ll give that a shot and let you know. Also I won’t be able to recreate the issue because I was using Rhino on my home computer and the best I can do on my MacBook might not be the same, but I’ll upload the work file once I am back home if I can’t get it resolved.
I’m not sure where you are getting at? I was able to get a circle with the proper arc length up to 15 digits. All I want is for that same precision to extend to solids once I extrude them. If the tolerance doesn’t affect geometry, then what does it do. That faq mentioned it did have effect on some specific operations.
For operations where an “exact” representation using NURBS is possible Rhino works to double floating point precisions, ie 15 to 17 decimal digits. The creation and extrusion of a circle to a cylinder is an example of where an “exact” representation is possible.
However for many operations such as intersecting two arbitrary shaped surfaces an “exact” mathematical representation using NURBS is not possible. (An exact representation may not be possible using any of the thousands of standard functions.) Rhino then generates an approximate solution with accuracy better than the absolute tolerance setting. There is a tradeoff between complexity (number of control points) and deviation from the exact solution. This is not the situation with the creation and extrusion of circle to a curve.
1 Like
The tolerance settings only come into play with things that are inherently imprecise, like trimming and joining.
Your concern about the arc length of a circle to 15 digits makes no sense at all, unless you’re building a Dyson sphere. You’re at the limits of floating-point math on a computer, a “15 digit number” is just gonna be noise, differences are just due to rounding errors converting between base 2 and base 10, or similar minutiae.
Thanks for the write up. That was my assumption. I also tried your process you said earlier on my MacBook but noticed that the length only goes as far as 75.3982 regardless of changing the settings. Not sure if it’s different on the Windows version which I have been using.
While I appreciate your concern I am doing this as more of an experiment because these errors will pile on. Even if it only affects only the 8th decimal place, scaling to other units does make these issues more apparent. I just want the assurance and peace of mind that my model is as precise as the computer will allow. I understand certain complex operations introduce limitations which I am fine with, but I don’t think a cylinder is one of those special cases.