MantisBT - opensim View Issue Details ID Project Category View Status Date Submitted Last Update 0007547 opensim [REGION] OpenSim Core public 2015-04-29 10:40 2015-04-29 10:40 Reporter Magnuz Assigned To Priority normal Severity minor Reproducibility random Status new Resolution open Platform Intel Core i7 OS Ubuntu OS Version 14.04 Product Version master (dev code) Target Version Fixed in Version Git Revision or version number 0.8.2 dev Run Mode Grid (1 Region per Sim) Physics Engine BulletSim Environment Mono / Linux32 Mono Version Other Viewer Singularity 1.8.6 OS X Summary 0007547: The use of floats gives poor precision Description In many places in the OpenSimulator and libopenmetaverse code, floats (32-bit floating-point values) are used. A float uses 23 bits for the mantissa, which gives a precision of 1/2^23 = 1/8,388,608 ? 0.00000012 to 1/(2^22-1) = 1/4,194,303 ? 0.00000024 of a value. When doing e.g. local trigonometry, with values ranging from -6.28 to 6.28, this gives an absolute precision of about 0.000001, which is usually quite enough, and often a margin of 0.000001 is used when comparing if values are equal. However, when used to handle coordinates in a 32x32 varregion, with a 8,192 m side, the absolute precision in X-Y coordinates in the NE end is only about 2 mm, enough to cause visible glitches or cracks in constructions. The same goes for the Z coordinate in high altitude skyboxes, at 4,000 m, with an absolute precision of about 1 mm. Besides visible glitches, several functions may also give unexpected results when comparisons expecting better coordinate precision than 1 mm are used. In several cases these problems are hidden, because comparisons using, or really needing, <= or >= will see two values with poor precision usually "rounded" to the same value. There is however a risk that they will fall on different sides of the rounding border, e.g. 8191.9969995 m => 8191.996 m, 8191.9970005 m => 8191.998 m, giving an apparent difference of 0.002 m = 2 mm, despite the actual difference is 0.0000001 m = 0.0001 mm, well within the 0.000001 (m) margin often used (values rounded to decimals for clarity). In the above example, with a margin of 0.000001 m, the risk of a false high difference is 0.05 % (0.000001/0.002*100%), which I think many can accept. However, if the margin instead is 0.001 m, the risk of a false high difference is 50%, which I think most would consider too high. Also, this small risk may be behind some rare and hard to reproduce glitches in OpenSimulator behavior, since they will only happen maybe 1/2,000 times under random conditions, but never for 99.95% of repeated conditions and always for 0.05% of repeated conditions. Steps To Reproduce Additional Information Mono 3.12.1 Tags No tags attached. Relationships Attached Files Issue History Date Modified Username Field Change 2015-04-29 10:40 Magnuz New Issue

 There are no notes attached to this issue.