lag reducing ideas needed PLEASE

i've tried searching (please improve the forums search engine) to find hints, ideas, methods for reducing lag and have basically found nothing helpful.

my Mistress and i run a modest mall (open air market, plenty of manuevering room) in Tiretta and as with pretty much all malls, we have lag issues.

We are very proud of our open and unique look -- receive many compliments on the design.

However, we wish to reduce lag as much as possible to give our customers and visitors the most enjoyable experience possible.

Tried using a lag finder we found on SLExchange, but it basically said everything causes lag, so that was no help. There are very few active listens there, most vendors are JEVN which have to be clicked by the owner to listen.

One recurring theme i did run across in my futile search attempts was my own wish for when shopping i like low lag areas.

Any ideas of what to try will be most appreciated.

Some things

: no particles (client killer vary)
: no textures over 512x512, pref 256x256, tho this sucks :q
: no listen what so ever, these arent needed anymore seriously \o
: no repeating/texture switching wich reloads a texture every 10 sec or so (timers)
: dont use "set object light" use "full bright instead" this is a killer for those who use Local light , still see loads of places wich still do,
: avoid using to many toruses, another client killer.

Build with cubes, not cylinders or toruses.

Repeat a lot of textures, don't use anything over 256x256 for most applications.

Try to keep repeats per face down.

Keep listening scripts to a minimum.

Don't use too many transparency textures (windows, etc.), or at least transparency-on-transparency.

Are you sure about this one?

No. But in my tiny mind, it makes sense.

All good suggestions so far, but I'd like to emphasize what's been said about textures already, and expand on it a bit. The biggest reason malls lag so much is because of poor texture management. The average mall has gigabytes, in some cases hundreds of gigabytes, worth of textures in it, but the average video card can only handle a couple hundred megabytes, so they choke.

Consider this. Every 512x512 texture uses either 768KB or 1MB of texture memory, depending on whether it has transparency or not (transparency = larger). Every 1024x1024 uses a whopping 3MB or 4 MB. However, a 256x256 uses only 192K or 256K, and a 128x128 uses only 48K or 64K. That means, for example, that for every instance of a 1024x1024 texture in your mall, you're using up the equivilent resources of 64 textures at 128x128.

A lot of people do completely boneheaded things though, like put a 1024x1024 on a little .5M sign. Multiply that by the hundreds of signs and posters in a mall, and you can see the problem. It all adds up quick.

There's hardly ever a legitimate reason to use a large texture anyway. SL happens to be better at blowing up small textures to full screen size than just about any other program I've ever seen. For proof of this, all you need to do is put a small texture, say a 256x256, on a cube and then zoom in on it so it fills the screen. If your monitor is 1024x768, you're now seeing that texture at 16 times its normal size. Notice it looks almost as good as if it had been created at that size. This is one of the areas where SL really shines. As much as we all like to compalin about what SL is not good at, the things it does well, it does REALLY well, and texture drawing is at the top of the list.

If I were you, I'd make a hard rule that no texture in your mall can be larger than 256x256, and then restrict prim counts in order to keep the total number of textures under control. Generally speaking, 256 is more than enough detail to display product photos well. If people bitch that their stuff is too detailed for 256 to give it justice, I'd suggest that they set up a simple photo dispenser. Just have a button on each vendor that says something to the effect of "Click here for hires image." When someone clicks, the photo will be given to them, and it will appear on their screen, and only their screen.

The concept here is similar to thumbnails on a webpage. The mall is the page. Images on the page must be small so that the page can operate at good speed. If someone wants to see an image bigger, they click on it and they are shown a larger version that exists independantly of the page, so it doesn't slow the whole thing down.




Oh, and Lordfly, Reitsuki, the repeats per meter thing does make sense. The more times a texture is drawn, the more memory it eats up. However, a 256x256 repeated 16 times is still more economical than a 1024x1024 repeated once. Keeping the textures as small as possible is what's most important.

Chosen, your advice has always been impeccable but the repeats thing is a tough sell. Let me make sure I understand you.

If I have a 10x10 floor with a 256x256 texture. Are you saying it would consume more memory if repeats are set to 10 x10 rather than 1 x 1?

My understanding is, Open GL need only load that texture into your memory once. Then, when you look at that floor, the client renderer references the texture, does all the angular math etc etc then draws each pixel of the floor within eyeshot.

The only thing repeats do, is change the way the original texture is referenced when it draws each pixel for the floor. But it doesn't actually keep anything additional in memory.

As always, I could be wrong, but if I am then I may be misunderstanding some fundamentals about how renders work.

With malls also remember that the textures being displayed of the items in a vendor contents are frequently obscenely large given the size of the display. THis also makes lag and annoys customers that have to wait forever for the next item to load.

script wise sensors, listens and timers are frequently the big culprits (not lways but most of the time)

Light is horrible and unnecessary with FUll bright

Oh, great, mighty and wise Chosen, you've got a point there: SL is extremely good at upscaling, better than anything I've seen except for fractal generation expansion which is waaay to slow to be done at SL speeds.

Any ideas or informed guesses as to what they are doing that pshop 9 doesn't?

open gl renders dots instead of squares so its alot less noticable

and i dunno about psp9 but psp6 couldnt resize a blank white image without distortion (the gimp is really good at it tho)

Photoshop still does it better.

SL just uses trilinear filtering (if availible), otherwise it just uses bilinear filtering. Photoshop has options for bicubic (best), bilinear (fast) and nearest neighbour (worst, fastest).

However, if you have anistropic filtering enabled - that will improve things a bit still

How do you know exactly what type of upscaling SL uses, and why would trilinear be available somtimes and not at other times?

Aimee, I had originally thought it worked as you've explained it here, but according to an alleged conversation between Darkness Anubis and a couple of Lindens, SL actually renders each repeat seperately. Granted it's heresay since I didn't participate in the discussion myself, but in hearing Darkness retell it, I got the impression that the conversation did actually happen as he described it. If anyone has any hard evidence on this one way or the other though, I'd love to hear it.

Anyway, I don't think excessive repeats will make or break anyone's FPS all by themselves, but every little bit adds up. Any potential lag source that can be eliminated, no matter how small, is worth attending.



I don't know how it actually works, sorry. Whatever it is, the Lindens should get a medal for it.

Because it's not SL that's doing the upscaling - it's your graphics card. It's practically impossible not to do what the graphics card does, the framerate cost of throwing that much data at the graphics card would be extreme (let alone the CPU issues).

Trilinear/Bilinear will depend on your graphics card, older cards (circa GeForce2) will use Bilinear, while newer cards will use Trilinear.

Thanks for the info.

back to tile textures normally (so i would take a long guess that sl does this) dont eat up extra video memory, altho becuase you video card has to render that tile X more times it does bog clients down.

Now im starting to porduce 128x128 pixel tiles in quanity, and trying to sell them. im currently standing in a 29mx29mx28m castle covered in the things (the idea is to show how a good texture will cover a sloppy biuld heh)

The most they are tiled is 6x6 but range in all sorts of configs to fit the prims.

And i think by now everyone knows i run the oldest video card in the world

and at the most i will get a jitter from the "extra stress"

now if i bump up my draw distance the giant dragon casino set at mostly shiny(next door) kills me
(just incase you show up one day after i get this thing wired and open and you run like dirt heh)

and no offince to the fine ppl at giant dragon casino thing, it looks awesome

The problem with this is, you are comparing the render of a texture against the render of NO texture, which isn't exactly a test of tile performance. Going back to my floor example... Imagine you set up your cam so you are looking directly at my floor and it fills your screen completely. You then drop a 256x256 texture into it with no tiling.

With no tiling, that 256x256 image will fill your screen, and the renderer will have to calculate every pixel of your resolution. Now don't move your cam, and tile it 10 x 10, the same number of pixels have to be rendered and the same sized texture is still in memory. The only thing different is that when a pixel on your screen is rendered, the client grabs color info from a different part of the texture for processing than before (so that it will look tiled.) There should be NO difference in performance.

Now if I had an untextured floor (again positioning the cam so it fills up our screen), and in the corner I have one little prim that was 1/10th the size and it had a 256x256 texture, then yes, the fact that a small portion of your screen has to render a texture would indeed give better performance compared to having that texture tiled all over our eyeshot.

But that isn't really a comparison of tiled vs. untiled.

(And of course all this is wrong if the SL client generates a new, big texture when you tile as Chosen mentions but I am still a bit skeptical about this.)

i am just reporting on a slight degrade in performance on a dirt old video card, im actually decently "read up" on real time 3d.

The only performance gain i hope to acheive with my textures is the fact that sl has to cough up and transfer a handfull of 128x128 pixel images. Instead of a handfull of 256 or 512's and let the client deal with it

anywho i would like to be more informed on SL actually deals with this, becuase, personally the ony way we can all combat lag (rather it be client, sim, or network) is to have hard facts on what is cool, and not cool, to do in sl over a large scale.

I would love to see a "PERIODIC TABLE OF LAG" LOL. Some kind of chart that tells us how much of each kind of lag, each kind of design decision costs us.

The example I bring up a lot is the Texture vs. Prims problem. Say you want to build the side of a building with a door and a bunch of windows. You could do it with, say, a 512x512 texture that depicts the door and windows OR you could use no texture at all and build all the little windows and doors out of prims. The question is, how many prims does it take before you cross the line and it becomes wiser to just use a texture?

Builders are faced with these questions all the time and the answers can be complicated (multiple different kinds of lag, etc...) It would be great to have to boiled down to some rules of thumbs.

What is better, four different 256 by 256 textures, or one 512 by 512 with faces using texture scale and offset to display the appropriate quadrant?

RUR RUR RUR, and I was just gonna say one of those "food pyramids"--but for lag!--would add up too.

If there were easier ways to count by points and come up with a final score. A calculator, or a calculaggor, if you will.

You can turn on the advanced prim culler, your lag will reduce dramatically.. its not in the menu - you can only access it through ALT-F4.

You'll notice an increase in your perfomance nearly instantly.

I thought ALT-F4 activated the secret Linden-God mode.

You don't listen to my radio show by any chance do you?

Should I?