This is an old revision of the document!
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.
For additional information on this topic see these links: