Is it true that buildings in the sky are less laggy?

Hi

Is it true that buildings in the sky are less laggy?

Is it better to build things like clubs, casinos etc. up above the ground?

It depends. The less objects you're able to see, the less your system gets bogged down, so you get the appearance of "less lag". If you build at a high enough altitude that the stuff on the ground is beyond your draw distance, then you'll benefit in this regard.

However, the higher everything is, the bigger the calculations get for every little thing, which causes the appearance of "more lag", so you're suffering. Plus, if you go too high, things can start to get wonky.

So what depends really is how you're defining "lag".

The sim still has to deal with all the scripts in peoples' attachments, however, if you put it higher than the average draw distance (128 - 256 M), and above the clouds (about 300 M) you should find some improvement. I build at 400M and show off at 25M (ground level).

I use a teleporter with a tilted axis to move between the two levels, though I sometimes just jump down to the ground from 400M.

I doubt there is anything that will reduce the lag of a club or casino crowded with 30 avatars all wearing hundreds (sometimes thousands) of prims worth of attachments....well, besides staying away from said establishments....

Being in the sky while most others are on the ground will reduce your lag, yes.

Being in a skybox near a busy club that is also in the sky is no better than being on the ground near the same club. I got lagged to death recently in my 500M skybox when a store at 600M in the same sim held a huge event. It was actually LESS laggy on the ground!

Building a club or similar venue in the sky is probably more courteous to the other residents in the sim than doing so at ground level, since it has less lag effect forced on those who are on the ground.

No matter where the club is, if it is packed with people, it will get laggy.

The only way for a club or casino to really minimize their impact on everyone else is for that club or casino to be on an isolated private island, with the whole sim to themselves and no adjacent sims to get lagged by them. The club itself would still get laggy when packed, but won't be annoying all their neighbors because their club full of customers (or casino full of camping chair zombies) is taking all the available agent slots for the whole sim.

Unlike humans, computers don't find calculations involving larger numbers any harder than calculations involving small ones.*

* Assuming you're using the same precision (numeric datatype) for all your calculations, which it is.

I wouldn't agree with that. Larger numbers are harder for computers to deal with than smaller ones. Just because computers are more efficient than humans doesn't mean they're immune to cognitive weaknesses. They have trouble for different reasons than we do, but it's still trouble.

The larger a number is, the more memory it takes to keep track of, and the more processing power it takes to do anything with it. Remember that Star Trek episode when they forced the evil entity out of the computer by making it calculate the value of Pi? You could overwhelm a real computer by doing the same thing.

In SL, the higher you go, the more complex the math becomes, more difficult physics calculations get, the more prone you are to seeing rounding errors in prim placement, etc. It's a simple equation. The more digits involved, the greater the margin for error.

I support what Chosen said. Most dimensions and locations involve floats, and they consist of a mantissa (the basic number) and an exponent (base 2). The weakness is that the mantissa only has 24 bits (max approx 16 million) so that is only 7 decimal digits. If you are building on the north or east half of a sim, with numbers greater than 100, you only have four digits left for you fractional part, whereas on the south west coast where numbers could be close to or under 10, you get an extra decimal digit. Going sky high also gives you less z accuracy.

This is incorrect. All numeric data is allocated 4 bytes, regardless of value, which is why there are limited ranges of possible values. It takes no more memory to store the value 1,365,246,987 than it does to store the value 0.



Not in LSL, you couldn't.



True, higher-value floats lose precision, but it requires no more memory or processing power to deal with large-value floats than small-value floats, does it?.

I'll concede my reasoning for precisely why calculations become more difficult at high altitude may have been wrong. I was basing most of what I said off of the way it was once explained to me by a friend who teaches VR programming graphics at a university. It's entirely possible that my recollection of his wording could be off the mark. It was a while ago.

However, it still remains true that whatever the reason, the math does get funkier at higher elevations, and SL in many cases will have trouble as a result. I'll bow to ed44's superior knowledge on the subject, and accept his explanation as to why. Thanks, ed.

is 768 a number big enough to produce any noticeable loss in precision? that is the maximum altitude that a non-phys prim can reach, higher than 768 meters, only physical prims that have been pushed (either by an avatar , by physical calculation (like a bounce) or by scripts) from below that altitude can reach, a few tricks might allow a non-phys prim to be placed higher, but lots of things get wonky when they happen above the maximum altitude, nothing can be rezzed so high, editing a prim there will cause it to snap to a lower altitude, and a few other things


when the grid gets back online I'll go find an empty sim and fire a few phys prims from diferent points and altitudes to see if there is anything diferent...

perhaps that precision problem is why sometimes when someone gets orbited too high too fast they instead of slowying down and falling start to acelerate and go faster (aswell move in a striaght direction, north/south or west/east even thought they started going to a direction like south-southeast)

768 is only 10 bits (1100000000 binary), leaving 14 significant bits available past the decimal point. That's a max precision of 1/16384 (2^-14), or a little over .06mm.

By contrast, for X or Y, the max whole value is 255 (256 is actually 0 in the next sim), which is only 8 bits, leaving 16 past the decimal, or a precision of slightly more than .015mm.

Deanna is analyzing this correctly.

Just to clarify what I was saying above: Second Life, like practically all programs that carry out math, uses fixed precision numbers - either floats (4 bytes) or doubles (8 bytes) - I'm guessing floats. Carrying out math operations on two floats takes the same amount of time regardless of their magnitude. As others have pointed out, though, there are limitations on the accuracy of numbers - roughly speaking, all numbers have the same number of significant digits, so a small number can have many accurate digits after the decimal, while a larger one has fewer. Thus, the issues with precision at higher altitudes.

Lol had fun reading the bit on number precision. Take it from a 10 year game programming veteran (with extensive Havok experience): working in the sky at 300m-600m will make no perceptible difference in performance or accuracy from a numeric integration standpoint.

But drawing less will improve client performance. Also I notice that at the ground level in my sim there are so many particle emitters taking up the limited particle count, that my effects seem to sputter or even not render. In the sky with no one around, I get much better frame rate and my particle systems render properly.

Also, just FYI: the physics system uses floating, not fixed, point. 32 bit floating point on x86 processors is IEEE754 with 23 bits mantissa, 8 bits for exponent and 1 bit for sign. There is an implied "always on" bit at the top of the mantissa, which is why people sometimes incorrectly say it is 24 bits. The mantissa can be thought of as the fractional part of the number.

not even one milimeter? isn't havok on SL limited to an smallest size of 1 centimeter? does this means the imprecision woudln't be noticeable till it becomes larger than one centimeter?

im not 100% shure but ill tell you that 1cm is verry noticable, it could be a obnoxious gap that catches the light just right from every freakin angle or maby some flickering textures, its not bad till it has a neon sign pointing at it saying "look here" and it seems to be amplified by textures so be prepared, no matter what, to do some eyeballin eventho your 1cm accurate on your math

The scale of a prim is limited to the 0.01 - 10.0 range, but that is not the same as size. Cutting/dimpling/hollowing can produce structures smaller than 1cm. Precision, in this case, means: at an altitude (absolute, not relative to ground level) of 512m or greater, the vertical (Z) component of any position can only be expressed in steps of 1/16384.