wim
March 30, 2017, 8:19am
8
This has to do with the way that Rhino 5 creates display meshes. Rhino 5 uses single-precision floating point numbers for these - Rhino 6 uses double-precision.
A lot has been written here on the topic. A few links:
It has to do with floating point representation in a computer. Most of the geometry is represented by double precision floating point numbers, but meshes by single precision floating point numbers.
As numbers become larger and larger, the gaps between consecutive floating point numbers becomes larger too. If you are far from the origin, these gaps can become of the same magnitude as the size of your object. Then you start to see jagged edges.
No, it does not work like fixed number of digits. A floating point number is represented as s*1.m*2^e where s is the sign bit, m is the mantissa and e is the exponent. Together there are 32 (single precision) or 64 (double precision) bits to store the sign, mantissa and exponent. This way, an enormous range of numbers is representable, but the gap between the representable numbers becomes larger and larger as number size increases. This is the origin of the inaccuracies.
Representable numbers, …
Thanks for the clarifications. This is a common issue.
My speculation is the snapping issues you are seeing result because there is a large translation component in the view projection matrices. If you can share a model were the issue is particularly troubling, it should be easy to debug our code and see where the snapping calculation starts to fail. The good news is sloppy snapping bugs are often caused by sloppy coding practices when dealing with view transformations and we can probably f…
1 Like