Not One Size Fits All

I'm all for people being more informed about how their viewers work, and so I was interested to see Cajsa Lilliehook's Under the Hood: The Debug Settings blog post. While it is all informative, a few of the recommendations offered point to the ways in which different inworld priorities sometimes clash. That is, what's best for making things look good isn't always best for how things run. And I would like to offer additional insight into some of these settings. This isn't meant as a dispute or a flame, and only in some areas as criticism; it's meant as a contextualization and an offering of additional information. If Cajsa takes us under the hood, I'd like to talk about what motor oil to use.

Those of us on the Phoenix/Firestorm Support Team tend to look at things from a troubleshooting angle, which doesn't always coincide with the priorities of creators or photographers. Unfortunately, some popularly recommended settings aren't universally ideal for all users, and we frequently end up with people asking for help for issues that were caused because they heard that a certain setting was "best." But best for taking high-quality photos, for instance, is seldom best for everyday use, and that distinction isn't always evident. My personal view is: if you're not experiencing issues, do whatever suits you. But a lot of people end up with a "So-and-So recommends it, so if it's not working for me, the problem must be your viewer" mentality, and that's never useful for problem-solving. Settings are not one-size-fits-all. Let's talk about the ones that sometimes bite folks in the tush.

"MeshMaxConcurrentRequests: 128"

Bumping this debug up is, indeed, recommended for helping mesh to appear. However: leaving it at a high number is neither recommended (by us) nor necessary for keeping the mesh rendered. Some people experience higher rates of crashing when this is set to a higher number (over 100 or so). Regardless of whether you're having trouble, though, "requests" refers to how much communication is going on between you and the server, and the more requests are being made, the more it will contribute to sim lag because you're simply giving it more work to do. If there's only one person with their setting this high, the effect will be totally unnoticeable. But if we're talking about 40 people all sending >100 requests to the sim whenever mesh appears, then sad to say, this one will end up contributing to the lag you're all feeling.

So our recommendation is: bump this up when you need to, and return it to default once you can view the mesh (or have determined it's not helping, in which case you'll probably need to relog). We have some additional suggestions about viewing mesh on our wiki. You don't need to be sending that increased number of requests once it's rendered for you anyway -- it's not helping to keep it rendered, only to render it initially.

"RenderVolumeLODFactor: >3"

I have no issue with this recommended minimum, but a max and a couple of caveats need to be included, as well. We don't recommend turning this higher than 4. Although LOD sometimes needs to be raised in order to view sculpts correctly, there are two downsides to increasing it too far. The first, which affects everyone, is that at higher LODs, small prims such as some jewelry will become invisible. They will cease to render to you. Higher isn't better when it comes to LOD; what's best is finding the balance that works for you.

The other factor is performance. Although sometimes notecards packaged with purchases that direct customers to this setting say, "This won't cause lag," that's only partially accurate. It will not contribute to sim/server lag (that is, unlike leaving MeshMax at a high number, a high LOD won't affect other people). However, any setting that increases the amount of detail that you're rendering may affect performance at your end. I'm not saying it will be a big difference. In fact, folks on higher-end machines with great graphics cards and lots of RAM probably won't see a noticeable impact at all. Those of us who slug through SL on low graphics to function will be seeing more of one.

To see if and how it affects you, just go to an area with lots of objects, open up your Stats bar (Ctrl-Shift-1 on all viewers), and keep an eye on FPS. Toggle between a lower LOD, like 2.0, and a higher one, like 4.0, without changing anything else at all. Some people won't see a noticeable change. Others may be surprised by how much of an effect it has. Personally, my FPS changes by about 25-50% between those settings (i.e., if my FPS is 20 at an LOD of 2, I'll usually see it drop to around 10-15 when I turn LOD up to 4, though it depends on how many objects are present). What happens to me is not necessarily what happens to others. In fact, the whole point is that such results are not generalizable. So we prefer to recommend a range of anywhere from 2 to 4 for LOD, rather than any exact number. If you choose to turn it higher than that, simply be aware that if you experience the vanishing miniprim problem, that's what caused it and what you need to revert.

"RenderUnloadedAvatar – Load avatars in your view."

Although we don't have a strong recommended setting for this one, it's important to know what it does and doesn't do. It's strictly an aesthetic preference: Do you prefer to see ruths or do you prefer to see clouds, when avatars are not fully loaded with their own body parts? If you like ruthies, have this set to True. If you like clouds, have it set to False.

If you want to fix the actual problem causing the ruths or clouds, however, you can pretty much ignore this setting.

The issue is bake fail, and our Phoenix page for troubleshooting will apply to most V1s, while our Firestorm page will apply to most V3s.

If you're not planning to fix the bake fail when you see it, you can have RenderUnloaded set however you want, but if you're going to work on it, it's probably best to set it to False. It can sometimes be harder to tell whether a fix worked or not when you're partially rendering the avatar. On the other hand, if you know what to look for, as a student in one of my classes recently pointed out, rendering the unloaded avatar can help you figure out what body part needs to be added or replaced. I've used this setting to do that myself. However, the important thing is realizing that switching this setting on does not, in and of itself, fix any actual issue. The problem will still be there; it'll just look different, and only to the person toggling the setting.

"NoInventoryLibrary"

At first, I was only going to make a quick comment that Firestorm users won't be able to set this to True without doing some finagling with command line parameters outside the viewer. The Library is needed to build the FS Bridge, which is used for script count, radar accuracy at long distances, some aspects of double-click tp in locations with landing points, and a couple of optional things, so it reverts to "False" on relog and, yeah, annoys people who want to get a more accurate inventory count. (The Library currently contains exactly 2210 items, in case anyone was wondering.)

Then I noticed that on the blog post that inspired this one, it is included under "Performance"-related debug settings, so I thought I'd do a bit more rambling.

Inventory size can affect certain aspects of inworld experience, such as login time, and when you do an inventory search or open a new inventory window, having more items in there will cause the search to consume more memory. But it won't affect the factors that we usually refer to as relating to "performance": lag, freezing, and crashing. When you're not interacting with your inventory, it's basically inert, so if you're concerned about performance, hiding your Library probably doesn't belong at the top of your to do list.

As painful as it sometimes is to hear, lowering your graphics settings will make the biggest difference when it comes to improving minute-to-minute performance. Settings like those mentioned earlier. Lower MeshMax may correlate with higher performance. Lower LOD may correlate with higher performance. Even RenderUnloadedAvatar is more likely to affect performance than hiding your Library: a fully rendered (albeit partially loaded) avatar is more demanding to draw, client-side, than a particle cloud, which can itself be made even less demanding by reducing particles to zero and rendering it as an "egg."

So although hiding your Library has some use, it's pretty limited. As a side note, if you ever use Character Test, don't hide your Library, as it will not work if the viewer can't access the Library's Girl Next Door and Boy Next Door avatar parts.

To close, I'm going to acknowledge that the recommendations I give, both personally and on behalf of the Phoenix/Firestorm Support Team, are given primarily with troubleshooting and the prevention of future problems in mind. That may not be everyone's strongest priority. People run on a huge variety of machines in Second Life and they do at least as many different things on the grid. 

All settings changes should be approached as a matter of preference, with both the pros and the cons made as explicit as they can be. What's good for one person's graphics could be crippling for someone else's performance. What I would like to see is not necessarily that recommendations like these not be circulated but that there be more contextualization of them, as well as more of an awareness of how there are drawbacks to nearly any graphics-related settings and how circumstances and needs differ among SL users. I am a fan of experimentation and finding what works best for you, while learning what it is that the different settings are designed for.