Wizardry and Steamworks/Viewer Optimizations
Intoduction
The followings should be considered suggestions that are heartily and highly open to debate because they may neither be entirely correct (or precise) and might certainly not work as expected on all the possible machines out there.
If you have used Firefox for a long time, recall their history. Let us see. First, they started off with a little browser like Google Chrome which was indeed incredibly fast (in fact, that is what Google went ahead and did, they took Mozilla and cut out all the useless stuff and released Chrome). Then, they started adding features... Sooner or later, they already had forks, such as LittleFox and even addons like FasterFox because the newly added features were so abundant that it ground down the machine every time you loaded up the browser.
Linden has taken a step towards a "lite" version by adding the alternative "simple" interface mode. However, that is insufficient. What we would need is a light-viewer with the irrelevant features turned off and the relevant features compiled-in. No bloat, no Twitter, no "integration" with your pet lobster, no crud added that we really do not need. Even so, the "simple" version provided by Linden barely lets you access anything. That, conversely, is too much of it eliminated.
No wonder that projects such as Firestorm are a complete failure: they expose too much to the user which is not relevant, nor useful. It is not that the viewer is bad, it is that it has too many features which are either obsolete, bugged or simply not needed.
We believe that the ideal is to create a new, "lite"-version of the viewer with most of the "options" compiled-in, sensibly. There is some progress made in that sense with Hippo Viewer, which receives an 86% thumbs-up rating (bear in mind that most projects have not rating at all). No wonder people like it, it is the closest to v1.x when things were straight-forward and uncomplicated. It makes up for a stable and fast viewer.
Premises
Here are some statements on which we base the following configuration suggestions:
- A bloated viewer is a slow viewer: Generally, the software tendency is to incorporate new features before fixing bugs. We do not know why this tendency is on the lose, however we will try to compensate for it by simply disabling everything that we do not consider either necessary or to have a considerable impact on the user-experience. Whenever you configure a viewer, try to eliminate all the possible features. If possible, turn everything off and start your way up from there by turning features on and deciding whether they are worth it. Sometimes this is something we can control, sometimes we cannot, for example: having to deal with Mesh bugs while groups are broken since 2007 (2007 was it?).
- Graphics should accompany you not drag you down into the gutter. Some features, such as shadows, are highly experimental and not implemented properly. The key is to drag the graphics slider to minimal and then start turning on things one-by-one, checking each time in-world whether that has any beneficial effect: move around, use control+alt+left mouse button to pan around and check whether the setting you just made is not slowing you down.
- If it half-works (sorta-kinda), turn it off. Goes without saying: if you feel that something is not properly done, do not risk it and turn it off. Turn it back on when the feature has become stable (eg: shadows).
- Writing to external media takes much, MUCH longer than writing to your internal drive. If you need a comparison, browse google for a comparison between ethernet, SATA, Firewire, IDE and USB for both internal and external drives. If possible, keep the viewer on your internal drive and put the cache on an external (fast) drive - Firewire is probably the best choice (until we get Thunderbolt technology).
- Writing, itself, slows everything down. All viewers have logging facilities that log almost everything to a file on your harddrive. These are not necessary and they can be safely turned off and unless you find yourself in constant legal turmoil (see Profile Generator) to check whether that's the case), there is no need to log your Instant Messages either - this may be a philosophical point and a debate you have to consider yourself. Legally speaking, you cannot use those log files anywhere else without violating the Terms of Service, making them rather futile in a legal context.
- Memory is, oh so, much faster than hard-storage. Generally speaking, RAM is precious and storage space is worthless. We have had the pleasure of having access to a machine with loads of RAM and have launched the entire operating system entirely in RAM without any kind of swap. You could not believe the speed of it, it was ridiculous. You remember the configuration suggestion in Windows, "if you have a lot of RAM, disable your paging file"? That is pretty much it...
- Voice. This is a nice bloat-feature of Second Life that is almost always unwanted. We have had some passes at stripping it out of the Singularity client completely but it is heavily tied into the messaging system as well. In our view, this feature should have never made it into the viewer, simply because it is completely useless and it frequently works badly. Skype, Yahoo or Live Messenger have a long-standing tradition of providing voice services and those are dedicated to providing them. if you really need voice, consider installing something like Skype and feel free to voice all day long. Keep the viewer free of it though, it never did anybody any good.
- Downloads are slow. Regardless of your set-up and your speed, Second Life is pretty much an online game that constantly requires you to download assets: textures, animations, geometries and... client tags. Yes, unless you really care to see who is using what known-viewer, then downloading client tags is really not necessary. Nor are the other network related features that require your computer to download them.
Imprudence
Imprudence is a fork of the 1.x Second Life client which seems to be the de-facto standard for a smooth ride in both Second Life and OpenSim metaverses. We are proud to document some of the settings that we made in this viewer in order to achieve a smoother user-experience. We do not know whether these settings will work for everybody, however we start from a few premises that should be common to all browsers and work our way from there.
We have successfully used the Imprudence viewer on our own grid (with a modified OpenSim version, named K-OS containing some homebrew modifications from Kira Komarov) and were able to cross regions without problems with minimal lag and maximal responsiveness. Video will follow soon.
Use the Built-In AO
Unless you really care about the breathing effect of your animation overrider, try to use the built-in animation overrider. It proves to be sufficiently standardized, based on ZHAO-II notecards and certainly releases the burden of a rather large set of scripts script. Most 1.x viewers support the built-in AO, and you may find it in Imprudence (and co.) and is shown in Figure 1.
The AO interface is pretty straight-forward, and allows you to load a ZHAO-II compatible notecard with animations. You can use your current favorite animations by:
- Create a new folder in your inventory and give it a name.
- Edit your current AO and locate the animations and dump them in the folder created in the previous step.
- Create a notecard, read on:
The syntax is very simple but may take a bit of punching in. A standard ZHAO-II compatible notecard looks like the following. This is an example based on a "Bubble" toy given to me not long ago by FailedNoob Resident:
[ Standing ]_SLC_BubST01(P4)|_SLC_BubST02(P4)|_SLC_BubST03(P4)|_SLC_BubST04(P4)|_SLC_BubST05(P4) [ Walking ]_SLC_BubWALK(P4) [ Sitting ]_SLC_BubTURN-L-(P4) [ Sitting On Ground ]_SLC_BubTURN-L-(P4) [ Crouching ]_SLC_BubTURN-L-(P4) [ Crouch Walking ]_SLC_BubWALK(P4) [ Landing ]_SLC_BubST01(P4) [ Standing Up ]_SLC_BubST01(P4) [ Falling ]_SLC_BubST01(P4) [ Flying Down ]_SLC_BubTURN-L-(P4) [ Flying Up ]_SLC_BubTURN-L-(P4) [ Flying ]_SLC_BubST01(P4) [ Flying Slow ]_SLC_BubST01(P4) [ Hovering ]_SLC_BubST01(P4) [ Jumping ]_SLC_BubST01(P4) [ Pre Jumping ]_SLC_BubST01(P4) [ Running ]_SLC_BubST01(P4) [ Turning Right ]_SLC_BubTURN-R-(P4) [ Turning Left ]_SLC_BubTURN-L-(P4) [ Floating ] [ Swimming Forward ] [ Swimming Up ] [ Swimming Down ]
Every line contains a list of animations separated by | and gives a set of animations to use for that particular avatar action. Let us take the first line:
[ Standing ]_SLC_BubST01(P4)|_SLC_BubST02(P4)|_SLC_BubST03(P4)|_SLC_BubST04(P4)|_SLC_BubST05(P4)
This gives us the set of animations to use for standing postures. In this case, this AO uses the animations: _SLC_BubST01(P4) and _SLC_BubST02(P4) and _SLC_BubST03(P4) and _SLC_BubST04(P4) and _SLC_BubST05(P4) for standing postures.These will be, by default, played sequentially, one after the other. However, you may also chose to randomize them (see Figure 2).
The last step is to place the notecard you created, along with all the animations it references in the same folder and drag it onto the animation overrider pane (see Figure 2.)
Using the built-in animation overrider is a great feature that reduces a lot of lag to yourself and others. It is also clean, supported and implemented in the viewer with no special quirks required.
You may even toggle a nice toolbar at the bottom by accessing the debug settings and enabling the built-in AO on/off toggle button (Figure 3.).
And finally, you can see an overview of how this is organized:
Note the inventory on the right where every animation is placed together in a folder along with the notecard.
Also, bear in mind that nothing stops you from placing dances in the [ Standing ] section of the ZHAO-II notecard for a nice stroll on the dancefloor.
HTTP-TCP or UDP
HTTP texture fetching, based on TCP, has been around for a while. The main idea is that in an environment where people use proxys to traverse networks, it may happen that a certain texture gets cached. Furthermore, HTTP is very common and less likely to be blocked by firewalls. TCP also has transmission-control, allowing the data to be checked and confirmed before asking for the next block. On the flop-side, UDP is designed to carry more data and largely faster without any sort of buffering. Similarly, TCP has a much more complicated header.
If you have a slow network and an uncertain set-up, we recommend using HTTP texture fetching. Otherwise, we could rather stick to UDP. A good article on the difference between the two may be found by googling (the first entry is on skullbox.net) for the difference between HTTP-TCP and UDP.
We consider HTTP texture fetching to be somewhat of a myth and a partial fail. It is good in some ways, but for a reliable network it does nothing more than slow down your experience. Every single packet has to be checked before it is considered valid. Nice in principle, slow in practice.
Run Multiple Threads
It goes without saying, keeping the viewer alive during rendering is a good optimization, especially if you have a multi-core machine.
Texture Memory
Ah, the good old trick to get the viewer to remember the texture memory across restarts. At some point, we believe the viewers will be updated to support more memory since we already see video cards with 2GB+ of VRAM. The related option to this one, may be found in settings:
Simiarly, you can see that we have left:
- Anisotropic filtering off. This setting chews a lot of the performance but does indeed increase the quality of the graphics. This is up to you. Again, any change you make, remember to check and see whether you are pleased with the results. If not, turn it off.
- Anti-aliasing. This improves the font quality. However, Mac machines seem to suffer from spurious bugs from this setting and, to be honest, the only real difference we are able to see is after the x8 setting which is a bit too much to pay for.
Turn Off Logging and Auditing Features
Every viewer has by default a lot of logging and auditing facilities. Generally, for the end-user, and even for the front-user ( :P ), this is never needed (there are other, ways...). Either way, this relates to one of our premises, the one that says that writing to the harddisk is expensive. Why terrorize your harddisk heads to write a log-file that you will never look at anyways? Why write the FPS to the log-file if you can just grab it from the viewer displays?
Apple Users
Apple Multithreadded OpenGL is a nice feature that has been around for a while and it is one of the first things we turn on in our viewers. It is a pretty slick way of parallelizing OpenGL on Macintosh machines. If it is not an artefact and the feature has not been abandoned, turn this on. We do notice some performance increase but check that for yourselves and decide. At best, we do not believe this will harm you at all.
Rim Who?
Pun ahead, our rimmings don't get any better either way we set this ( :P ). Turn it off. Anything that contains light and avatar should be kittied to null. Having a light in the backside is arguably scary.
Advanced Snapshot Options
This one is a nice feature, it gives you more options to chose from (resolution, refresh, etc...) when you take a snapshot. It does not consume anything and you can directly turn this one on. Of course, in the long run, one could learn to use a snapshot taking software package and rip this feature out of the code entirely. There are, oh so many snapshot taking programs out there that definitely do not go "bip" in-world and scare the Flamingo away when you photograph it.
Snapshot Quality
For some reason, the default value of this is 75. There is no point. Absolutely, no point in leaving it at 75.
Parallel Inventory Fetch
We noticed no major issues with this one. The idea is that the viewer will spawn a thread in background which will already start fetching your inventory starting from log-in, without waiting for you to open your inventory. Chose what we like, we will be bold and turn this one on.
Media Filter, SSL Verification and ... clothes protection?
Although media filter is not in the options of Imprudence (thanks!), it is the most useless feature ever invented. These three "security" features you have there are, in order:
- Security through liability dumping. Are you sure you want to connect to http://45.213.11.23/hmm.php? So, it is more secure if I get asked so I may shaft myself personally? No.
- Security through ambiguity and obscurity. Let us check the countless hosts we connect to that they are who they say they are. Face it, you connect to lots of hosts while in SL, whether it is streaming or media. Verifying that each one are who they say they are, will not matter to you too much. If you do your banking from inside the SL viewer, you should not have a bank account in the first place. It also does not say what that verifies. If it is a self-signed certificate, it might still be a legitimate website that does not wish to pay for Verisign.
- Security though... obscurity? We're not even sure if this is obscurity. It is misleading, borderline silly and very very funny. Turn it off. This compares well to the anti-bot protections sold on marketplace which are probably just dummies since we have already seen some "action" right next to one of those anti-bot protections - those are the REAL fraud, by the way. It was funny, the "deeder" even received a prize for staying in the region. With it, or without it, those who know, will rip your underpants off you, regardless.
Vectorize, Vectorize, Vectorize...
These two also gave a performance increase.
Sky
For some reason, the sky settings affect our machines the most. The sky setting, both in the Preferences pane and in Debug settings seem to decrease the performance substantially. Either way, the old particle clouds can be disabled safely. It does not seem to increase performance by much but if you can do without them, turn them off.
Also, in your graphics settings, try to play with the sky detail since that may indeed give you a performance boost on lower settings.
VBO and FBO
This is terribly hardware dependent. On a Mac, it seems that VBOs slow camera panning down and FBOs, although increasing performance, sometimes, on some machines, leads to some graphic glitches. You can play with both of them and see what suits you best since, when working properly, they do lead to a massive performance increase.
Advanced
The only really useful feature here are the:
- Disable login/logout screens.
- Disable teleport screen.
Since pulling the wool over your eyes will not hurt you any less if you do crash.
- Use the chatbar as command line.
The latter is a good way to perform some quick actions by just typing a command in local chat. Console users will love this one. Do consider though that every time you type something the viewer has to do some pattern matching to scan-in the string and decide whether it is a command or not. The same applies to the spellcheck. Unless you are completely illiterate, bear with the slurs. If people are terribly annoyed by your spelling, they will honk you for sure. Make them do the extra work, not your viewer.
- Increase rez speed via draw distance stepping.
This one should probably be turned off as well. It is limited by your draw distance anyways and just has the effect of rezzing stuff that is closer to you faster. We still left it on to squeeze some performance out but, in most cases, it should not be needed.
D-BUS
If this is what we believe it is and you are not running Linux, then it is useless. Turn it off.
Max Drag Distance
This will allow you to drag a primitive 255m from where you are standing. Depending on what draw distance you have set, consider raising this as we did instead of running after your primitive every time you push it around.
No Constraints
The two options:
- Disable camera constraints.
- Disable minimum zoom distance.
will let you zoom through primitives and zoom-in closer on smaller primitives. They are both good options and good features. Kira Komarov had to explicitly mention this a few times when building the Wizardry and Steamworks/Population Genetics and Selection because the sun in the middle of the dome was hard to zoom-in on if these options were not enabled.
The next useful are the two options:
- Double-click Action: Autopilot.
- Autopilot Style: Teleport.
which, unless the land is point-to-point teleport restrictive, will allow you to double click some land and you will be teleported exactly there. This is a great way to build and zap yourself around. The Phoenix viewer has an option that uses llMoveToTarget inside the Phoenix-Bridge, which bypasses point-to-point teleport restrictions. This is a very useful option and we look for it in every viewer we download.
Heads up!
These are two settings that will prevent you from plopping your head when you are AFK and also logging you out after a certain amount of time. These are also very useful, and we look for them every time. In the worst-case scenario, the machine's power-management takes care of that.
Ideas
Based on the former, here are some suggestions.
Memory Cache
 |
Note: After some testing, we consider this light-speed rezzing... It really blasts all other methods away. |
- Some *nix flavors, as well as Windows, have options for creating (mounting) a drive that represents a slice of your RAM. Consider, if you have memory to spare, offshoring the entire cache to RAM. There may be solutions around that would offer safely mounting and unmounting the drive by writing the cache files to harddrive after shutting down the viewer. This would have the effect that all your transactions are made directly from RAM, which would offer an incredible speed compared to hard storage.
If you are on Mac, Snow Leopard onwards, try the following in a Terminal:
imp:~eva$ diskutil erasevolume HFS+ "ramdisk" `hdiutil attach -nomount ram://2097152`
which will create a new ram-disk of 1GB size.
You can check by issuing the command in a terminal df -h:
imp:~eva$ df -h Filesystem Size Used Avail Capacity Mounted on /dev/disk2 1.0Gi 12Mi 1.0Gi 2% /Volumes/ramdisk
Next, configure your cache to write to that folder:
AFAWK, 1GB = 1024MB but, 1000 is probably what they mean. Unless it's measured in bananas and 1000 bananas mean 1024MB.
- Based on the former, how about running the entire viewer in RAM. The viewer itself is only a couple 100MB in file-size. The cache, Imprudence's cache is limited to 1GB so you are looking at up to 1.5GB of RAM usage. This may not be too much for newer machines. Just drag and drop the viewer into the newly created ramdisk.
Keep in mind that by using a RAM-disk, whenever you restart your machine, the cache will be purged. If you want to take this to the next level, consider a commercial/third-party solution that swaps out your ramdisk to your hard storage before resetting and then loads it back. You probably could script that as well and spare your money.
Squid Cache
Squid is a proxy that allows you to deliver content faster by providing a front-cache to all your clients. In the past, this optimization technique has been used to cache textures, thus delivering them faster. However, we found that this works poorly for some, or other, reason. We greatly prefer the RAM-based cache since it is a local cache which requires no network-pull at all and does not require installing a system service which may be incompatible with the Second Life HTTP requests. However, if you wish to install squid, try the SLSquid_Proxy page.
Squid is great for multi-user environments. However, so is the memory cache technique described above. Given that you mount a slice of your RAM as a drive, you may of course network-share the drive. However, that defeats the purpose a little.