This is one of the things I have learned to live with, but never really understood…
Why isn’t Rhino accurate when it is far from the origin?
In example:
I have a bunch of height curves far from origin and extract points and then select duplicates. Many duplicates found.
Then I move the curves to origion and repeat. Now there are no duplicates…
So why isn’t Rhino extracting the curve points accurately?
To me it makes no sense that extracting a point that is located at X=5 500 000.002 should not be placed at exactly that position when a point extracted at X=0.002 is extracted exactly.
I’ll provide some curves if you can not easily duplicate this.
The thing is that there is “space” between representable numbers, which changes with the size of the numbers (look for “gap” in the wikipedia article). Also the IEEE-754 specification handles numbers close to zero in a different way (“denormalized”).
I have heard this mentioned many time on the forum.
I think what would help many users is to know how far from the origin accuracy degrades(Based on Unit system)?
It is probably a case of gradual degradation of accuracy in which case there should be specific distance values at which best effort tolerance drops
**Example:**From 1x10^5 units from zero best accuracy is 0.01 units (Or some info like this would be useful)
Warning users to " Don’t work far from the origin" is about as specific as ‘Cut me a long piece of rope’.
I think most users would appreciate knowing they should stay within a certain radius of the origin to maintain their desired tolerance values.
At the moment the most obvious indicator to most users is when their meshes start behaving badly, but there should be a more numerical value to this. Michael VS
This is not just a Rhino problem.
I use Autodesk product extensively and the “far from origin” issues are numerous.
I always use world 0,0,0 as a base point for any drawing elements and when it has to be placed somewhere, e.g. real world co-ordinates far from the origin, a drawing is compiled of referenced files at the desired locations. That way, any individual plan / drawing can be worked on without the inherent problems…
Here in Australia, our survey datum point is close to Melbourne, most of my work is in Sydney being 1000 kilometres away, and working in millimetres means that the origin can easily be 1,000,000 units away, and objects just do not behave as they should. “Grip points” at the ends of lines may not appear is a very basic example of far from the origin behavior.
OK, so what you are saying is that floating point is with a FIXED NUMBER OF DIGITS? And the point floats around somewhere within that fixed number of digits? That makes a lot of sense. So “wasting” many digits before the point reduces the amount of available points after the digit.
But there must be another bug then because what doesn’t make sense is that the number of digits used is 11, which is half precision isn’t it?
I know Y=6 652 615.116 meters is quite far from the origin, but why can I can snap the dimensions so accurately? And why can’t MESH PATCH do the same?
Are some tools running in lower tolerance than others?
Also take a look at this meshPatch vertex deviance from it’s input points:
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, I think, you can imagine as the mantissa differing by a single, least significant bit. I’m no expert by a long shot, so please inform yourself by the Wikipedia articles
i digged deeper into the topic. i found that even when working 1000km far from origin in mm which is billion of units, the precision (gap size) should still still be in range of nanometers but obviously rhino has issues when working this far from origin (why?).
i used formula
to calculate gap size for 64bit floating point number and the result for billions of units from zero remaining precision within that range is:
i might be wrong somewhere but if i this is correct it would mean it should be absolutely possible to work even further from origin without issues but reality is that there are many issues. My latest experience that gumball position was off by millimeters from correct position when working only 500km from zero.
Can someone explain why there is discrepancy between theory and reality? (if there is any)
Computer code math functions usually have different versions for single floating point precision calculations vs double floating point precision calculations. My guess is in the code for Rhino there are a few single precision functions, probably left over from the past when double precision math could be much slower than single precision math. For most purposes the difference between single precision and double precision isn’t noticed, but ocassionally such as very far from the origin it is noticeable.
i thought so but its quite dangerous when user has not way to see that or is warned (visually everything looks alright, how could i notice 1mm off?).
thats what i have been saying for two years look under the hood and eradicate all issues like this once and for good, instead i have been told i should model closer to zero (why should i when it all depends on fixing known and resolvable issues). because now its halfbaked and rhino cant be considered “industrial strong” as i read in some other post which i liked.
i can work far from origin, volume centroids are calculated correctly BUT gumball position is off. How can one be sure what is right what is wrong? these are very important things because this is CAD software which is supposed to be accurate and people rely on it thus should be priority. i know there was big leap from v5 to v6 but none from v6 to v7. Till when should users wait there are no more issues like this? Elon might land on mars by that time …
Only limitation is 64bit everything else is responsibility of the software developers. I know rhino is not the only one but could be only one which makes it right. This is the burden of 90s cores in almost every software on this planet holding us back.
My guess is the remaining single precison math is buried in libraries or similar, and finding them is not just a matter of someone taking a couple of weeks to go through the code .
The display pipeline, i.e., your graphics card works on single precision only (some expensive ones may work double-precision). Therefore the ecosystem is mostly built on single precision.
It’s similar to someone tens of years ago saying “IPv4 is enough”
its a hybrid of double precision coordinates mixed with some single precision operations and single precision render mesh. is there any cad software out there which uses double precision solely for everything thus having no issues with far from origin?
This could be solved by a max drawing bounding box where all calculations handled by the graphiccard uses that bounding box as “world”, and eliminating objects outside that box. How difficult it would be to incorporate I don’t know, nor how much of a performance hit, or gain for that sake.
