Prim drift problem HAS to be addressed.

I know that back in 1.1 this was mentioned as a "Not now, maybe later" sort of thing:

But last night, my entire avatar 'prim-drifted'. That is, the avatar is currently composed of 350 prims, (and, no, this isn't a bunch of wild stupid attachments on my head - if anyone's seen the avatars we build at Luskwood, you'll understand that this isn't just wasteful prim useage) - the head, the tail, the wings, ears, feet, everything: was randomly shifted left to right.

As people who have dealt with this know, this isn't fixable by reattaching, or relogging. The prim drift on attachments is *permanent*.

Last thing we heard about this in 1.2 was that it may not be fixed until "1.4" or maybe later. I don't see this as being addressed in 1.4, so I'm assuming 'later'.

I spent the good part of six hours last night just trying to realign every tiny bit and piece, and of course it still isn't right, and probably never will be. I did have backups from a few 'generations' ago, but since the drift is slow, cumulative, and often subtle - i didn't even notice it until I was a few iterations into the avatar's build, beyond a point of reliable restore.

I was not flying at excessive speeds, I was not crossing sim lines, I wasn't building at any sort of height (6 meters, actually). So I don't know what caused it this time.

I know that many would say that the solution is simply to "not build avatars that complex", but I'm not so sure that's the right approach to take of a bug of this severity.

Since, I've backed up my (95%-repaired) corrections to alternate accounts. Those alternate accounts exist ONLY for backup purposes: so to this, there's another issue:

Linden Lab:

1) If you're not going to fix the problem with attachment based avatars slowly destroying themselves,

2) AT LEAST give us the capability to back up these avatars onto our LOCAL SYSTEMS.

I realize there is no way to 'view or edit' the objects on a client computer. I don't care about this. In building an avatar that is pushing the modeling level of some standalone games, I at least want the ability to back up that work to DVD or CD on my own system, *ESPECIALLY* if it is *KNOWN* that the avatar will slowly 'decay'. Which it does.

This is the third time I've had to rebuild this avatar. Yes, I am fully aware that the TOS does not guarantee the integrity of content.

(The reason I'm saying this is to field off the responses that I know are coming (not from the Lindens, but from the peanut gallery "Don't use that avatar!" / "Don't build stuff so complex or detailed!" / "The TOS doesn't guarantee that things won't break!" -- that's great, and its also counterproductive. )

But while content integrity of what we build isn't guaranteed, local download backups would at least give us the opportunity to ensure against bugs and errors like this one.

But moreover, I'd rather see this bug fixed in the first place. It's known, it's been acknowledged, and we were told "probably by 1.4".

Anyways, enough of a rant, I just thought it really had to be said, since the whole prim-drift issue has been pretty silent since before 1.2...

It's not just avatar attachments that suffer from this. I now have a graphic-rich Heads-Up Display(HUD) on the chariots players ride in our Deus Via game contest entry. (Come play! Game Dev 3, north section, the big coliseum!)

The pieces of the HUD are suffering from several Second Life bugs, drift being one of them. (Alpha sort order being the other biggie.)

Drift happens ever time as an object is linked or unlinked (or just from use). I found that after several links/unlinks to edit the pieces of the HUD, its icons will have moved. Because the HUD is very small, I have elements positioned at the smallest increments possible, so even the tiniest drift results in quite visibally miss-aligned graphics.

My only solution so far is to script every piece so that it A) reports its position relative to a main piece of the HUD whenever its script is recompiled, and B) positions itself to a hard-coded (in the script) offset from that main piece when the object unlinks or the script recompiles.

So after positioning a new icon, I force that script to recompile, copy the offset it whispers, and paste that into the script and recompile again.

Now, when I see the HUD is out of alignment, I rotate the object to default, unlink it, relink it, and it's as good as I can get it.

Unfortunately, LINKING can cause drift as well. Heck, the pieces even drift over time as the object is used, perhaps due to rotations (though all my rotations are 90 degrees). So from time to time, I have to replace every chariot on both fields.

I wanted to let people own their own chariot, so it could store their game data, but they wouldn't be able to do the unlinking safely to re-align the HUD.

What causes this? Does the compression and bit-backing used to send object data over the net suffer from loss of precision for some numbers? Can this be fixed? I sure hope so...

And why the heck are the positions of a link's prims being SAVED anywhere if the object isn't being unlinked and you can't move them while they ARE linked??? They they aren't saved, then re-logging should solve the problem. But the fact that it doesn't means that the server-side database is being updated after the drift occurs.

i do think LL should look to implementing at *worst* like a 'lock' on link sets so that once linked the actual parameters of the pieces become read only and cannot be updated.

As someone who was once *spaced* (to about 760,000 km) while wearing a complex avatar... the fact that there is some kind of 'saving' of corrupted link sets and no way to properly restore them (especially if its not yer own creation but rather one you comission/buy)

which *is* a problem... cause it makes creating a complex avatar not only that much harder.. but it forces the creators to become support specialists for the people who buy them as the avatars or other complex linked things sort of 'wear out'

Off topic, but try adding in a single point of transparancy to the edit window. I hear this fixes that.

as far as i know there is no way to fix that not jus in SL but with polygonal rendering in general. Its why you very *VERY* rarely see stacked transparency in commercial games, and when you do (as in the occasional bridge in far-cry) you often see the same bug.

Its sort of endeming in how polygonal rendering 'fakes' transparency (by rendering transparent objects after all others.

The only way to not get it is to design things such that you never get two transparent objects overlapping that are within a close enough space that their 'centers' can flip between being the closest to you (and thus automatically the one drawn 'ontop' of the other)

Well, enter the Town Hall meeting with Philip.

Seems that it went like this:

Arito Cotton: Is a fix for the 'drifting prims' problem (when you link and unlink a lot of prims together) in the works?
Philip Linden: We will work on the drifting problem.
Philip Linden: Hadn't heard of that one.
Baba Yamamoto: that drifting prim is an old one

Basically the gist of it is, Philip had no idea that this issue was still around. Or that it was there in the first place. Another person at the meeting did declare, "That's an old issue." -- I'm not sure what that means. It's old and that's how it's gonna stay? Dunno.

But it was a bit upsetting that it really -has- fallen by the wayside.

It was unclear to me what Phillip was referring to when he said he hadn't heard of that one. It might have been the uuid thing.

Prim drift has been around before 1.1. I've had to completely unlink, re-align, re-link an 80 prim suit I created that was suffering from prim drift.

6 months later the suit is in need of a major re-alignment and several older works also need re-alignment. The right hair piece on my Fei-Yen KN suit has bent in wards and rotated a bit out of place, and the skirt wings are no longer on even planes and rotated out of place by 3 degrees.

It's a pain to have to re-align everything, but it's more of an inconvieniance to those with no modify objects.

Hey, I'm going to cover prim drift in my next installment of Second Life articles on my weblog. It seems ridiculous to me that this issue has been around for so long, yet hasn't been adequately addressed.

I really enjoy building stuff, but I can't see myself bothering until the drfit issue is fixed. I can't stand data corruption, and as has been mentioned, am frustrated local backups are not supported. I'd never known about this problem until yesterday, and it really ticks me off.

Anyway, if there's anything anyone would like to add to this thread, I'm considering everything that's being mentioned here in writing the next article segment.

Could someone confirm the following statements for me:
- Prim drift has been around since SL began, and hasn't ever been fixed.
- Prim drift potentially affects all linked objects in SL

Also if someone wants to take a stab, I've got a few questions:
- Has the prim drift issue ever been officially responded to aside from the recent town hall meeting? If so, what was the response?
- Is there a consistent, measurable degradation of all SL objects, or are only some objects affected?

Thanks, folks.

Prim drift has been around at least since Summer 2003 when I joined.

I believe it affects all linked object but is more noticable in things with large numbers of linked prims (50+).

Prim drift happens in a number of scenarios in my experience:

Surefire way to ruin any attachments you're wearing: Use one of the many methods to rocket yourself high into the sky (Really really high). As you get higher, your attachments all break apart and cannot be recovered. If they haven't broken yet, you're not high enough.

This in itself isn't a problem because nobody goes that high unless they're experiementing with something. But it shows you how imprecise the positions of linked prims in a set get at high elevations.

Surefire way to make you think you're drunk: Get any linked item with around 50-100 individual prims. Unlink one piece of it (Select Individual, Unlink). Link it back together. You should seen very minor movement of random prims - other than the one you just relinked in. Do this a few times and things become very off. This problem worsens the higher up you are. Go up to even 100-200 meters and you'll really see problems.

The worst thing about these issues is that they are very MINOR a lot of the time, and you don't notice something's wrong until a lot later when things are really off.

Solutions for now: None. Backups are great and you should definately make them, but if you modify something frequently, it's just as difficult to compile all of the modifications from older versions as it is to completely redo the object.

Suggestions to minimize problems: Build as low as you can possibly get (not sure if underwater would be better) and be careful about adding too many prims to one object.

Thanks for the info, Arito. It's a shame this is so well documented by users but remains unresolved.

Here's a possible reason for the drifting:

Floating point rounding error.
Why I think SL will drift prims is that it uses a non-arbitrary size floating point variable to store object positions. The effects of the floating point error is more pronounced as the heights get larger because to accomidate for large numbers to the left of the decimal point, the variable reduces the precision on the right side of the decimal point.

That's my guess to the reason this change is taking so long. Since objects are such integral parts of the SecondLife system, I imagine massive changes to the codebase are needed to change the non-arbitrary size floating point variable's type to an arbitrary size floating point type. Object's transfer size is also something that may need to be taken into account.


Of course... this is all a guess
==Chris

yah that wouldn stop the lindens from makin a value for position with in a link set 'read only' unless specifically edited by a player tho

Yes, this IS caused by floating point inaccuracies, which is why it gets worse as you get higher.... More bits of the variable are needed to encode your height, leaving less for the small offsets between prims.

And as I've said before, there is NO reason why attachments should be re-saved with these changes caused by the system. If the PLAYER did not make the change, it should NOT be stored.

I know why it's being stored now, because adjusting the position of an attachment on your avatar is saved so that the next time you wear it, it's in the same place. But the position and rotation of attachments can ONLY be changed by player intervention right now (not by scripts or physics or anything else) so if the player didn't edit it, the data should NOT be saved.

And even when it IS, ONLY that data should be saved, not the entire attachment's data, including cumulitive floating point rounding errors.

And while we're on the subject of simple building bugs that have been aroud for AGES, Arito experienced one just last night. There were two long cube prims end to end, which got rotated 90 on one axis and 180 on another axis. Then the link was broken and each prim was moved in turn, but wouldn't line up anymore! At the same Z-value, one was higher than the other at the join. Even ROTATIONS are not precise enough.

I'm thinking that precision is being lost in order to save a few bits in bandwidth. Something that can save a LOT in transmisison costs, but results in a more frustrating experience for players.

i agree about the saving of bandwidth costs tiger and for 'viewing' stuff thats fine and dandy.. but the second you open the edit window on somethin the client REALLY ought to go 'hey whoah wait a sec SL gimme the *REALLLLLY* precise coordinates for this thing now cause im gonna need them


and again... all inter-link positions should be READ ONLY except when specificlaly being edited by a player... there is no reason the system should be writing new positional data for prim x in part of linked group y when its attached and yer moving y left and right abit

The prim drift problem was previously discussed here .

My proposed patch for 1.3 did not pass inspection. However I've eliminated MOST of the drift and the final fix will be included in the next patch to the 1.4 preview, which will probably be Friday.

It has been reduced as much as possible, but is not entirely gone because of inflexibilities in our code architecture where objects are built and dismantled in Havok-1.

The good news is that the Havok-2 port does not suffer from this problem (I made sure of that), so there will be no drift of attachments or rezzed objects when the Havok-2 migration is done.

The bad news is that there may still be some drift for an object that is linked then unlinked then linked and unlinked... and so on. This would be caused by true floating point error, there aren't very many ways to get around this when truely transforming from one frame to another.

The good news is that said drift would be on the order of a micron or less each link/unlink cycle so it would take several manual link/unlinks to throw things out of visible alignment.

(It could be reduced by quantizing position precision to something larger than the floating point error, such that the error always gets rounded out, however then all you got to do is to link, rotate, unlink, link, rotate, unlink,... and so on ==> you have worse drift than if you had never quantized.)

(It could also be reduced by moving to 64 bit architecture and using doubles instead of floats. We're not using 64 bit CPU's yet, but are thinking about evaluating them for performance/price. It is an inevitably affordable technology.)

Currently you guys are using vanilla 32-bit P4s, which have 128-bit floating point units. Unless you are using fixed-point multiplication I don't think switching to a 64-bit architecture is going to do much, since the 64 bit architecture applies to the integer ALU only (not the FPU.) I agree that 64-bit CPUs are the Way of the Future, but the FPUs always have bigger registers than the ALU so that alone doesn't play a big role.

If 128 bits aren't enough to squash this, it might be worth your while to consider BCD arithmetic for stuff you don't want to get hosed by machine epsilon (rounding errors.) IIRC from taking assembly eight years ago, x86 has native support for BCD math, so it should be fairly quick.

Huns, thanks for the enlightenment. We're using floating-point, so I presume the P4 architecture is doing the right thing.

Good. My take away is that prim drift may very well be solved. I'll sic our testers on it and see if they can detect any drift.

well architecture aside when you declare a float, you get 32bits

of which i believe only 24 bits are 'precision' aka the mantissa.. the other 8 are exponent

a *double* when declared is 64 bits and has 52 bit precision mantissa and 12 bit exponent so its essentially 2^38 times more precise... aka if we used doubles the problem would essentially be moot since the precision would be SO much higher that the errors would be happening at TRILLIONS of meters up.. not hundreds

64 bit would help that effort because of how the memory adressing works you can effectively 'feed' the fpu of a 64 bit cpu with 64 bit numbers in one cycle.. where as in previous p4 32bit architecture it took two cycles to load a double, and a single to load a float... hence doubles had a... well double performance penalty

unless you have dual channel RAM

am I rite?

Ya know, if you would shovel your prims every day you wouldnt have to worry bout em building up into drifts.

nah the dual channel ram jus feeds the cpu cache faster... that happens on the timing of the memory interface (and thusly much *MUCH* slower'n the cpu itself)

when goin 64 bit tho the cpu will contain 64 bit registers so it only takes a single register and thusly a single cpu cycle to dump the double into the fpu, whereas a 32 bit cpu will need two registers to hold the float and then three cycles to dump a double into the fpu (dumping the first half, shift, and then the second half i think)

essentially a 64 bit cpu *should* be able to run doubles as fast as a 32 bit cpu runs floats... barring any weirdness in the processor architecture itself.

I have not done any ASM work with FPUs, so I have a question. Do you even need to involve the 64-bit registers in this operation? Isn't there a set of instructions for addressing the FPU registers directly?

edit: http://www.jorgon.freeserve.co.uk/TestbugHelp/FPUvCPU.htm

also http://www.stereopsis.com/FPU.html (jesus it takes 80 cycles when you do int(x) in ANSI C!)

Is it just me or does the problem with prim drift sound strikingly similar to the RL sub-atomic problems described by the Heisenberg Uncertainty Principle? Sure the scale of the effect is much smaller in the real world, but maybe that's just because God uses 128-bit floating point numbers.

Knuth solved this problem in the TeX typesetting system by calculating all positions as integers where the smallest interval was smaller than the wavelength of visible light such that rounding errors would be literally physically invisible. Knuth's "scaled points" - the smallest interval, were 5 nanometers and take 34 bits to hold. SL doesn't need quite this high resolution and could and micrometer to tens of meters fits in 32 bits of integer.

I have no idea whatsoever about how Havok handles its calculations and I know that OpenGL likes floats so there'd be a bunch of (expensive) casts, but that is one way out of the hole.