How we turn Second Life into a Lag Hell

“Lag Hell”. This is how Second Life has always been referred to by oh-so-many people throughout its ten years of existence. We often see people complaining about how laggy a region gets the moment a few avatars are on it – or, in some cases, how laggy a region is, no matter if it’s empty or packed full. The blame is invariably put on Linden Lab. Lag is always someone else’s problem. Oh really?

First of all, I’ll be the first to that Linden Lab have made many bad design decisions from the very beginning, and many of them are still haunting them to this day. But is it really so simple? As a matter of fact, it’s not. Yes, there’s much wrong with Second Life on the technical front. It has numerous limitations, but most of them could actually be worked around, provided content creators (from the complete beginners to the “professionals” out there) actually bothered to build and script like, well, professionals. Someone with far greater experience in the 3D graphics industry than I could ever hope to have has actually written about it. I’m talking about Penny Patton, who wrote an excellent post about this – but I’m going to revisit this issue anyway, in my own way, simplifying things to make them easier to understand for people like me who aren’t 3D graphics experts.

Now, what do I mean by saying that many content creators don’t build and script like professionals? Two things: textures and scripts. As a matter of fact, they are explained in the Second Life Wiki’s “Good Building Practices“, but not many seem to bother reading them…

Let’s talk textures first

On SL’s marketplace website, you’ll find many texture creators selling high-resolution textures (1024×1024, which is the maximum SL supports). I don’t blame them – after all, they give them with full permissions, so content creators (amateur and professional alike) can very well save them on their hard drives and manipulate them as they see fit. This manipulation also includes scaling to a different, smaller size, depending  on the size of the object (or the size of the face of the object) they’ll be applied to.

Yet, we see far too many content creators go overboard and say “ooh, I’ll fill my sim and my builds with super-duper-high resolution textures to ensure they’ll never lose definition when someone zooms in.” While it is commendable that someone wants  to make sure their objects’ textures won’t pixelate when someone zooms in, using 1024×1024 textures everywhere is unnecessary – and even stupid and lazy.

Penny Patton explains (and she’s not the only one to do so, as a matter of fact) that textures consume a lot of bandwidth to download, demand a lot of processing power from the sim so that they’ll be retrieved from the asset server (i.e. the server in which our inventories are stored) and delivered to us – and, to top it all off, they hog our graphics cards down, as the graphics cards need to store them in memory and render them.

I’ve you’ve been to a region where only few scripts are running, there are only very few avatars (or even none) and still you get pathetically low frame rates, now you know the reason: the region has too many large textures on the things that are in it. The chart below shows just how large files each texture size produces.

A chart showing the sizes of the files that correspond to the various texture sizes we might use in Second Life. You can also find it HERE.

A chart showing the sizes of the files that correspond to the various texture sizes we might use in Second Life. You can also find it HERE. Click on the image for the full-size version.

To cut a long story short, for the most popular texture sizes in Second Life, the files for 32-bit colour depth (this is required when we want transparency) are as follows:

1024×1024: 4MB

512×512: 1MB

256×256: 256KB

128×128: 64KB

64×64: 16KB

While for textures that don’t contain an alpha channel (24-bit colour depth), things are as follows:

1024×1024: 3MB

512×512: 768KB

256×256: 192KB

128×128: 48KB

64×64: 12KB

Penny Patton also explains that the viewer doesn’t allocate more than 512MB of the graphics card’s dedicated RAM to textures (and most people still have graphics cards with 512MB RAM anyway). When I raised this topic to Oz Linden, he didn’t know, so I guess I’ll take Penny’s word for it, for the time being at least.

As I wrote earlier, many content creators (amateur and professional alike) think that they need to use 1024x1024s everywhere, but this is not the case. You see, the  size of the texture you’ll need depends on (a) the size of the object faces it will be applied to, and (b) how closely a user is likely to zoom into the specific object. For demonstration purposes, please have a look at the attachment I’m wearing in the following picture:

Can you guess what size textures are used in the grey attachment with the blue-lit strip?

Can you guess what size textures are used in the grey attachment with the blue-lit strip? Click on the image for a full-size version.

Out of misplaced politeness and a desire to avoid stupid drama, I won’t name the  content creator that makes this cyberpunk version of the CString you see in the picture above. How big do you think this object is, anyway? At its widest, it can’t be more than 6 or 7cm. And as for its length, it really doesn’t seem to matter, as this can easily be taken care of with texture repeats. But really, it had three 1024×1024 24-bit colour depth textures and one 1024×128  (this one had an alpha channel, so its colour depth was 32-bit. So, its textures were a download of 9MB and 512KB, i.e. 9.5MB. And that’s without the sculpt map – by the way, have you noticed that sculpties are always the last objects to rez on a scene? Now, I’m sure you can guess how laggy this object was, without even taking its scripts into account: a listener for the HUD, colour changers, a resize script, a texture animation script for the light strip down the middle (even though it’s not necessary…).

So, what did I do? Well, the black gasket-like sculpts lost their textures, plain and simple. They were not necessary and were barely visible in the first place. The other two textures? I went into edit mode, opened the texture selection floater and saw the textures themselves. Obviously, I didn’t have them in my inventory and I couldn’t download them, so I took a screen grab, isolated the 165×165 (or so) square that showed the texture thumbnail, cropped it and turned the big one into a 128×128 texture, and the one with the alpha (the one on the light strip) into a 128×16. Total download burden for SL? 48KB and 8KB respectively, i.e. 56KB. Compare these two total file sizes, please. Also note that, due to the fact that the object is small, these small textures cause no loss of resolution or definition upon zooming into it at all.

It goes without saying that, once I sized this object the way I wanted, I also removed all the scripts from it. If you click on the photo above, you’ll see the full-size image, which was upscaled from my viewer’s 1366×714 window to 1920×1004 and cropped accordingly. Note that, although I do take snapshots larger than my screen size, I’m still rather conservative and I’ll explain why. “But,” I hear the snapshot size queens moan, “it’ll lose definition when we take snapshots at 6144×3840 or larger.” Well… Let me give you a little piece of mind. ALL textures in SL are raster images, which means that, the more you blow them up, the more they’ll lose detail and definition and even the smartest interpolation algorithms won’t make up for it. And also, let me remind you that resolutions higher than 24MP are really only meant for printing at 300dpi on super-high-quality photographic paper of A3 size or larger. When exactly was the last time you printed your SL snapshots on such paper? As a matter of fact, the pros (not the wannabes and the poseurs) even drop the printing resolution to 200dpi or lower when they need to print on super-large media, depending on how close they expect the viewers to get to the image…

So, to wrap it up: Don’t use lots of 1024×1024 textures on your builds. Use the smallest textures you can get away with and think while you build – oh, and read the damned Wiki.


Ah, yet another painful matter for every Second Life resident. We know full well that, without scripting, all objects in Second Life are as useless as making a doorstop out of solid 24-karat gold. They won’t do anything. They won’t interact with anything or anyone. So… If we want a certain object to do something, it needs to be scripted. Yes, but that doesn’t mean it’s OK to script ineffectively when you claim to be a professional content creator.

How many times have we seen objects that have a resize script in every prim they’re made of? Hair makers are notoriously guilty of this idiocy. So are shoe designers.

How many times have we seen hair with one colour change script in each and every prim? Or shoes? Or other fancy attachments?

Now, how many prims (oh, sorry – sculpts and meshes nowadays) does a typical hairstyle have? 150?170? 200? 250? I’ll take a typical example, from a certain well-regarded hair designer, that weighs in at 169 Land Impact. The sodding thing had 171 scripts in it! Each one compiled in Mono, of course, simply because that option was pre-checked in the scripting editor and someone was too stupid and too lazy to uncheck it – not to mention that code optimisation is something entirely alien to most “professional” scripters who write prefab code for content creators. I also ran into another design, which had 190 LI and an incredible 381 (!!!) scripts in it (one resize script for each prim/sculpt, one colour change script per prim/sculpt and, of course, the obligatory, dreadful and idiotic facelight).

And yes, there is information and there are instructions on making your scripts more effective. Here. Read it. And yes, Penny Patton wrote about that one too. Read her post, for crying out loud.

It’s not my problem, it’s LL’s

No, it’s not. Linden Lab developed Second Life and it has specific capabilities and specific limitations. Although it’s true that they’ve made many poor design decisions, they’re the ones who made the whole framework, which means that, if you want to make stuff that’s not laggy, you are the ones who will have to build and script effectively. If you don’t like SL, you can always sod off and try your hand at making your own virtual world that will not have SL’s or OpenSim’s (remember, OpenSim is very similar to SL, and many of the same mistakes have been made on these grids as well) limitations and weaknesses. But… Wait a minute. If you’re too stupid to write effective code in LSL, how exactly are you going to make that super-duper virtual world I just mentioned? Oh well.

So, yes, if you make laggy stuff, lag is your problem, and with your lazy-ass attitude you’re also making it everyone else’s problem. Which means that content creators need to learn to build and script like real professionals, instead of whining about how laggy SL is.




See also:




22 thoughts on “How we turn Second Life into a Lag Hell

  1. Well said, I am very guilty of using big textures but with all big textures I use, I make that choice, I choose to use them because I want big buildings but still have sharp detailed textures.
    I have historical graffiti on walls, 1920s advertising, lots of things that I really want people to see properly be able to read.
    So in many cases, with big objects, I choose 1024 on purpose, knowing they will load slowly but feeling that this is worth it.
    But I too find such massive textures being used on tiny objects, on repeated textures that don’t need it, etc.
    They are all over the place.

    And although I know LL isn’t keen on adding even more buttons to viewers, I do think that they should consider adding just one; “Adjust size”.
    Whenever you as a builder use a BIG texture, a window should pop up warning you about it possibly causing lag.
    And then you can use the Adjust Size button, its simple, when you click it the viewer asks you what size you want to transform the texture into, you get a few options to choose from and voila, a copy of your texture is made at a smaller resolution, free of charge.
    I think this will change the use of large textures dramatically.

    1. Forget about the “adjust size” button. It can’t be done, because LL uses JPG2000 files internally (which are raster images). It could be done if they hadn’t idiotically locked themselves in with Kakadu Software’s technology and gave their system the ability to also handle procedural textures, which can be upscaled and downscaled infinitely, with zero loss of detail and astonishingly small file sizes.

  2. With the things I do, textures for vehicles and clothing, I sadly discover that often 1024×1024 is simply not enough. Text is the first thing to become illegible and most of what I do pretty much revolves around text.
    Don’t exspect me to scale down anytime soon.

    1. The problem with text on textures shows exactly what an idiotic decision it was on behalf of LL to lock themselves in with the JPG2000 format (a proprietary technology owned by Kakadu Software) and not support procedural textures.

  3. I agree with Jo, I sooooo wish that there was a resize possibility in world to save time. I also use some large textures and know what i’m doing. but really what I do is try to use as many seamless textures as possible. if ‘high quality’ textures in SL had been equated to tile-able and small whenever possible instead of high resolution, we might have skipped the need for some of the nagging about texture sizes that seems to be the new trend. But I have never know a texture store to advertise low lag textures or brag about how small or low resolution their textures are.

    Everyone in SL wants everything they make to be the hero in the scene. We are not part of a paid game design team with an overall plan and sheets of specs to follow. Most of us never get even close to the sim designer level. The places we inhabit are also rarely created with an overarching view to a balanced use of resources. Because many residents make stuff for fun and each creation is precious to them. And some residents make stuff to sell and therefore want it all to be as beautiful as possible. Both groups have an incentive to treat each object as though it will be the hero in a scene sometime, somewhere. And that’s actually closer to the truth than that a game’s art direction team will scour through your store looking for low res objects to fill in some holes in the scene. < NOT gonna happen. However when we decide that corner needs a lamp, or the lawn really needs some grass, or a row of trees to screen us from the neighbours, we go buy the nicest lamp, the best looking grass and the prettiest trees we can find. Even if when we are shopping we are able to prioritise those 3 objects (or 300) in terms of overall importance in our 'scenes', the first use of resources that comes to mind will be either Lindens or land impact, not likely processing power required to render. And let's face it in the hands of really smart designers, large textures relying on crisp detail ARE and have always been a means to lower land impact.

    Which brings me to why and I also agree Laetizia that very often on the things I make 1024 is not enough or barely enough to get texture pixels on a piece. I do bake or place several textures onto one UV then upload that texture for mesh models. In case mesh you're not sure what I mean, picture a bronze sculpture on a stone plinth with a brass name plate. Made from sculpties or prims, that would typically have been 3 separate textures at 512 or 1024. Note I said typically, I realize the texture used could be much lower. I can instead through UV mapping fit all 3 textures onto one texture surface and then upload only that. Picture an image with some weird blob shapes of bronze, some squares & rectangles of lichen covered stone and occupying one corner a picture of a brass name plate with words. It might look like the collage of a crazy person with no talent as an image, but it's not an image, it's a diffuse map for a model. So in it comes, I always save textures like this at both 512 and 1024, hoping that 512 will be enough. It wouldn't be very likely on the piece I am describing, and in fact it might turn out to be the case that even at 1024, a separate texture will be required to make the words on the name plate readable.

    Which brings up another issue of textures and mesh that is quite noticeable to mesh creators. Every blogger in SL can call for using as few textures as possible and it was historically the right thing to do when sim building. I might have textured every single sculptie rock and wood plank on my sim with the same 2 seamless 512s. But that is not going to work with mesh, unless you want us to make mesh that uses texture like sculpties and prims did, meaning separate pieces wearing separately applied textures, no baked shading etc. You can certainly use textures that way if you're smart, and if you're really smart they'll be seamless. But you are using a lot more geometry and texture faces to do it and I think you are wasting resources. Even if you don't see the bits under ground, or the ends of the walls, underside of foundations and so on — the many many things in prim building that could be left plywood, resources are being used rendering them and serving them up.

    So, fewer textures suits situations with more surfaces. Fine. Is this preferable to fewer surfaces with more textures? I honestly have no idea in terms of resource consumption, but I doubt it is. Since everyone likes to use the example that professional video games wouldn't be made this way, I challenge anyone to show me the game made from prims, the game where the underside of every rock, and sofa cushion has been built and textured. Where every store front or house is an actual building with a door and an inside and a back side and even an underside (don't forget the spiral staircase and gazebo that won't even be in the run by scene). Would a professional game designer do that? No.

    Instead the store fronts would be like theatre backdrops, the stuff that wasn't seen in the shot wouldn't exist, which means obviously the gazebo and the spiral stairs, but less obviously the undersides of things, ALL surfaces not seen by the camera or unlikely to be seen by the players. And a great deal of geometry on what is seen would be replaced by texture information, great big ole crisply detailed textures made up of layers of information about not just color, but shine and refraction, the angle of reflected light, the deepness of the crevices and so on. There would likely be a separate set for each building front or perhaps small row of buildings, small props like the mailbox, the light pole and the scattered litter might all fit on one set, ditto each character would likely be one sheet and so on.
    How big would these textures be? Maybe as small as 1024 for the litter, mailbox and light pole sheet, but more likely 2048. And unless the buildings were off in the distance, you could expect them to be a minimum of 2048 and possibly as large as 4096. Character sheets are very typically 2048s and repeating textures (maybe the cobblestones) are sometimes as small as 512. I am told a size this 'small' is acceptable because displacement effects to add dirt and variety can be used later in the rendering process.

    Games try to use rendering resources efficiently by replacing geometry with texture. We can too. But you should expect more discreet textures in your scene and a greater number of larger textures. Soon some items will feature 2 extra textures, the specularity and the normal maps. Don't panic, not only do these textures not need to be as large as the diffuse, they can be repeated (bricks eg) and while they add to texture information in the scene they can potentially use far less in resources by removing the need for some 3D details made from vertices. What do game designers know that SL residents are only now catching onto? In terms of processor cost vertices add up fast and texture is relatively cheap.

    Which is why that chart that keeps being dragged out dogmatically asserting that no more than 5% of the textures in your scene should be 1024s might have made sense at some point in history. But it just doesn't now. Not only is it unrealistic, I think it's actually INCORRECT in terms of overall rendering resources use. Either that or them game designers everyone keeps nagging us about must be doin' it wrong.

    my apologies for the length of this diatribe. i should start a blog lol

    1. Garvie, I’m afraid that overuse of 1024×1024 textures is indeed a major cause of lag – it’s been confirmed by all the Lindens I’ve encountered in the UG meetings. Also, let me tell you that design is always a process where numerous compromises are made. As for the game designers doing it wrong? I highly doubt it.

  4. I am not disputing that the overuse of 1024s IS a major source of lag, I know it is. I am saying that we need to think carefully about what counts as overuse. It certainly isn’t as simple as breaking the textures you use into allowable percentages based on their pixel dimensions. Mesh encourages and requires larger textures because fewer pixels are left for information about particular parts of the mesh. In the example I described, the lichen covered stone texture might be 300 X 600 ish, then name plate 250 X 250 and the bronze bits fill every other available nook and cranny, all crammed onto one 1024 x 1024. Now maybe you think that’s too big and you’d be ok with it being 512 and a bit blurry because you weren’t planning to zoom in on it anyway. Maybe the size police can even demonstrate that 3 different maps at 512 each would have been preferable to one 1024 map. I honestly don’t know. But I would change working methods were that to be definitively the case.

    I’m not arguing for larger textures based on increased crispness or anything, but rather trying to explain what encourages the use of larger textures. Also I am suggesting (but again i really don’t know for sure) that based on what I understand of the game industry and 3D rendering is that the mesh statue wearing its 1024 is using fewer resources overall and will render faster than a sculpt or prim statue with more surface area or vertices and smaller textures. And it will render faster DESPITE its larger texture. That’s why info about shading and shape and shine and so on is turned into texture information and baked (rendered in advance). It’s to SAVE resources and render time.

    Granted SL is a bit different and everything prerendered as texture is gonna get rerendered as scenery. Do I think every texture in SL should as small as possible, yes I certainly do. Does that mean that I will agree that only 5% of the textures should be 1024 or that 1024 is always or even most often too big. No, I think that is ridiculous as a goal and as an assertion.

    BTW, next time some helpful inworld person hands you that chart (i’ve recieved it twice so that i could use it to help educate others), please note its size. It’s a 1024, which might have been for the sake of being deeply ironic, but I suspect is rather that at 512 one could not read all its valuable info. Maybe redesigning the chart and dividing it up into 4 256s would be better?

    1. I’ll start from the end: No, I didn’t get that chart in-world. I was directed to the link. 🙂

      Now, one huge problem I see is that SL simply doesn’t support procedural textures (basically, vector graphics as textures). If there was support for such textures, you can rest assured there’d be much fewer problems, as their filesizes are astonishingly small and they can be scaled infinitely, without loss of definition.

      But LL went and locked themselves in the JPG2000 jail…

    2. As for how overuse of 1024x1024s lags people to death, let me remind you of Alpha and Omega Point: I’ve been to both, on occasions when there no other people in the region. Even with deferred off (it wasn’t called ALM back then), I didn’t manage more than 3.8fps. With deferred on (but no shadows), I was down to 0.9. Also, an exhibit called “Ascension” was one of the two places where I crashed after two minutes or so of being there. Why? It was full of huge textures that choked my graphics card and made it give up. I understand that there are cases where 1024x1024s are necessary, but that’s beside the point. My point is that there are many applications where a texture doesn’t need to be that big at all. In fact, many people out there simply use 1024x1024s because they can, not because they have to. I’ll give you an example: I was using a certain texture for some pillars (their main part had a 0.70m diameter and a height of 3m). It was 1024×1024 and I had 2 horizontal repeats and 3 vertical repeats. In that case, did I need such a resolution? No. I could very easily get away with a 256×256, so I replaced the original, initial texture with a scaled-down version I made in GIMP.

      1. yeah, i mean i do totally SEE and the problem and the grey. to me the frequent offenders are vendors. you know, you get to the here’s everything in a box on the wall in a store. each box has a unique large texture, all boxes stay grey, shopper leaves (at least i do)

        thing i’m trying to get across is that if there are a lot of 1024s out there now, mesh is going to encourage there to be even more. but in the bigger picture, i think it will reduce lag and time for scenes to render, so this year’s pet peeve about texture size just seems ill-timed to me.

        it’s also a bit late to the game, since i think the problem really took off with the prevalence of sculpties and particularly the buy this to make your own kits. the kits frequently included large textures, because due to sculptie stretching and distortion, large textures are required. sooooo a whole mess of unskilled builders made a whole mess of things. but that’s kind of what SL is for right and those people aren’t listening to blog posts about content creation.

        we could for instead start encouraging baldness or barefootism or whatever, both of which greatly free up resources and reduce lag for yourself and others around you.

        but really as a texture maker & teacher, sim owner, and seller of lawn ornaments i am getting FED UP with being lectured about how i should use textures on my sim so that when the lecturer shows up bejangled and beribboned from their sculptie toenails or faun hooves, to their glorious mane of pride of the 80s hair they won’t feel lagged. *cough* not aiming that at anyone in particular. *cough* really

        not everyone thinks that SL’s pre-eminent value is as a forum for playing dress up. other people take other routes to personal expression.

        also, i thought that maybe if people understood more about how UVs get put together they’d understand why the textures get ‘seemingly’ large, but really in terms of texture efficiency are doing an extremely good job.

        procedural would rawk! but that’s a whole lotta programming for SL which already has its hands full. you can kinda make your own though then crop them, (except only some sorts of fine grain patterns will work). but textures as small as 8 px square can be uploaded and successfully applied, works for very subtle texturing – grains of sand, nubbly cloth type things.

        what would be really great and encourgage seamlessness in mesh would be an extra layer inworld for shading. baked ambient occlusion does not need to be detailed to be quite effective. for instance i just made a simple wooden chair in mesh that wears a 256 seamless woodgrain quite well. but it has no baked shading, so it doesn’t look all fancy mesh-like. if i do decide to make a shaded texture for it, it will mean rebaking to a larger texture, hopefully a 512, but very possibly a 1024. it would actually save me grief, time and upload cost if instead i could leave it standing around in any ole 256 seamless woodgrain, and import an AO which would be reusable for that chair (also a 256 or 512), then slap that in the shading window on the texture tab.

        hope that made sense 🙂
        now i say we focus on demonizing hair & shoes & primmy gazebos, and spiral staircases… puhleeze.

  5. Great article, it’s what I’ve heard of for years and tried to avoid. You can see the actual texture sizes in the texture console, and it is always jammed with enormous textures for no reason.

    We can and should do better.

    Want proof? While not done in Secondlife, this amazing scene is shot with a single 256 x 512 texture. Impressive work, fantastic when you see what can be done by with materials, uv maps, lighting, and god-like mastery of pixels. He has a write-up on this at

    But watch the video full screen first.

  6. In open sim you can use 2048×2048 or whatever size you wish!
    But of course one has to consider the amount of users on my regions, the fact that each has a dedicated cpu and 1giga ddr 3 (how is now for SL servers, 4 regions on a Cpu???) and my connection is 200 mega optical fiber!
    Still on Sl i do use only 512×512 and i some even less!

Comments are closed.