Revisiting the issue of texture-induced lag in Second Life: A case study

I had written about the issue of lag before, and before me, Penny Patton had done the same, and I think very little has changed for the better since then. Most of the “lag” we experience in Second Life is blamed on Linden Lab, whose engineers are always accused of basically not knowing what they’re doing. Rarely does it cross our mind that we, the users – from consumers to content creators – are doing something wrong.

Second Life, and the same goes for OpenSim and other similar virtual worlds, is a 3D environment, where data is exchanged and processed in real time, both by the server and your computer. Additionally, Second Life (and its clones) only supports raster textures, which means that, as you move closer to an image or stretch it, it loses definition. Worried by this, content creators tend to stuff their creations with textures of the highest resolution that is allowed in SL: 1024 pixels x 1024 pixels. This puts a lot of strain on your connection, on SL’s systems, and your computer, and you get lower frame rates, sluggish response to controls and chat/IM inputs, texture thrashing, and, eventually, crashes.

In my previous post, I had provided a table with the file sizes of each texture size, which I had taken from the official SL wiki’s Good Building Practices page. I’m providing it here again.


A chart showing how much graphics card memory the various texture sizes we might use in Second Life. take You can also find it HERE. Click on any image for its full-size version, which opens in a new window.

Many of these high-resolution textures are actually unnecessary: Zoom in as close as you like on an in-world engagement ring adorned with a 0.3 carat diamond (which is a perfectly good size for a diamond in RL), and it won’t fill your viewer window to the point where you need a 1024×1024 texture to do it any kind of justice. In fact, I’m here to tell you that, even if you’re using a 4K monitor, you’re unlikely to need more than a 256×256 texture for the gem.

Many other content creators choose to use different textures for the various instances of the same component of an object. Some, like Apple Fall who makes “shabby chic” furniture and builds, can’t help it: To properly mimic an old, careworn table, armoire, credenza, or house, you need to depict uneven wear and damage patterns, and this creates the need for using multiple different textures, even if the basic geometrical objects are identical. But there are occasions when this is unnecessary and unjustified.

I actually have a perfectly good example of this. It’s the full-perm BC – Pool Table by Bethi Catteneo, which is not exactly ready to use, right out of the box.

First of all, its proportions are, typically for a product used in SL, completely out of whack. Not only is it oversized, but, when you stretch it to bring its width and length down to the proportions of a real pool table, it’s too low. So, you have to start fiddling with the size of the legs and the decorative panels, and with the positioning of the bed (the cloth-covered playing surface), the frame with the cushions, the pockets, and the metal parts under the pockets.

Second, its root prim is not the bed, or the frame, or the shadow mesh. No. It’s one of its eight legs. This makes positioning and rotating the table difficult. Third, the glossiness and environment settings for the specular maps are excessive. Fourth, it uses – or so it seems – a different texture for each of the middle legs, a different texture for each of the outer (corner) legs, and a different texture for each of the decorative panels.

To make matters worse, all of the textures on this table are 1024x1024s. Now, all of these problems can be easily fixed by a somewhat experienced builder. But there’s also another problem, which I simply can’t fix: On the rear side of each decorative panel, the arched part is hollow in its back, and has no texture face. Let me show you what I mean:



Yes, so the only way to deal with this would be to not cam down there. This is the only issue with this table that can’t be dealt with in a straightforward manner. Now, let me show you the impact of the decision to use only 1024×1024 textures.

The display weight of the pool table as it is, with its multitude of different textures for identical components.

The display weight of the pool table as it is, with its multitude of different textures for identical components.

Now, I’ve resized to RL size, unlinked and reassembled the pool table, but have made no other changes. As you can see, the display weight (i.e. the strain caused to your viewer by the textures) of this piece of furniture is a rather non-trivial 14332. I had to do something about it. And I did; I unlinked the middle legs and replaced all of them with copies of one of them. So, I had the same texture on all of the legs. One 1024×1024 texture (3MB) instead of four. Not bad. I did the same with the corner legs. I did the same with the decorative panels; replacing the ones on the narrow side, though, was trickier, as the X dimension of the long side’s decorative panel corresponded to a different dimension on the narrow side’s panel. However, it was nothing that couldn’t be done. So, I have used eight copies of the same decorative panel, and all of them have the exact same texture. What have I achieved? Let’s see…

By using copies of the same leg(s) and decorative panels and, therefore, reducing the number of different textures used, I cut the display weight down to 7661. Much better.

By using copies of the same leg(s) and decorative panels and, therefore, reducing the number of different textures used, I cut the display weight down to 7661. Much better.

The display weight was cut down to 7661. Much better, but things can be further improved. I intend to resize the shadow to 256×256, the decorative panels and legs’ textures down to 512×512, and also the textures of the metal parts, and the specular maps will, too, go on a diet. Mind you, with the changes I brought about, there was no detrimental change in the table’s appearance. In fact, I also reduced the glossiness of the table and made its shine look sweeter and more realistic.

Bethi touts this as “[o]ne of the nicest looking pool tables in SL”. Is it? Yes, it is. If you’re prepared to put some work in it, it can look really nice. And, as I’ve demonstrated, you can make it be lighter on your land and graphics card, as well. But, you must be ready and willing to “break stuff”. After all, that’s what copy/mod permissions are for, and this product comes with full permissions. And this brings us to the one-billion-dollar question regarding lag: Do you want to be part of the solution, or do you want to be part of the problem?




7 thoughts on “Revisiting the issue of texture-induced lag in Second Life: A case study

  1. Great article although you seem to implicate users as the problem when it seems more likely that content creators aren’t making their products with optimised textures. Even a relatively new builder knows not to use multiple textures when copying the same part with the same texture is better.

    1. I don’t seem to implicate the users. I do implicate them. It’s everyone’s responsibility to keep lag down, regardless of whether they’re a content creator or a consumer. As a consumer myself, I do my best, as you’ll see in previous articles of mine, to optimise the stuff I’ve bought from others.

    2. It’s one of those things Leighton, that is everyone’s responsibility, if creators are making high lag stuff, they only keep making it because people keep buying it, (speaking of SL). It is kind of a catch 22 in some ways .. Non-Creators , don’t want to understand how things work, they just want to use it, yet the things they use impact their experience, and they blame the experience.

  2. It is much worse than you think. The graphic showing image sizes is correct, but only for an uncompressed image, and not one inside the viewer. The server compresses them. But the opposite happens at the viewer. The SL viewer uses a technique called “MipMap” for each texture to let it handle the Levels of Detail. Just as prim sizes change with distance, so do the textures. .

    As an example taken from the official Image System document, when a 256×128 texture is loaded, the following textures are also generated and loaded: 128×64, 64×32, 32×16, 16×8, 8×4. This incurs a 33% increase in the amount of texture memory consumed, but makes a significant improvement in performance and visual quality. This is done to every texture in the viewer when it is downloaded. Your figures only show the original size before upload, which is irrelevant.

    So you have to multiply your above image sizes by 133%. Also, the texture could have an alpha. That makes a 1024X1024 texture with alpha not 3 megabytes, but 4 megabytes (4*8 = 32 bits) and then you have to multiply by 1.33. This means a 1024 X 1024 can use up to 5.32 megabytes!

    An older GPU has 512 Megs of RAM, and even a new 4 GB monster GPU can use only 1 GB of texture memory due to viewer limits. That means you can fit only 96 max-sized 1024X1024 textures in the GPU before all image rendering changes to the much slower CPU and PCI Express bus. Say goodbye to those hundreds of gigahertz GPU cores! For 1 GB, the max is 192 textures. Frame rates drop like a rock.

    More details on mipmapping and the rendering pipeline are at and for the general public at wikipedia at

  3. hi, i’m an sl resident.. just a buyer not a creator nor designer.. i’ve just moved to a new land and started buying stuff and decorating.. i never knew about all these stuff.. but when i’ve filled half of my land with pretty apple falls stuff and those lit up trees from HPMD and other pretty mesh stuff, my place starts to lag like hell. I have a lot more prims so i was wondering why does it lag so bad. So here i am reading this and trying to understand. This is a big frustration for me since i like pretty mesh stuff and i know most of them use high textures which causes the lag. And had been spending so much on them. So, my question is.. do you know some good brands that actually give a thought about textures but looks pretty/realistic all the same (since low LI does not equal to low lag). Correct me if i’m wrong. I am not familiar with modifying the objects like you did up there, the least i can do is to not buy products that causes the lag in the first place.

    1. Well, as I wrote, Apple Fall uses almost exclusively 1024×1024 textures, and his builds use far too many of them. There are some brands I’m aware of. You can try Trompe Loeil, by Cory Edo. Another brand you can try is Scarlet Creative, by Charlotte Bartlett. There’s also Barnesworth Anubis, if the style of American suburbia is more to your liking. These are three that come to my mind immediately.

Comments are closed.