lag reducing ideas needed PLEASE

Biggest source of lag? Avatars. Second biggest cause of lag? Prims. If your sim is nearly full primwise, no matter how efficient your textures are, you are going to be in lag city. Rotating prims are another source. All those rotating fish, the spinning signs and water fountains with rotating jets contribute significantly.

Sex balls. All those hundreds of pink and blue spheroids of carnal pleasure are killing your framerate, especially those old, tired, dust covered ones that never get used but continually listen in vain hope that they will again be used. It is time to retire them or take them up when you are done.

Cubes are your friend. The more you deviate from the primal cube, the more resources it takes to produce it. Texture only the sides that will be seen, use blank textures with a matching color everywhere else. Concerve prims at every opportunity. instead of 10 prims worth of pictures hanging on a wall, put all 10 pictures and the wall texture in one texture for the wall. If one alpha texture will save 10 prims, go for the alpha. If you can save a torus or two with an alpha, again alpha out.

Opening doors, sliding doors and elevators should be used sparingly if at all. Resist putting in those snazzy free hot tubs you see everywhere unless you actually use it. If you want it for looks then pull out the scripts and sounds.

Limit physical objects as much as possible. Resist the temptation to set those cute birds free to fly around. Limit the use of trees and plants. Although they only use one prim in the server side, your computer is still having to render 5-10 or more prims to see them and each side has an alpha usually.

If you enjoy:

Ska Music
Mindless Rants a la Lewis Black
Counting how many people I can convince to log off on a Sunday
The odd offensive song
Prank calling a random Linden

Then ... well yes

Hmm ... What's better: 8 flattened and widened tori or 96 prisms making up 8 dodecagons?


....or should I just build something else?

A general principle used by software developers is to understand the nature of efficiency (have a gut feel of lag) and build using good principles - hoping for an efficient system, but not worrying too much about all the fine details.

Once you're done - you "profile" your software. Basically a fancy way of saying measure the efficiency, specifically measuring which sections are efficient, which aren't, which get called often, which don't etc.

Only then do you really start optimising. This is because predictions of what is or isn't gonna make a difference are often wrong. Code well, then measure, then optimise.

To turn this on-topic - scan the forums and the wikis to get a gut feel for what causes lag.
Then build - aiming for low lag - but not stressing too much.
Then use the stats bars to see where you get lag - and what type of lag.
Only then do you optimise.

I agree with this almost completely. My one dispute though is from personal experience retexturing half a sim including 9 businesses and a walk through prefab lot. Preplanning to use small textures BEFORE you build can be an immense timesaver.

Depends.

The 512x512 is more likely to get messed up by the "fake TCP" download mechanism, but they seem to have fixed that pretty much... now they need to work on clothes and skins rendering as solid black blobs.

The amount of data downloaded should be comparable.

The 256x256 will rez in in 4 stages. The 512x512 will rez in in one step.

I don't think there's much difference, it's more a matter of how you want the user to see it rezzing in...

In a mall or store, using vendors instead of lots of boxes will massively reduce the initial texture load. I hate going into clothing stores because they almost NEVER use vendors, and they have rows and rows of textures I have to download.

The best vendors I've seen are the ones that have a large image of the current product, and little pictures for the Previous and Next buttons. That way the texture for the next object is preloaded by the time I've finished looking at the current one.

OMFG! I'm laughing so hard, Siggy!

had a strong hunch mall lag was largely caused by all the different textures.

thanks for all the suggestions, already have put some into play and seems to have reduced the lag, now i just gotta continue.

again, thanks everyone

Suezanne, it depends.

Image files carry a certain amount of overhead, (headers, color lookup tables etc.) By combining your 256 textures into a 512 "texture sheet" you are allowing images to share this overhead which reduces the total bytes that need to be downloaded.

However, Second Life was designed to prioritize the important textures, the ones you happen to be looking at in particular. This helps because you wont have to needleslly stress the server and your bandwidth downloading textures of things you don't see.

So combining texutures is a GREAT thing to do if all the textures on the sheet will be in one eyeshot (for example: the textures on a car, or boxes in close proximity in a store.) However, if the textures on the sheet are far apart (for example, street signs that are skattered around a sim), you will be needlessly loading larger textures than you have to for any given use.

It seems I was wrong here, the delays I'd seen in large texture downloads weren't just due to the "fake TCP". SL seems to defer larger textures, so a 512x512 will take longer to show up than four 256x256 textures.

Your advice was all good but I wanted to clarify this part. Lag is actually a bit more complex because there are different KINDS of lag, in this case we are talking about lag due to bandwidth vs. lag due to render performance on your video card.

Prims cause very little bandwidth lag. Even a sim jam packed with prims need transmit only a tiny amount of information to our clients for render. Textures on the other hand is murder on bandwidth. You need only look at the file sizes on all the images to get a feel for what has to be downloaded. This is further complicated by the fact that multiple people in a sim all have to grab those textures too, so THEIR downloads can lag you.

Contrast this to the lag due to renders. Textures DO add a performance cost for your video card but it's not as bad as prims, especially complex prims like tori.

So if a sim is full primwise yet completely untextured, you will find folks with high end video cards may experience very little lag, while people with older video cards will be lagged to death. Textures, on the other hand tends to effect everybody equally, but will become more troublesome for people with slower internet connections.

Therefore, when I build I do my best to strike a balance. If a very primmy build can be replaced by a single texture, it's often worth it as long as I work hard to keep the texture as small as possible.

A HA! This I didn't know! If this is true it would largely negate any benefits of making texture sheets. Good to know!

Limiting across the board all textures of only 256 x 256 is pretty hard sell I think. Many textures for sale are 512 and also a 256 x 256 image for product images is not enough detail for most especially clothing. I have seen malls with hard limit of 512 textures and it's been good to great for lag. If you try some of the other suggestions here I think it should make a big difference. I think other things that can be done is kill all visitor greeter / counters most are based on sensors (laggy), 3d vendors and other non-essential scripts.

This isn't hard information, it's an educated guess based on what I've seen and on other comments elsewhere in the forums, you need a real guru like Strife to give you the real scoop. Also... it depends on how many textures you're talking about: there's a little per-texture overhead, so a 512x512 is going to be smaller than 64 64x64 textures. Plus, you DO get the whole thing showing up at once.

If the textures are only displayed on demand by a vendor, then it doesn't matter terribly much if they're big. If you're really allergic to vendors, How about small lo-res images for the box, and a larger image that loads when you click on the box?

I've never been able to determine with any reliable predictability the order in which textures will appear, except to say that whatever's under the mouse cursor always gets priority. Canvas size doesn't always seem to be the determing factor, as far as I can tell. My USS Defiant replica is a good place to observe the randomness, at least for me, because it's one area where I know all the texture sizes by heart. The floor texture is the only 1024x1024 there is, and the various textures on the walls, equipment, computer screens, etc., range from 128 to 512. When arriving on the ship for the first time, sometimes the floor appears first, sometimes it appears last, and sometimes it's in the middle. Clear your chache and enter the ship a dozen times, and you get a wide range of results. All I can say for certain is that if you're focused on the floor, the texture rezzes right away, and if you're not looking directly at it, then it could rez at any time. The fact that it's the biggest one doesn't seem to matter in and of itself.

All things being equal, I would agree that four 256's SHOULD load quicker thatn one 512, in the same way that slicing a large web image can help it load faster, but things are not equal. I don't know how the loading order is determined, but what I do know is that size alone is not the determining factor.


I wouldn't give up on texture sheets just yet, Aimee. I'm still sold on them.

First my disclaimer: I am completely non-tech to the point of not being able to remember the difference between memory and hard disk space...and so any replies will have to explain in English and no techie-talk.

We tried really hard in Numbakulla to reduce lag:
*we used a limited set of textures,
*reduced any big ones to 512X512 or less
*tried to keep to no more than 12K prims in the sim
*reduced the use of light, and alpha textures to a minimum
*deleted scripts from water prims
*reduced the number of scripts to a minimum
*no open listens
*deleted as many twisted or torii prims as possible, especially twisted torii
*asked players to takeoff bling/hoochie hair/high prim avatars

In those days, it was a simple matter of looking to see how the FPS in the sim was doing. If we added anything and it dropped dramatically, it was fairly easy to see what had made the difference - AND what difference removing that item or script would have.

Baron Grayson built some beautiful crystals which were wonderful - but had a terrible effect and were therefore removed, much to his chagrin, I think.

Now that Sim FPS is set at 45, and what happens when the sim is under stress is that the scripts run slower instead of the sim FPS dropping, I would very much like to understand *how* to do what is described above: use the stats bar to read what is happening in the sim. With the above disclaimer that I am very non-techie in mind, I can't see *any* way of linking the two.

We have had continual problems in Nemesis, with all sorts of weird things happening, including the inability to use a radio in the sim. At one point people in the sim were crashing, and the sim was crashing. None of this seemed to show in the stats anywhere, which I have found extremely frustrating.

If anyone has insight into the things which we should be looking at, I'd be grateful .
Cali

Srever side load can be reduced by building things to help the physics engine:

1. Make things that aren't going to be collided with or could be brushed aside in RL (e.g. curtains or plants) phantom.
   
2. Avoid concave surfaces (I believe thins includes linked sets, for instance leave ceiling and all walls of a building separate).
   
3. Place a transparent cuboid prim over complex objects (for instance a fancy lamp) if you've got space in your prim allowance. Haven't checked this, but should work in theory. Not sure if it needs to be linked or not either.