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.
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.
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…
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?