|Anonymous | Login | Signup for a new account||2020-11-24 04:06 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007065||opensim||[REGION] OpenSim Core||public||2014-03-19 16:43||2014-03-19 16:51|
|Product Version||master (dev code)|
|Target Version||Fixed in Version|
|Summary||0007065: Primitive position randomly deviates by minuscule amounts upon movement|
|Description||This 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 Reproduce||Select 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 Information||In 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.
|Tags||No tags attached.|
|Git Revision or version number||24436|
|Run Mode||Grid (Multiple Regions per Sim)|
|Environment||Mono / Linux64|
|Attached Files||Snapshot_001.jpg [^] (870,708 bytes) 2014-03-19 16:43|
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.
|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|