Question for someone from the libsl team

From another thread:



This is where we are at in the prim drift problem. Gearsawe Stonecutter started working on it and I jumped in. We have independantly narrowed it down to how LL is storing the prim information. There are a lot of linked prim combinations that will result in reproducable drift upon a sim restart. You can also speed it up by rotating certain linksets in a seesaw manner without having to restart the sim. Some of those resulted in drifts in excess of a meter a day. But I also spent a lot of time trying to break it down to the lowest common denominator. I noticed one single prim that Gearsawe had that will drift everytime a sim is restarted.

Take a .5 meter square prim and with Rotation = <351.40, 6.05, 22.35> shear = -0.10, 0.30 will drift <-0.000015, 0.000000, -0.000015> after every restart and it is accumulative.Take the same Prim and same rotation and a shear of -0.50 & 0.50 or 0.50 & 0.50 will not drift. Or the same prim and same shear but a rotation of <30.0, 30.0, 30.0> won't drift either.

At first it seemed logical that the position of the prim or linkset was recorded and then the rest of the information like rotation, shear etc. But if that was done then there wouldn't be any drift in the single prim. So the question is condensced down to:

How exactly is LL storing the prim information? How is it that position + rotation + shear will result in drift? I know the bounding box center is different for this prim from it's position but the bounding box shouldn't play a role. The answer for this problem should be applicable to linksets also.

The local disk cache is only storing the prim information that comes off the wire, your local cache shouldn't be playing a role in the sim drifting prims. The most likely reason I can think of for object drifting is lossy quantization/dequantization of prim parameters. In theory the X/Y/Z coordinates for an object are each stored as four byte (single) floating point values and won't be affected by any other parameters, but who knows really. The number that stood out most is "shear = -0.10" because 0.1 can't be accurately represented with a floating point system. Take a look at http://babbage.cs.qc.edu/IEEE-754/Decimal.html and punch in the values you are working with, you'll see that -0.10 has a significand with a repeating decimal (1.5999999) and you are actually storing -9.9999994e-2 instead of -0.10. Furthermore, values like shear are quantized down to single bytes (256 possible values in theory, in practice even less than that because of the quantization formulas LL is using) so you have a huge loss of accuracy with things like shear. If shear is being figured in to the object position at all when it's stored, this would cause it.

Llauren, We have been working on the problem for nearly two months now and it is spread out over about 4 threads with a lot of dead ends and side treks. Even the qoutation from Strife was from an unrelated thread. Prim drift is a problem that has been with SL from day one. Most have just accepted it as just a nuisance, while a few have tried to gather some data over time. You will still see a thread pop up every now and then from someone bitching that thier doors drift in thier builds.

Still after a hundred or more hours of work between Gearsawe and I and twice that many sim restarts it all boils down to how LL is storing the info. I had been promising for a couple of weeks to post the question on the libsl mailing list but didn't really want to "spam" the list and side track anyone from thier work. The hope was that they had been able to work out how the info was being stored. Eddy's answer would negate that assumption. (Thank you Eddy). Unfortunately being that the problem has been around for so long, a person would also have to come to the conclusion that LL also just views it as a nuisance. If we had been able to specify the exact cause of the problem and gave the solution then MAYBE some developement time would have been allocated to fixing it.

At some point I will post the query in Answers just on the off chance one of the backend people will respond. Other then that the project is dead in the water until we can find out how the info is handled.

Sorry Llauren. I was replying to your message posted before Eddy's reply while you were typing the follow up question. I'll get back a little later with the relevant threads.

Prim drift is a perplexing issue to which there is no easy solution short of hierarchal linking (HL) & higher percission floats (doubles).

LL isn't keen on implementing HL, it's a lot of work; it effectively requires rewriting link_message, detect events & various functions; it would be easier for LL to do this with Mono in place ([post=1330994]Mono status[/post]), as then they could just create an object model and return objects instead of link numbers (an prim object model POM).

It's nice to be quoted ^_^

I think this is all of them. You will notice that I came to the (false) conclusion at one point that all of it was because of IEEE 754 float errors. It probably is to some extent but still the server is doing something that is screwing things up. In the example I gave above on drift the object was set in all three axis to zero float and checked to 6 decimal places.

/54/21/146735/1.html
/310/7e/144846/1.html
/142/d3/145466/1.html

While looking for these threads I also stumbled across another relevant qoute from Eddy:



From this related thread:

/54/f4/136824/1.html