When you model is located far from the world origin, or you are using a unit that is too small for the physical size object you are modeling, then floating point issues can appear.
They are seen in commands that rely on accurate intersections calculations like booleans, trimming, hatching, Make2D, Clipping Drawings, Hatch and may more.
The typical issue is that hatch messed up, the Make2D is not accurate, and clipping section may place the background mis aligned with the section geometry.
In general, modeling a very large distance from the origin can cause problems and should be avoided.
Rhino, like most CAD products, represents position in double-precision floating-point numbers. That means the x‑, y‑, or z-coordinate of any point can have a value ranging from as large as ±10308 to as small as ±10-308.
Because of the limitations of current computer technology, we expect calculations to be accurate to 15 digits of precision in a range from ±1020 to ±10-20. This limitation is found in all modern CAD products.
If your integer fills up the 12 of the 15 digits, then the accuracy is “rounded off” This is the primary issue you are hoping to avoid. This is not just Rhino that uses floating point math, all CAD programs (AutoCAD, BriscCad, TurboCAD…) do.
Make2D and Clipping drawing rely on Rhino being able to calculate accurate intersections. If the intersections are “round off”, then the outcomes of these commands will look inaccurate. To get the accuracy desired, you need to:
The is the best approach to create metric architectural models in reasonable unit like Meters and only dimension in mm. While mm entirely is the correct choice for a small object like jewelry. For architecture where the objects are 10,000 or more times larger, a unit like Meters is a much better choice for precise calculations.
CAD users should understand that floating-point numbers are approximations of real numbers, not exact representations, and can lead to rounding errors, especially when performing complex calculations or comparing values.
Computers represent numbers using a limited number of bits, which means they can't store all real numbers with perfect accuracy. This is particularly relevant for numbers with decimal parts, as many decimal values don't have a precise binary representation.
When performing calculations, floating-point operations often result in numbers that are slightly off from the true value due to rounding. These errors can accumulate over multiple calculations, leading to inaccuracies in the final results.
Most modern computers use the IEEE 754 standard for floating-point arithmetic, which defines how numbers are represented and how operations are performed.
The decimal number 0.1 cannot be represented exactly in binary with a finite number of digits, so it's stored as a close approximation, and the difference between the stored value and the actual value can cause problems.
For additional information on this topic see these links:
Question? Email tech@mcneel.com Attn. Mary. Include a small file and your Rhino SystemInfo.