Source of prim creep?

I have seen various discussions about whether prims will creep on their own out of alignment. Some here never seen it happen while others say it has.

Now, I have been working on a huge building and I have noticed something when moving various parts of it. (I had to flip the entire thing 180 degrees at one point. Ugh.) The building is too large to link in its entirety. So, I have been linking the individual walls and floors. I am trying to keep this build seemless. No gaps, no overlaps. However when I move a linked wall, I see some prims will move out of alignment with the rest. The amount is small like .0n or .00n, but it is noticeable none the less. Upon closer examination, the root prim of the linked set is where it should be, but one or more of the linked prims will be ever so slightly off.

Has anyone else noticed this or can replicate it?

There are rounding errors in position that don't show in the 3 decimal places that the build tools show.

There is a workaround for doing what you are trying to do. Even though you cannot link a huge build, you can select it all at once and move or rotate the selected set. The easiest way to do this is to position yourself above the build, Ctrl-3 to edit and drag a box around the whole build. You can then move or rotate the selected set as one unit even though they are not linked.

I used this method to rotate a 60m long house and all its contents with no mini-drift or misalignment at all. Good luck.

I would maybe accept this if I was working with figures like x.125 or x.133. However when I moving a linked set x coordinate from 24.000 34.000 and I notice certain pieces are at 34.012 and others are at 33.998, etc. Weirdness.

More than familiar with the technique. When moving that building 180 degrees, I ended up with various pieces at 176, 180 and 184 degrees. The only other thing is think of is that this build is close to the sim edge.

Whenever I need to move or rotate a large set of linked prims the first thing I do is cross my fingers, then I touch some wood and if there's any around I throw some salt over my shoulder. Seriously this is a pig of an operation that often results in total disaster especially if you get a wave of packet loss during the process. Good advice is to select the whole build and take a copy into your inventory before you do it.

Prim creep or prim drift is a common (and existing) phenomenon in linked prims. To my knowledge it is caused by the absolute sim coords->relative link coords calculation taking place in linked sets.

The forms of prim drift/rot I have experienced:

1.7 assetrot
On update/sim resets some internal prim values (cut/twist etc.) will change. I assume this is because the assetserver (mySQL) fp precision is actually different from the sim's.

1.7 precisiondrift
Changing numbers since 1.7 can cause slight 'jumps' in prim values (cut/twist). They happen instanteneously or over time. Seems to be caused by asset conversion too??

localrotjumpers
Adding scripted local rotation (not omega) to prims 'confuses' the sim caches in some way. At 'recaching'?? (some time a day) of sims, these object can 'jump' to new positions.

linkdrift
The linking and unlinking of prims seem to cause the already mentioned relative->absolute fp errors. Causing errors during unlink/relink and when moving using 'edit linked parts'

rotrot
The fact that SL uses quaternions internally but calculates to X,Y,Z angles causes weird errors in angles some times.

primrot
In the long run prims seem to drift slightly. I have no explanation for this, and i'm not even sure it's happening.

I probably forgot a few...

The linking causes it for me.

For instance, i have three 10x5 wall sections perfectly aligned with copy selection. When i link them, a gap appears between the prims, when i unlink the gaps narrow,but are still there. Its been screwed since 1.7.

-LW

at the script show someone had a script for linking big things like houses... Can't remember the name though. Anyone?

Floating point numbers stored in IEEE-754 format (which most CPUs use) are not intuitive to our decimal brains. For example, 34.000 might look like a nice round number to you but internally may not exist on the discountinuous number line of IEEE-754 and the closest representation may be 34.0009. I made this particular example up but the principle holds.

Sim edges are doomed. There is a 10m border on the interior of a sim edge where math seems to fall apart. The build I mentioned was at a corner so prior to building I placed 10m "guard prims" in that buffer zone so that I could avoid it.

There are also just plain bugs to contend with, and as someone noted above, if you get a packet loss burst in the middle of a move operation (and sometimes if the asset server is too busy) all bets are off. *sigh*

If I need to rotate a large collection of objects, I always log off first. This clears out your undo buffer, among other things. That's good because if something goes wrong in the rotation, packet loss or what have you, you can safely hit undo as often as you like to put things back the way they were. If you didn't relog just beforehand, then previous changes you may have made to the components of the build may also be undone, especially if thee was packet loss and the parts of the build are out of step in the undoing.

My main bane is simple prim rot. Over time, the identical units of a building I have will start to drift out of alignment. I've seen up to an 1/8th of a meter. As this building shows the prim rot so much more than any other I've ever had, I believe it to be related to a llSetPrimitiveParams function that would change the hollow of one of the prims in each linked unit. (The door.) It may be that the units that have their doors opened and closed more drift faster. The drift seemed mainly in the X axis, but that's just a feeling - I never tested it.

I had something similar.

I had a flower that opens and closes. The stalk stands still and the flower -- a shaved torus innard -- gets llScale'd over and over and over. Everything drifted noticably after not very long, and the flower would be floating a half meter away from the stalk.

I assume this is all flavors of roundoff as the Engine tries to reslot everything back "where it was" sort of.

The fix I used was a script something like (this is my operator typing, he has no access to our Inventory and scripts just now):

llSetTimerEvent(600) // easy on the server

timer()
{
vector here = llGetLocalPos();
if(llVecDist(gHere,here) > .2) // move .2m or more is for real
gHere = here;
else
llSetPos(gHere);
}

I did this in each prim of the object.

Maybe that can help.

I used to make sculptures with rotating parts, I had to abandon them because they would slowly walk across sims, quite amusing but very frustrating

Source of Prim Creep

=





Back to off-topic I go..

*looks at sketch for steam engine*
Well that sucks to hear that.

Something along the lines of Davan's script will fix it though. It's an annoyance but not that big a problem.

I had an interesting piece of prim creep just this week, and not on a big build, either... in the Angel earrings I was putting together the main body of the angel is a single prim... and I decided to make a very simple script to just change the dimpling [actually the two angles of twist 26 DEC 2005] of the sphere between two values. So I got nice flappy wings on the angels... put them down on the workbench, work on the attachments... put one just where I wanted it, but did not link in case I needed to do further adjustments, went to place the second attachment, and looked back at the first... and the angel was slowly moving away from it! Each little flutter ooched it just a bit further away!!

After sitting there with my mouth open for a few seconds I started to giggle... the second was doing the same, of course... I took the script out, made them unflappy and put it back in. So they have a bit of a warning not to leave out on their own or put onto a christmas tree as an ornament... as they will slowly flap away... pictures of chasing little angels around the house...

Attached they are obedient and do as they should. Although I suspect they are slowly dragging the AV a bit of a millimeter at a time as they pull on the ears.... nothing that can be proven, of course.

So just a fun little item from The House of the Twisted Prim. Even at a jewlers level, prim drift happens.

As annoying as prim drift or creep can be, I wonder if in a controlled environment, they can be harnessed as a virus can, and used to benefit builds some way. For example, "organic" placements that don't require a strict locked grid, and are in fact may be quite counter to that.