Wandering Prims?

I've been working on a project recently to build up a range of low-prim low-texture houses and noticed a lot of ugly seams in the floors and walls. When I checked the prims I discovered that they were no loger in their original positions bt had moved by a few millimetres and /or fractions of a degree. So I went through the whole build correcting thigs and everything looked tickety-boo again. The next day when I logged in the seams were back and different prims seems to have shifted around a bit. This is incredibly frustrating. Who is going to buy a house with nasty seams showing up through the textures? Does anyone know of a way of corecting this problem?

I have been experiencing the exact same difficulties with building my space station and so have my friends, adds to the whole SL is becoming a FPOC thing and LL needs to go back a upgrade and FIX THE BUGS THEY ALREADY HAVE instead of constantly making new ones.

These issues are due to four things.

1) floating point precision. The client viewer will let you set the position of an object to a greater level of precision than is recorded and transmitted between the server and client. So you can line them up perfectly but if that required a fraction of a millimeter, then chances are the next time you get an update from the server it will end up missaligned.

2) level of detail. The farther you are from an object the fewer polygons are used to render it. This is a good idea in theory and works perfectly in most games because objects are not made of prims. All the edges are welded in the typical 3d game and LOD models are provided for the object as a whole rather than individual prims. In SL when a lower LOD model is seen it may not have edges in the same place that it's full level of detail version did, and so the edges won't line up. Your object detail slider effects how far away and how drastically this reshaping of prims happens. Also the farther away something is the lower the precision of it's position. In theory it shouldn't matter because at a distance you don't have the resolution to see small missalignments. In sl once again, the primitive model means that all edges are not welded and so cracks or lines can be seen when this happens.

3) gimbol lock. SL stores positions as quaternions which are not subject to gimbol lock, but quaternions are not intuitive for user input. Because of that SL allows users to put in rotations in degrees around each axis. That method does allow for gimbol lock though and on top of gimbol lock it's dependant upon what order the rotation around each axis is applied to the object. Gimbol lock means that at some rotations, typically when one or more of the degree settings is at 0.0 or 180.0 degrees (ie the most common settings), the rotation that those settings represents is not clearly defined. It could represent more than one actual rotation. Even though rotations in sl are stored as quaternions, the quaternion is calculated using the degree method, even when using llSetRot() and a quaternion directly. In the llSetRot case it's seperated out into a euler (3 sets of degrees) and then converted back into a quaternion before it's stored. That step is taken so that the degree inputs can be filled in for the client.

4) floating point drift. Objects occasionally seem to drift slightly over time. Usually this is the case on child prims, and prims that rotate frequently. The reason for this is related to floating point precision again. When an object is rotated it's position is recalculated based on it's last position rather than it's original position. If the math comes out with coordinates that are higher precision than sl uses, the numbers are then rounded off. If it works out that the numbers are rounded up or down consistantly everytime that object updates then eventually those rounds will cause the coordinates of the object to change significantly.

Thanks for your reply Rikard. I take it that means such problems are basically unfixable. At least I know what I'm dealing with now.

Sounds like lots of words for basically saying the whole thing is fucked up.

You may find the following to be helpful:

llSetStatus(STATUS_BLOCK_GRAB)

it tends to help prevent some of the prim shifting- that which is caused by users touch the object, but not prim shifting caused by miscommuncation with the asset server, nor accidental corruption of data on the asset server (I run into this all the time with my 500+ prim builds because of a major packet loss problem with my ISP)

To addsome extra info to this, two things:
1. The correct form is:

llSetStatus(STATUS_BLOCK_GRAB,TRUE)

People tend to get confused over the statement, thinking 'block' refers to an object (a block), but it actually means, to 'block grabbing'. So the value must be TRUE.

2. The bug which caused the 'move on touch' issue of a lot of objects has been squashed nowadays. So don't worry about this problem atm.

If by "the whole thing" you mean floating point numbers, then yes.

Thanks for the correction on that Damanios.

Floating point numbers are a pain for me as well, with examples of doing something like having to enter 8.957001 to get 8.957 because SL thinks I said 8.954

One thing that might help on this is to slightly move the structure, so it's root prim is on a neatly divisible position number with one-digit or two digit precision. For example x=34.5, y=129, z=24, rather than x=34.523, y=129.029, z=24.1333 . If the size of the other prims isn't really strange, and if you position them 'by the numbers', the rest of the prims should then also be set with position increments that don't get lost in 'floating point roundoff error la-la land'.

When I design a build right now, I start with the foundation on the axis and on whole number x/y/z values, and try to build from that with fairly regular prims. Of course, this isn't always possible. But it seems to help.

Hmmm. I don't see how floating point roundoff errors can cause an object I placed at precise coordinates such as 112,24,747 to drift to 111.999,24,747.002. I've been told that floats are as precise as integers if storing whole numbers below some large limit (16 million?), they only get rounded for large numbers or non-whole numbers. Nevertheless, I do see pieces of my skyport drift over time, despite each piece having been precisely placed at coordinates such as that. I have yet to see a believable explanation for the phenomenon, given that it's certainly not due to rounding error and the grab bug is supposed to be fixed... *shrug*

Julia, that's exactly what i've been experiencing. Like Ceera, I'm very careful when building to place prims at 'precise' locations such as 100.000, 60.500, 32.250 (or whole numbers whenever possible) and generally keep my prim size parameters to simple-ish numbers such as: 5.000, 4.500, 0.250 and yet they still insist on wandering around. Even in linked sets the prims drift around in relation to each other which strikes me as odd. I would have thought an object sonsisting of mulitple linked prims would drift as a single object, but apparantly not.

Who'd-a thunk it: The Second Law of Thermodynamics rears it's ugly little head in SL!