I am trying to build a model with a tolerance of 1 mm (building).
This model is exported to a another tool for finite elements meshing and calculations.
My main concern is to make sure that two elements that should be “connected” on a point or an edge are indeed.
The model are mostly made of linear 1D and 2D plane elements (no circles or curved elements).
It shows that with a tolerance of 0.001 m, the two edges (connected at 90°) are distant from 0.0000173 m
I am wondering :
1- why is it possible to have distances lower than the tolerance (which are not an intersection) for such elements, knowing that they are perpendicular planes (could be the same question for planar cases) ?
2- is there a solution, for elements that could theoretically be in that situation (ex. the exact position of an intersection of two elements not being co-planar or perpendicular), to properly connect edged/corners of such elements within the imposed tolerance ?
Hu Bruno - Rhino is as accurate as a computer can be for exact operations - for example, setting the radius of a circle is not subject to Rhino’s file tolerance, it is as exact as it can be. Some operations cannot be exact - these are, if all goes well, done to within tolerance, So a trim or projection of a curve to an arbitrary surface is not exact, for example, and is calculated to within tolerance.
Thanks for the answer and I fully agree for a general case (2nd part of my question) and this is partly the beauty of Rhino to be so “accurate”.
However, my concern is not to improve the accuracy but in a way to reduce it.
For the point 1) of my questions
The model creates objects that (in may case) are distant by 0.0000173 m while the tolerance should only create/see (as they were made through operations in planes perpendicular or co-planar with the C-plan) distances by increments of 0.001 m given my settings.
Is this not surprising ?
I think I was not clear at least for the question 1).
The two surfaces that are shown are perpendicular to the C-plane (in this case (X,Y), and are also perpendicular (one in XZ the other in XY)
They are created with a series of operations using the vertical surfaces, objects copy/pastes/cuts/moves with the snapping and other control to keep elements connected etc.
The elements are linear segments or plane surfaces (some are not in the model but not these ones).
So, my understanding was that I was only creating objects on a grid which depends on the software tolerance/accuracy settings (0.001 in my case).
I would then not be surprised with a measured distance of 0.001 … but I am with something less and not a multiple of the tolerance.
I am surprised that, in that case, the results is not “exact” (within my settings).
The reason why it is an issue for me is that I want to avoid any useless “differences” for the mesh tools I am using (in some cases two very small distances are considered as different nodes)
So, the thing about tolerance is that it is not that a result will be in increments of the tolerance value, but rather that results will be calculated to tolerance or less. The discrepancy you show is well within tolerance. The display of the distance, if set to three places, would show you zero, or .001 depending - you can set that in DocumentProperties > Units > Display precision or in annotations styles for dimensions.
Am I making any sense, with what you are asking about?
Your understanding is not correct. Rhino does not use a “grid” for calculations. It uses double precision floating point arithmetic with the equivalent of around 16 decimal digits. Sometimes checks of distance between objects will return a result with a magnitude of 10e-15 or similar. Those discrepencies are the result of the finitie precision of the arithmetic. Larger discrepencies can be the result of accumulations of discrepencies in individual calculations or other causes.
Thanks for this precision.
And I fully understand (well I believe I understand ) the fact that for a general case, Rhino is able (and it is an advantage of course in some cases) to offer the double floats accuracy.
The reason why I am surprised is in fact because the distance I see (0.0000173 m) is lower tan the tolerance I use while obviously much higher than the double float precision. So, as indeed Rhino is very accurate, it means that this difference is “created” by the software based on a combination of the interpolation of something and the settings of my model.
The “grid” I was mentioning was just in the case of elements straight 1D (linear segments) or straight 2D (planar poly-lines or surfaces), no curve, no rotation, all created perpendicular or parallel to the C-plan.
In such a case, all the elements should, I think, follow what I was calling a “grid” with an accuracy = the tolerance imposed of the software.
If the above is right (if not I won’t bother more on this I promise ) and just to be sure to understand :
In that specific situation (everything assumed perpendicular/parallel and straight 1D/2D with a tolerance t) … are you saying that :
if I create/move an object (with no rotation), its angles/edges) at coordinate/distance X we can have an edge/corner with coordinate X1 with X1-X < t (ex X1-X = 0.0000173 m in my case with t = 0.001)?
If yes, what then is the meaning of the tolerance/accuracy settings?
or (if the answer to the above is no) : the reason why I see the issue it is because I have created at least one of the objects presenting the issue based on another object that was either not straight 1D (ex. a curved line or surface) or not perpendicular (or parallel) to the C-plane?
The object should be at the new location within the limits of decimal to binary math conversion. Integers can be represented directly in computer math which is binary based. Many decimals can not be represented exactly in binary with a finite number of digits. This is similar to not being able to represent 1/3 exactly with a finite number of decimal digits. These errors should be the order of 10e-16 or similar. If the object is very large or very far from the origin the errors can be larger.
Curved objects and moving in non-parallel directions by themselves do not introduce larger errors larger than the order of 10e-16 . (Provided not a long distance from the origin, etc). However intersecting/splitting/triming curved objects, offseting curves and non-planar surfaces, rebuilding curves and surfaces and other operations can introduce larger discrepencies.
@bruno.zuber Your apparent errors of the order of 0.00001 could be due to using meshes rather than Nurbs. Apparently Rhino has used single precision rather than double precision for meshes, and single precision has 6 to 9 decimal digits of precision.
Another potential cause is if the objects are a very large distance from the world coordinate system origin.
Many thanks for the follow up David.
OK this is interesting to know.
However in that case, I did not use meshing tools, only 1D and 2D geometric objects (lines, poly-lines and surfaces) and only in reasonable distance from the “origin” (model of approx 40m).
Thanks David …
but then …
again talking only about straight 1D/2D objets built perpendicular/parallel to the C-plane
… what means the tolerance value in the settings?
What did you mean when you said “mesh tools” here:
Are your objects NURBS or meshes? Do you ever use meshes?
How far are you objects from the world origin?
Tolerance setting has no effect in that situation…
Rhino uses the tolerance setting to determine when to add control points to the NURBS objects resulting from geometry operation such as Intersect or Offset so that the result is within the absolute tolerance of the theoretical “exact” result.
Perhaps you could upload a simple example of your geometry which you are not satisfied with.
) the fact that for a general case, Rhino is able (and it is an advantage of course in some cases) to offer the double floats accuracy.