Lag Myths Dispelled
Fashion shows have always been popular in Second Life, and with the current generation of highly talented fashion designers bringing a unique — and very realistic! — touch to high-quality clothes in SL, it’s interesting to see how, in a little less than a week, people have been talking about “rules of conduct” on a fashion show.
In fact, they’re much less “rules of conduct” but guidelines of what you’re allowed to wear or not when attending those shows. So far, so good (fashion shows in Maoist China weren’t a pleasure to attend…), but strangely enough, those “guidelines” are based on an incorrect perception of the hugest problem on those shows: lag.
While it’s undeniable that all highly attended events are laggy — it’s a limitation of the technology — I was surprised to see that almost all “rules” are based on very old limitations of the SL technology, which plagued us in 2003-2005, but that have since then be “fixed” by Linden Lab, as both the client and the server software have dramatically improved.
Improved, yes, but the lag is still with us. And, in a desperate attempt to fight down lag, people are coming up with ancient “recipes” for fixing lag — unaware that they’re not really helping out, but just repeating old myths, that simply don’t reflect the state-of-the art of LL’s technology these days. Lag will remain with us for many more years, but not for the same reasons we had it in 2003-2005.
Read Brace Coral‘s, Hamlet Au‘s or Ana Lutetia‘s blog posts on fashion show lag… and then let’s take a look at those myths, why they are still popular enough to be part of the “rules of conduct”, and, well, what we can really do about fighting lag using the technology of 2008.
And let’s enjoy those fashion shows!
Myth #1: Scripted attachments create client-side lag.
In fact, this happened to a degree back up to late 2005. LL has introduced a new scheduler somewhere in 2006, and since all scripts run on the server, what they did was to “slow them down” until they don’t bother the server’s multiple activities — namely, tracking avatars. During 2002-2005, it made sense to remove scripted attachments, since the server gave them a lot of priority in its scheduling, thus having little time left for the other, higher-priority tasks. Nowadays, scripts just… run slower. But — and this is the crucial bit! — more scripts don’t mean that everybody suffers due to server-side lag! In effect, what happens is that the scheduler lowers their priority, handles the “important stuff” (avatar tracking, texture loading, public chat) first, and only when there is a spare cycle or two will run the scripts. So, if you’re wearing a scripted attachment, it won’t affect the server much. You will just notice it running slower and slower. There is no need to detach it any more, and for almost two years this has been the case.
Myth #2: Particles also generate server-side lag.
Particles might have generated server-side lag at some point in LL’s history, but since I’ve been in SL (mid-2004), they are 100% client-side. This basically means that a fast GPU + CPU will have no trouble at all rendering all the 4096 particles by default. If everybody’s got bling on and are generating 10,000 particles, you won’t see them anyway — but just 4096 at a time. If your graphics card or CPU can’t handle 4096 particles at the same time, turn it down: you have your own configuration set too high anyway, and you should tweak it down to what your comnputer is able to handle! If you’re still skeptic that particles are a local issue, well, turn them off temporarily with Ctrl-Alt-Shift-= (see http://wiki.secondlife.com/wiki/Help:Keyboard_shortcut_keys for a complete list). In any case, your particles will not affect the server (who has no concept or use for particles) and won’t slow it down. People who are pushing their computers way over their limits should learn how to tweak them to get the best performance anyway — and yes, my 5-year-old laptop can render everything at 20 FPS or so if I turn everything down!
Of course, each of us would like to have ultrafast performance on low-end, ancient computers — but that’s not the point. If your computer can’t handle so many particles, don’t push it and complain that others are affecting your experience! SL is still beautiful with 2048 or even 1024 particles, and that will immensely help your graphics card to render everything properly on a busy area.
On a side-note… flexiprims are also handled client-side, not server-side. The server has no clue if the prim is a flexie (or a sculptie), so it takes exactly the same amount of server time to track down a flexie/sculptie than a plywood cube. So, the same rule applies: if your client is lagging because of flexies, you have the settings set too high for your graphics card (flexies are rendered on the GPU hardware) — you can start by lowering the “flexie mesh” (one of the options on Preferences) or simply turn them off completely (there is an option for that too). Or, well, just focus the camera on the model’s flexiprims instead — flexies that you can’t see are flexies that your graphics card is not going to render, so they won’t affect performance at all.
Myth #3: Primmed hair generates huge lag (client-side and server side).
Again, this was the case back in late 2005, when primmed hair started to become popular. In effect, the major source of client-side lag are avatars, with their 7500 or so polygons. Naturally enough, if you have way-complex hairdos, these will have thousands of polygons, and render slower… right?
Welcome to SL in 2008. Linden Lab has developed very aggressive culling and occlusion strategies, meaning mostly that attachments viewed from afar will have way less polygons for your SL client to render. With “way less” I mean that a hairdo with 100 prims, which might at some time have as many polygons as a whole avatar, will, from a distance (say, 20 m), have perhaps just a handful to render. Now obviously 100 avatars with 100 polygons, viewed from a 20 m distance, will have more polygons to render than a single avatar very close up! But… that’s not how one works on a fashion show… you’re not looking at the audience, which is far away when you zoom onto the gorgeous models on the catwalk. When you zoom in to a model, you’ll only get her avatar and attachments rendered with the whole lot of polygons — while the audience fades into the background and is aggressively culled down to a handful of polygons, pretty easy for your hardware to render. If you wish to do a group shot, showing the audience as well as the models, it means zooming out to fit them all on the picture — and, again, by zooming out, the polygon count gets automatically reduced!
So what should you do?…
On the other hand, if you don’t want to turn any setting down, and enjoy your graphics card overheating (believe me, I’ve blown up a few myself!), there is a very simple trick: don’t look at the audience. Focus your SL client on the catwalk only. Since mid-2006 or so, the SL client will thankfully ignore anything it can’t see (another change which has come with the times; long are gone the days where a particle emitter behind you would affect client-side lag!). Alt-Zoom on what is the focus of the show and ignore the rest. In any case, the golden rule is that others are not going to affect your computer’s performance — client-side lag is only your problem!
So, to recap: up to 2005, SL did indeed render all those millions of polygons in full, since they didn’t use any culling strategy, and detaching your hair would make a difference. A huge difference, in fact! But this is 2008, and the SL client works in a completely different way; in fact, it tends nowadays to render almost a constant number of polygons all the time, culling the meshes down as you zoom out, adding more polygons as you zoom in (but the background gets occluded anyway and won’t interfere with the rendering if you’re zooming in very closely!). Granted, none of this is “perfect” yet, but the difference is HUGE!
Still, urban legends and myths about SL are still with us, even if the technology advanced quite a lot. The difference is that back in 2004, most people around in SL were computer nerds who patiently explained what happened, and we picked up those “old tips” and got them perpetuated over the years. As SL grew in number of residents, the number of computer graphics experts remained the same, and they never explained to a large audience how things work in 2008… so we’re stuck with the old myths, and keep repeating them over and over again, even if they’re just plain wrong!
So why are we still lagging, if everything’s so cool and perfect? You might have noticed that on some of the fashion shows there is an “attachment nazi” yelling at everybody (and sometimes even banning people) to remove all attachments. As an increasing number of people comply — you can see jewelry, hair, sometimes even shoes, promptly getting removed — lag does not decrease. Frustrated, the “attachment nazi” continues to yell, over and over again, to have people remove their invisible attachments — AOs, multitools, facelights, and so on. There is no way to know if they’re being removed or not, so the session usually ends with the “attachment nazi” insulting the audience that is still “hiding some scripted attachment somewhere and causing the whole sim to lag”. But, in fact, most people — strong believers in the old myths — might have, indeed, removed all their attachments.
But the sim will still lag. Why?
Lag comes in all sort of varieties. Place the catwalk facing a sim border with nothing but the ocean behind it, and create lots of opaque prims behind the stage — and the lag will suddenly drop immensely. Why? There is “nothing” behind the stage to render, so the SL client will be superfast. Turn the stage towards an open beach, complete with marina, boats, a lovely strip of land full with houses and delightful gardens — and everything will lag like crazy. Sure, it’s beautiful — but unfortunately it means that the SL client will now have to worry about all those thousands of prims, all those swaying Linden trees, all those reflections on the water — instead of rendering the models on the catwalk. So, positioning the stage correctly will improve things dramatically.
Then, although the SL client is much better at its rendering strategy, and in spite of the huge performance improvements from the new script scheduler (Mono will improve that further), the simple and plain fact is that the sim server will have a lot to do on a sim full of avatars. First and foremost, skins. The old rubber-Linden-skins have just a handful of KBytes to render; any new-generation skin (from 2005 onwards) is megabytes in size (due to the increased detail), and we have three textures to load: head, torso, legs. 3 MBytes per avatar at a minimum; 100 avatars on the audience, that’s 300 MBytes to load. And where do all the textures come from? You guessed it — from the sim server. Which has to send those 300 MBytes to 100 avatars, or 30 GBytes total. So, on any busy event, we have the poor sim server struggling to push 30 GBytes downstream to all the unhappy and laggy avatars around. There is no way to avoid this step!
… surely people are not going to suggest that we also drop our skins and the detailed clothes, and run around naked into white Linden undies? Of course not. So, we suffer huge texture lag — and blame it on attachments
Well, attachments have problems, too! The more detailed they are, the higher it’s likely that the creator has just photosourced something and repainted it on Photoshop, for a beautiful 1024×1024 texture that looks gorgeous when zoomed in — even if it’s just a tiny detail on a earring. Now, although the number of polygons get dramatically culled down when viewed from a distance, the texture still has to be downloaded to your computer — and that’s additionally to all those lovely skins! And, on average, each prim has seven textures to load. 15,000 prims, that’s 100,000 textures, or 100 GBytes (on average), assuming that you’re loading them all (which most people aren’t). PLUS all the textures on the attachments!
“Ah-hah!” I hear you say, “So, after all, there is a good reason for people to drop their attachments, right?” Well, yes and no. It all depends on the content creator. For instance, I have 70-or-so-prim hair… but… it only has one texture for the whole hair. That’s as bad as Linden hair, which also needs to load one additional texture anyway! So, assuming you’re using one-texture-hair (which most of the best hair designers know how to employ successfully), you’re actually not putting a huge strain on the infernal texture loading, even if you have 100 prims on your hair! (note that Linden hair also has a huge amount of polygons — as many, in fact, as 100-prim-hair! — so for the purpose of the polygon count, which is what really creates client-side lag, it’s about the same)
Of course, someone coming in with a 2000-prim-hair, where each hair prim has its own 1024×1024 texture… well… those people should be shot on sight
Note also that most jewelry work the the same way. You might have 100 prims on your bracelet, but a professional jewelry designer (and fortunately we have thousands of those in SL) might just use one or two textures — and for jewelry, they can easily get away with 64×64 textures, since things are so tiny (which means that even at a short distance, the SL client will drop polygons very easily). The good ones are all done like that. Similarly, even shoes are done with few textures, and sculptie shoes are even better — although they have one dramatic issue, which is the “invisiprim” script (which lags both the server and the client). Although we seldom hear the “attachment nazis” complain about shoes, but focus only on the poor AOs, shoes are actually quite worse for lag — even if they are low-prim (like sculptie shoes) and have no scripts for bling, walks, or heel sounds. But… they’re so lovely to wear (Who uses Linden shoes these days?)
- Client-side lag is caused (mostly) by insanely-high-polygon count; avatars and Linden hair/skirts are one of the major sources of high polygon count.
- Server-side lag is caused (mostly) by textures that need to be uploaded; avatar skins are the major source of texture upload.
- Badly done attachments (with too many useless prims with insanely huge textures on each face of each prim) and badly built catwalks and stages are a major source of server-side lag.
- Invisible attachments create zero client-side lag. Shoes create more lag than AOs or multitools. Particles don’t lag the server at all; if they’re lagging your client, you have far too high settings on your Preferences.
But ultimately, removing scripted attachments, bling, or hair won’t help the lag a bit — if you’re allowed to keep your skin and prim shoes! That’s why the “attachment nazis” can ban as many people they want, “suspecting” hidden attachments somewhere, but the lag will not improve… it’ll only get the audience furious.
Finally, even if everybody used rubber-Linden-skins with just white undies, things would still lag on the client. And this is for a simple reason: there is a limit to how many textures (even small ones!) that your graphics card can handle. If you have more textures to render than your graphics card has memory, you’ll always lag, as SL swaps out textures to computer memory (and in extreme cases to disk). This happens all the time. The reason why some games and virtual worlds never lag as bad as SL is because professional graphic designers and 3D modellers know exactly, for a specific scene, how many polygons are going to be viewed, and how many textures need to be in the graphic card’s memory for that scene. Also, it helps a lot that these games have static content that is fetched locally from your hard disk (so you don’t need to have a server pushing 30 GB of textures during an event!). We have no luck in SL: there are always textures to load, putting a strain on the poor server…
So why is it important to dress good on a fashion show? We go there to look at the models on the catwalk, right?
Fashion shows are social events, like going to a live music show, or a discussion, or dancing at a club. On social events, we dress for the occasion — and take pictures (or even make movies) — since that was always, in the past 250 years or so, the whole point of attending those events in fancy dresses. Yes, of course we want to see the models (as we also want to listen to live music or to the DJ…). But if we’re going to be there, we’re also there to be seen. This is natural, and also part of our social behaviour on such types of events. We interact socially by gossiping in IM (or in public even!) while we watch the show. If the “attachment nazis” force us to get Ruthed (the only avatar that does not require a Shape upload, since it’s a default stored on our disks), and the audience has to be a crowd of Ruthed avatars… what’s the point then? It’s so much better to watch the show on a video stream instead! Or, well, visit the fashionista blogs… where there is no lag (but also no social interaction besides a few comments on the blog posts).
Fortunately for us, Linden Lab has dealt with the issues of the “three myths” enumerated above. They’re no technical excuse any more for the “attachment nazi crowd” to impose us a “dress code” (or rather, an “undress code”). Of course the myths are very hard to dispel; they will persist for ages and ages, long after people have forgotten why we had them in the first place. So, quoting Brace Coral, “Have a Great Time” — and make the show entertaining and pleasing for everybody without “forcing” them to role-play Ruth.
Thanks to Ana Lutetia for the lovely pose She’s great at doing cute anims!