Lag - what to avoid?

What causes lag on a sim and should be avoided? I realise that EVERYTHING contrbutes to lag to some extent, but what are the 'big hitters'? Those big rotating spheres and boxes for advertising, I've heard are big ones. Would the resolution of textures also have an impact? Excluding particles, whats guaranteed to 'kill my sim'?

Logging in.
The only sure way to avoid lag is to not login.

Thank you for your carefully thought out and constructive reply.

Dear, you might want to be a bit more specific. There are 2 types of lag: Server side & Client side. Bling & particles... those are all client side. Some PC's can handle them better than others and don't see any lag from them. Scripts, those are Server side... they affect everyone equally. Textures are a bit of both, but mostly client side.

Some of the worst offenders in client side are those super high res pictures that some stores seem to like. On less robust PC's they take longer to rez. Combine them with the lag of numerous vendor machine scripts all "listening", and you see the lag that is common in the big stores. Another bad offender is the constantly changing dance floors that some clubs like. Each time the texture changes, this forces the client PC to have to re-calculate. Now think of the 10m size limit, so that dance floor is composed of numerous "tiles" each changing, each forcing the client to lag while calculating the new texture (and this is worse when the floor is animated). Yes, some people don't see it... that's because they have better PC's able to deal with client side lag better.

Now you mentioned the rotating boxes... those are scripts, those are server side lag. It really depends on the script in question as to how much it contributes to lag; some scripts are written better than others, and are lower in lag. The execution of the script is just a part of the server lag. There is also what the script is doing and how it goes about doing it.

Thank you Stephanie

Now... Those dance floors... If they are inside a building, and not visible to the Avi, yet within the Avi's draw distance, are they still going to cause them grief?

I take it you're defining "lag on a sim" as anything that slows down your client frame rate, not necessarily things that slow down the simulator (server) itself. You mentioned particles, for example, in the same sentence as "killing my sim", which particles really can't do since they're a client-side effect. They can certainly slow down the client, however.

The single biggest contributor to low FPS by far is poor texture management. The average scene in SL has gigabytes worth of texture data in view, while the average video card can only process a few hundred megabytes, tops. People do really silly things like put a 1024x1024 texture (3-4MB of texture memory) on a 2-foot sign, where a 256x256 (192-256KB) or 128x128 (48-64KB) would have worked just fine. To keep your sim as "lag" free as possible, keep those textures small, small, small.

Poorly written scripts are another giant culpret. People often try to fight "lag" by restricting the amount of active scripts running on a sim at any given time. I don't really see that as effective though, since all it takes is one particlarly bad script to bring a sim to its knees. It's the quality, not the qanitity.

Those are the two biggies, but there are lots more. I'm sure others will chime in and add to the list.

Thank you Chosen. I wondered about those hgih res textures. A few 2000 x 2000 textures on one lot within a sim would certainly be...taxing.....

I believe in running as few scripts as possible, like a lot of people, but I am also very selective about which ones I DO get on my lot. I think I have maybe 10 scripts, total, including doors on 48,000m...oh.. unless I wear my dragon avi, then its 48,000 scripts Not quite, but you get the idea

Chosen hit it right on the head. one of the biggest offenders is poor textures on builds. limit the size of the textures as much as you can and try to use a "common" set of textures in your builds. If you have 12 walls to texture and you are using 12 different textures you will not fare as well as if you have used perhaps 3 or 4 textures.
Another biggie is the textures you purchase here in SL. I pesonally will not buy ANY texture that doesnt have full rights. If it is no mod you cant download it to change the image or to resize it as needed. I once bought some wonderful textures. Unfort they were not only NO MOD but they were freaking HUGE. another buy down the toliet.
Hope this helps

Indeed Sara.. I think I'll build all my buildigs with the same external and internal textures for that very reason. Go to a texture store to see just how bad it can get, and they are using pretty efficient ones in pack vendors.

Just for acuracy's sake, so you know, there's no such thing as a 2000x2000 texture. OpenGL requires that all textures be measured in powers of two. Heights and widths that SL allows are 32, 64, 128, 256, 512, 1024, and 2048. Anything else will get resized at the time of upload to the nearest of those numbers, and the results are not always pretty.

ooh..good to know..thanks Chosen.

One thing I found helpful, Misfit, was to turn on "Beacons-> Scripts" (I *think* its under the View menu) occasionally and look around my land. When you do this, each object containing a script is "targeted" with a red crosshair. I discovered a surprising number of things I didn't know had scripts have them. For example, my partner has placed some butterfly generators on our land: each generated butterfly (usually a dozen or so at at time) is running its own script. I like the butterflies, and we have enough land to support it, but...it was a surprise none-the-less.

For me, its a matter of balancing client/sim performance versus the "richness" of the environment. Second Life would be a sad place indeed if we all deleted every script, used 128x128 textures exclusively, and got rid of every scripted/flexi/high resolution avatar in the world. Yes, we need to be aware of the impact, but I think the world (client and server) needs to continue to improve to produce maximum performance with "rich" environments.

I also think its unreasonable to expect Second Life to perform well on older/under configured machines. Not to exclude folks on 2003 vintage and older technology, but... building a world for the lowest common denominator isn't going to keep people coming back. For the folks on lower end machines, there should be easily accessible performance profiles that let them "tune down" every possible setting to keep their clients working...but not at the expense of everyone in-world blessed by higher-end technology.

Never a truer word was spoken Thomas...quite profound. I run some of that 'older machinery', however it tends to perform far better than what the numbers indicate. For people who dont have my tweaking skills though that are running machines just as old, SL has got to be a bear.. The performance 'staging' concept would sure be meritorious if there was some way to work out the perfect elvel for each stage in the diverse equipment out there.

Beacons - scripts...nice tip...Gonna do that as soon as they fix the presence thingo...again...

The biggest Lag issue right now is supposedly caused by some sort of memory leak. The leak progressively increases the "Images time" until SL restarts the sim.

Building with just a few textures helps.

I've also found that setting non visible faces to "Blank", "full bright" also helps with FPS on low end machines as the rendering engine does not have to do anything except issue a "Tri flood fill".

Looking at the debug image map I can see that there are a lot of textures from avatars since the new trend is to use lots of alpha textures instead of lots of prims.

The prim vs texture trade off is complex.

If the persons computer does not have much in terms of video card ram then it is better to have lots of prims with the same texture.
But on the other hand if they have lots of video card ram and want the best possible view it is better to have layered alpha textures.

Also keep in mind that the new "Object occlusion" really only helps if you place "Invsi prims" in your windows. And even then it really only helps when you are inside of a building. Anything within your draw distance is drawn regardless of if it is visible when you are outside.

Where are you getting that information?


Yes.


Interesting. I can see how the full bright would help since it eliminates shadows, but I'm not sure the blank texture would serve better than any other that's already cached. Since SL doesn't use any procedural shaders on prims, wouldn't any collection of pixels be just as good as any other of the same size?


New trend? What do you mean? Avatars have had the same number of clothing/skin layers for the past 3 years, and they're almost always alpha'ed.


Still not sure exactly what you're talking about. "Layering" alpha textures will result in sorting problems in almost all OpenGL applications, including SL. If you're talking about the clothing/skin layers on the avatar mesh, that's a little different, but I don't think that's what you mean since you mentioned prims here. If you're talking about prims, then overlapping alphas is almost never a good idea.


Huh? SL doesn't know what "inside" and "outside" are. All it knows is whether or not one object in your field of view is obscuring another. If the answer is yes, then the obscured object gets culled from rendering. That's it.

Try this. Stand outside in an area with lots of objects visible. Make sure occlusion culling is turned on, and check your FPS. Now rez a big box right in front of you, and size it so it covers as much of your screen as possible. Now look at your FPS again. It will be considerably higher.

I'd guess the 'blank' texture is useful in the sense it's as common as plywood (so it means less texture switches while rendering the scene, when as many items as possible share the same texture no matter if they belong to X amount of people) ... plus, it's 32x32 pixels big which is quite rare in SL ^^;

re: earlier point about the scripts and beacons. Keep in mind two scripts are rarely equal in the sense they don't necessarily need to use similar amount of resources, respond to same amount of events etc. For example, the 'butterfly' script is more than likely just a single procedure which sets up particle generator (which is then handled client-side) and then never runs again.. and for that matter, could be safely removed from the prim as particle generator attributes are property of prim and get stored with it.

there's some more in-depth info on scripts and lag in the LSL wiki:

http://secondlife.com/badgeo/wakka.php?wakka=lag

Prim Heavy Avatars

A linden's post in the technical section.

Even low end Graphics cards have a special function for doing a "Flood Fill". This command does not access an input texture while it fills the area and thus it is slightly faster.

Just change the color so that it does not stick out like a sore thumb when a few pixels leak threw the crack.

Im talking about the prim hair vs textured prim hair and the non-human AV's.
My avitar has about 50 curved hair prims all with the same texture.
I also walk around as a bowl of petunias sometimes.

The newer ones have layered Alpha textures, and yes the system does mess up, but you can't tell the differance as the hairs are all the same color.

According to the LL documentation if anything inside of the octtree box is visible all the objects in that box are drawn. The boxes are also larger the farther away they are from you. This means a building would have to be very big not to be rendered.

What I am saying is that you can improve the system by eliminating windows from your building by placing inviprims in the windows. The system thinks it's solid, but you still get to look out and see the sunset.