Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007065opensim[REGION] OpenSim Corepublic2014-03-19 16:432014-03-19 16:51
Reportermirceakitsune 
Assigned To 
PrioritynormalSeverityminorReproducibilityrandom
StatusnewResolutionopen 
PlatformOSOS Version
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0007065: Primitive position randomly deviates by minuscule amounts upon movement
DescriptionThis issue apparently existed since Opensim was created. I remember it giving me trouble many years ago, and it still ruins my buildings at this day. I don't know if anything can be done to prevent it, but I thought it's still worth reporting.

When moving objects using the "snap to grid" option, especially with "sub-unit snapping" and multiple objects at the same time, primitives often deviate by a minuscule amount. It's only visible if you zoom in very close and watch the edges of two objects which should be perfectly aligned. In practice, this is a problem because small tears can be noticed between flat surfaces that should be seamless... such as spaces between walls.

The deviation is nearly impossible to fix in-world, because this amount is below the number of decimals that can be viewed or modified in the viewer. Given that, for example, an object might be stored at position 1.20651930046733e-05 on the X axis, but the viewer only shows 1.2065.

The reason why distant decimals are occasionally randomized when moving primitives is unknown. I was however told it might be due to the floating point rounding errors, and how Mono and .NET convert integers to floats internally.
Steps To ReproduceSelect an object with several primitives, which all have a clean position rotation and scale (such as 0.5, 2.75, 9.125, 0.0625 or any value that confirms perfect alignment). Move it around with grid snapping, and if possible duplicate it (by shift-dragging) and move multiple objects simultaneously as well.

After doing this for a while, select individual primitives in an object. A few of them will have their position deviated by at least one decimal. So for example, one which should have the Z position 32.375 will have 32.374 or 32.376. If you zoom in really close and compare one of its edges to another primitive which was in perfect alignment, you will notice there is now a small gap between the two.
Additional InformationIn the attached screenshot, you can see two rectangles which are just slightly apart from each other. If selecting either of the primitives, they both display the exact same position / scale / rotation on all axes... yet are visibly distanced from one another. No amount of movement can repair that gap once it happens.

The issue takes place on all platforms and with any viewer. It happened more than 4 years ago, back when I was using Windows and the .NET framework as well as the original SL viewer... running a 32bit version of Opensim. Today I use Linux and compile / run Opensim under 64bit Mono, with the Kokua x64 viewer. The problem is precisely the same. I did however always use SQLite storage, and never checked if the problem happens with MySQL region storage too.
TagsNo tags attached.
Git Revision or version number24436
Run Mode Grid (Multiple Regions per Sim)
Physics EngineBasicPhysics
Script Engine
EnvironmentMono / Linux64
Mono Version3.0
ViewerKokua 3.7.2
Attached Filesjpg file icon Snapshot_001.jpg [^] (870,708 bytes) 2014-03-19 16:43

- Relationships

-  Notes
(0025482)
melanie (administrator)
2014-03-19 16:51

Moving an object will not actually change child prim positions directly. This effect you are observing is because the prims are sent to the viewer, which then sends them back. In this round trip, rounding errors come in. This is because the protocol uses various packing schemes to save on bytes during ObjectUpdate.

Unfortunately, the error, as you have observed, is cumulative. There was a similar case with small negative rotations that would cause textures to continue to rotate by small amounts each time a texture parameter was modified. In that case, the rounding error was introduced in LibOMV.

All packing math would need to be checked to ensure it's round-trip consistent. This also may mean changing math in LibOMV.

- Issue History
Date Modified Username Field Change
2014-03-19 16:43 mirceakitsune New Issue
2014-03-19 16:43 mirceakitsune File Added: Snapshot_001.jpg
2014-03-19 16:51 melanie Note Added: 0025482


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker