shame!

Microblogging platform Plurk, of which I'm an active user as ThoMillgrove, reports that Microsoft Chinese subsidiary MSN Juku as blatantly ripped off their code, design, and UI elements. Very uncool, unethical, and illegal. We can hope that Microsoft will act in all haste to correct this.

lag hoodoo quick reference

Approaches to reduce lag, within groups sorted in order of effectiveness, more or less. This does not cover every item mentioned in the series of articles, just the ones that are likely to have the most impact. It also omits hardware and network upgrade options. You may review the previous articles for more details.

Viewer and Operating System items typically affect your local experience, and not others. Those dealing with the avatar and the region (AKA sim) typically affect both you and others.

Enable the Statistics bar to monitor the effects of changes with Control-Shift-1

• Viewer Control Panel Graphics Tab (with Custom box selected)
  
  Note that these are trade offs between speed and quality
  
  
  
  
  • Window Size set to smaller size
  
  
  • Quality and Performance slider moved to left one or more steps
  
  
  • Draw Distance reduced
  
  
  • Atmospheric Shaders and Water Reflections disabled
  
  
  
  



• Viewer Control Panel Network Tab
  
  
  
  • Maximum Bandwidth to 500 kpbs, but adjust with experimentation for best FPS
  
  
  • Disk Cache Size to maximum (usually 1000 MB)
  
  
  
  



• Other Viewer settings and issues
  
  Activate the Advanced menu with Control-Alt-D
  
  
  
  
  • Advanced->Rendering->Run Multiple Threads
    
    This is not helpful if you have one single core CPU
    
  
  
  • Advanced->Rendering->HTTP Get Textures (if available)
  
  
  • Disable Voice, and/or Video (Media) if you are not using them
  
  
  • Experiment with alternative viewers
  
  
  
  



• Local Operating System
  
  
  
  • Run spyware scan, virus scan, and defragmentation (on Windows)
  
  
  • Reboot
  
  
  • Disable unnecessary 'helper' applications and crapware
  
  
  • Reduce window system eye-candy, e.g., Windows Aero interface
  
  
  • Give viewer increased priority
  
  
  • Update drivers for graphics card, network interface, and motherboard
  
  
  
  



• Avatar
  
  
  
  • Check your ARC (Advanced->Rendering->Info Displays->Avatar Rendering Cost
    But never yell at somebody else about their ARC; that is rude
  
  
  • Choose unscripted attachments and clothes in preference to scripted ones
  
  
  • Choose clothes and other attachments that use a minimal amount of textures cleverly
  
  
  
  



• Region (assuming you have permission to create/modify within the region)
  
  
  
  • Remove unnecessary prims, and don't litter!
  
  
  • Use large prims to break up view of lots of smaller sims
  
  
  • Reuse textures
  
  
  • Be careful of scripts, as they can potentially cause serious lag
  
  
  
  

That completes this series of articles. I hope you've found it helpful. May your lag be low and your enjoyment high.

lag hoodoo 9: hardware

Before we get started on the main issue of hardware, a couple of things I've read and discussed with others are worth mentioning.

Zauber Paracelsus, whom I don't know from Adam, published a blog article titled 'Reducing Your Lag!!!' that is worth your reading. While much of what he covers I have already mentioned, he did make one statement about the Maximum Bandwidth setting (Preferences->Network) which made me go back and test a bit: 'Put it below 500 and you'll see a huge performance boost.' I played around with it, and found that, on my system, 500 seemed to give me the best results. It wasn't a huge change, only three or four FPS, but that can make a big difference in feel on an otherwise laggy system. Probably the best setting for your system will depend on your particular network, so experiment with it a bit.

Second, especially if you have a Windows system from a major vendor such as Dell or HP, you may have a lot of 'crapware' being loaded on start up on your system. It's worth taking a look on the Task Manager to see what all may be running on your system that you are not aware of. Take a look at this ZDNet blog entry for more details on how to deal with this.

As you work on reducing lag in your virtual world experience, it's important to remember that you can only do so much if your hardware is not up to the task. Just as a tune up, as important as it is, will not make a Hyunadi perform like a Ferrari, so insufficiently powerful computer hardware cannot perform beyond its limits. Obviously, if money is no object, you can buy a $5000 gaming system and very likely dramatically reduce your lag issues, at least those on the client side. I will not go into huge detail as to how to purchase or build such a system, but you can take a look at the Tom's Hardware Build Your Own website for lots of information on that.

However, many of us do not have that sort of cash ready to spend on such a system. There are strategic upgrades that can be made to maximise whatever money is available for hardware improvement. I do not intend to write an in-depth article on hardware upgrading, but I will touch on the areas most likely to affect the performance of a virtual world viewer. I recommend that you take a look at the vast amount of information available on the Tom's Hardware website.

The key to hardware optimisation is in discovering the bottleneck, and there is generally a bottleneck. With 3d VW viewers, the most likely culprits are GPU (graphics processing unit, the heart of your graphics card), CPU, and RAM (memory). There could also be hard disk, bus, or network speed issues. CPU and RAM are fairly easily checked using a monitoring application, such as the Windows Task Manager, the Mac OS X Activity Manager, or the Linux "top" command. These tools can quickly show you, among other things, if your CPU is being utilised at 100% on an ongoing basis, or if your RAM is being overtaxed. On Windows, for instance, select the Performance tab. If one or more of the CPU Usage History is remaining at 100%, or the Physical Memory Usage History is remaining near 100%, the system has a bottleneck in the affected area.

Memory is usually a fairly easy and not terribly expensive upgrade, and if your system has less than 1 GB, you should almost certainly upgrade it. CPU is usually a more complex upgrade, and may require a motherboard replacement, at which point it may make more sense to consider a replacement system. Network speed is usually a function of what your ISP is providing you, though there can be local network issues that cause loss of information and slow down overall performance.

For GPU performance, take a look at the graphics card installed in your system, and compare it to the Second Life recommendations, which will generally be applicable to viewers for Opensim-based grids as well. If you upgrade your GPU, ensure that your power supply is adequately rated for the demands of your system. Typically the specifications for a graphics card will specify a minimum recommended power supply wattage.

Next week, I will wrap up this serious with a review in the form of a quick checklist of things you can do to reduce lag. Until then, happy avataring!

lag hoodoo VIII: what would Henry do?

In this article, I'll look at a few odds and ends of lag reduction that that we haven't covered yet.

The advanced menu, activated with Control-Alt-D (it was originally called the Debug menu, hence the use of 'D'), gives us one or two possibilities to look at, depending on the particular viewer. First, there's an option under Advanced->Rendering called 'Run Multiple Threads'. If you have a multiple core CPU (quite likely if you've purchased you system in the last year or so), or multiple CPUs (less likely), selecting this can make a significant difference, at the potential cost of occasional crashes. If you have a single CPU, this will likely make no difference, and is best left off. If you're not sure what sort of CPU you have, try turning it on while watching the FPS in the Statistics Bar. If you see a significant improvement, then leave it on; if not, turn it back off.

Additionally, on the Snowglobe viewer and a few others that have borrowed its new texture pipeline, there will be a choice in the same menu for 'HTTP pipeline'. If it is there, turn it on. The difference it makes can range from very slight to huge, depending on several factors.

Disable voice from the 'Voice Chat' tab of the Preferences window if you never use voice, as that is an additional running process and a couple of libraries.

Aside from those, a few other things that can be done are general system maintenance issues. I won't go into great detail, as there are plenty of online resources. Defragment your hard drive if you're running Windows. Scan for viruses and spyware. Make sure you are not running services and other applications that you never or seldom use. Update the drivers for your graphics card, network, and motherboard.

Experiment with different viewers. There is no one viewer that is fastest on all systems in all situations, so find the one that works best for your. Some I have found to be generally faster are Emerald, Imprudence, and Cool. But sometimes, they're slower for some people. Also, some viewers have an optimised version available for newer CPUs. Unless your system is quite old, try that.

When in doubt, reboot. That's especially true with Windows, but also applies to Mac OS and Linux, if the system has been up for several days.

Remember, there is only so much you can do with software if your hardware is inherently limited; next week, we'll look at hardware, and then I intend to wrap up with checklist of sorts.

lag hoodoo number seven: the server

Early on I mentioned server-side lag as a potential issue. This, as you may recall, is reported on both the Lag Meter and, in much greater detail, the Statistics Bar. The most interesting server numbers on the Statistics Bar as far as I'm concerned are Time Dilation and Sim FPS. Other potentially interesting ones are Agent Updates/Sec and Script Events.

Time Dilation is a measure of how well the region is keeping up. Typically, it should be at 0.99. If it starts to drop below 0.95, the region is lagging, and the lower it drops, the worse the lag. Likewise, Sim FPS is a measure of the fastest rate the sim is able to update the scene to viewers; as with FPS on viewers, if it drops below 15 FPS, you will notice jerkiness, even if your viewer FPS is faster.

So what causes server side lag? The simple answer is complexity: the more there is for the server to deal with, the slower it gets. This complexity can be caused by lots of prims, lots of textures, lots of scripts, or lots of avatars. Starting with the last one first, the server has to keep track of the number of avatars, and the relations between those avatars and everything else in the sim (for our purposes, consider a sim and a region to be the same thing). As the number of avatars in a sim increases, the number of relationships increases exponentially, as all the avatars' viewers have to be updated with information about each avatar. This is why twenty avatars in a sim can seem so much laggier than simply twice ten.

Lots of prims can cause lots of lags, all else being equal. This is true not only of the prims that are a part of the scene, but also the prims that are worn by avatars in the form of hair, shoes, and other attachments. Now the viewer can also be lagged by lots of prims, but the server performs some smarts so as not to send prims that cannot be seen, either because they are completely hidden, or because they are too far away. But the server still has to account for every one of those prims. Likewise, every textures on those prims have to be accounted for, and transferred.

Finally, scripts can cause lag. It's important to know that scripts are handled at a lower priority than the actual rendering of the scene. That means that, if the server is too busy accounting for everything else, it may handle scripts slowly, or not at all. If scripts are running, and there are a lot of them, or one or two that are very processing intensive, they can also add to server side lag.

So, what to do, what to do? Obviously, if you own or have permissions in the region, you can do more than if you are merely a visitor, by reducing both the number of prims and the number of textures. One clever approach is to combine a number of related textures into one, and then using offsets and scaling to use only pieces of that texture on different prims. Likewise, care in the use of scripts can make a big difference. Additionally, laying things out so that not all prims are visible from all locations, while not necessarily helping the server in terms of the number of prims to be managed, will reduce both network and viewer lag.

If you cannot control these aspects of the sim, there are still things you can do. Reducing the number of prims and textures on your avatar can make a difference. This does not mean you have to go naked in a crowded place, but it does mean that careful choice of what you're wearing can make a difference. Avatar Rendering Cost, ARC, is an interesting, though not entirely accurate, means of determining the load your avatar is contributing. This is found from the Advanced menu (activated with Control-Alt-D), as Advanced->Rendering->Info Displays->Avatar Rendering Cost. This will display a number, the ARC, over the head of all avatars in range. Generally, the lower the better, especially in a lag situation. However, notice that the ARC on other avatars, as you move away from them, will drop. This is because at a distance there is less to render on your viewer; but it is still having to be tracked by the sim. Experiment with different hair, or jewelry.

A naked avatar has an ARC of zero, but so does a fully dressed avatar, if she is only wearing appearance (non-prim) clothes and hair. It's the attachment of prims that drives ARC up, and, as we know, prims add complexity to the job the server has to do.

However, it is very important to remember, before you decide to become an ARC enforcers, yelling at others to reduce theirs, that ARC is often really a fairly minor issue compared to the physical presence of the avatar. So the main point in this is to mind your own avatar, and make sure you are not contributing more than necessary to the lag. Also, I recommend you not leave the ARC turned on, as it causes viewer lag for you.

Finally, be a good citizen and don't leave litter around. If you unbox something, don't leave the box lying around. If you pull something out from inventory, or create something for temporary use, remove it when finished.

lag hoodoo, the sixth visitation

This week we'll talk about competition. The computer has finite resources, and no matter how well you've tuned your viewer, if something else is competing for those resources, it will have an impact.

The biggest potential competitors are other applications. Web browsers, graphics tools, even word processor and spreadsheets can have an impact. Big downloads or streaming media can impact the network performance significantly. If you're seeing a lot of lag, and have tried the things before, start closing applications. If you have lots of tabs open in a browser, close tabs, especially those for high-demand pages such as YouTube.

Vista's (and presumably Windows 7's) Aero interface can have a huge impact on graphic performance. MacOS's interface likewise can compete for graphics card resources. I've found with Vista that disabling the semi-transparent window frames makes a 5 to 10 FPS difference in my viewer performance. Menu-click (that's right click for you right-handers) on Computer to select properties, click 'Advanced system settings', click 'Custom', and then unselect the 'Enable desktopcomposition' box and press OK. Equivalent tuning in MacOS is likely to help.

One other tip is that reducing the area to render improves performance. In other words, if you reduce your viewer from full screen to a smaller window, FPS can increase significantly. This becomes a trade-off between performance and being able to actually see what you're doing sometimes, but is worth experimenting if you are still suffering from lag issues.

Next week, we'll discuss server-side lag, and what can be done about it.

lag hoodoo episode V: the network strikes back

Moving on from graphics settings, it's time to take a look at what the network information means, and what can be done about it. In the Lag Meter (Help->Lag Meter) the second item displayed is labeled Network. In the Statistics Bar (Ctrl-Shift-1, or View->Statistics Bar), there are three items, 'Bandwidth', 'Packet Loss', and 'Ping Sim'. There are more network details under the 'Advanced' section of the Bar, but we will not go into them in this series.

Bandwidth means the total amount of information than can be transferred in a given period of time, while ping time is a measure of latency, that is, how long it takes to transfer individual packets of information. A high bandwidth connection with with large latency (a satellite internet connection, for instance) will likely feel jerky, even though all the information is being transferred rapidly. Likewise, a low bandwidth connection (such as dial-up, ISDN, or slower DSL) will feel like moving through treacle or molasses, even if the latency is very low.

Network-related items that can be controlled within the viewer are found in the Preferences window (Ctrl-P, or Edit->Preferences...), and include 'Maximum Bandwidth' and 'Disk Cache Size'. The default setting for bandwidth is almost certainly too low, but the correct setting will depend upon the specifics of your ISP (Internet Service Provider), local network, and computer hardware. The quick way to find the appropriate setting is to move the slider to the right until you start to see Packet Loss in the Statistics Bar, and then slide it back to the left until the loss is 0.0%.

Disk Cache Size specifies how much room to use for caching downloaded texture and other information, and should always be set to the maximum value, unless you are very restricted on local disk space. The slider will go to 1000 MB, and should be set there. In fact, there is a way to go even higher through debug settings, but at some point you reach diminishing returns. You should not press the 'Clear Cache' button except to try to resolve a rendering or crashing problem, or you will rob yourself of much of the benefit of caching.

The Second Life Snowglobe viewer has introduced a new texture downloading technique than can, in some cases, greatly improve texture downloading and caching. This improvement has also been included into some other viewers, including Emerald and Kirsten's

Outside of the viewer, there are some additional things that will affect network performance. Everybody knows that cable internet connections are always faster than DSL. Of course, everybody is often wrong, and the truth is much more complex. DSL is often available in a range of speeds, and an upgrade can often provide significantly better performance. DSL also is a switched system, meaning that a neighbour's downloading does not impact your performance as directly as it does with cable. On the other hand, DSL speeds degrade rapidly depending on your distance from the local switching office. Other ISP systems, such as wireless broadband, have their own issues.

On your local network, using a wireless connection can sometimes have a very large impact. If network performance continues to be poor, try a direct wired connection to see if that is the issue. If it is, the solution may be as simple as moving the wireless router a small distance, or to another room closer to where you use the computer, or may require upgrading to a faster wireless specification, or even giving up using it all together.

Ping Sim, or latency, is a function of the distance from the server to the viewer, and is not normally something you can control, short of moving physically closer to the servers. There can be situations caused by bad routing that make this distance needlessly long. Likewise, lots of Packet Loss even with a very low Maximum Bandwidth setting can indicated a hardware issue somewhere in the path from the server to your computer, or a misconfiguration of a router or firewall. Diagnosing general network performance problems is beyond the scope of this article, though it's amazing how often simply replacing a cable can make a difference.

disclaimers

First of all, I have never yet—to the best of my admittedly fallible memory—blogged about anything given to me gratis. That doesn't mean I won't ever do so, or that I think doing so is a great evil. It just hasn't happened.

Second, I believe that disclosing that an item being reviewed was received free of cost is ethically the right thing to do, regardless of any legal requirements. It's simply a matter of basic honesty.

Those two things said, I personally suspect the US FCC's strong recommendation that bloggers make disclosure treads dangerously close on treating the speech of bloggers differently from that of other media. Would such treatment stand up in the US courts? I don't know; as a strong free-speech supporter, I certainly hope it would not.

In any case, any blog reader who assumes that, because the FCC is enforcing such a rule, all bloggers will adhere to it is both naïve, and does not grasp the international nature of the Web. I certainly hope that FCC commissioners and staffers don't fall into those categories, but I do wonder. After all, this is the same government agency that has spent, and continues to spend, vast quantities of money in a tizzy over Janet Jackson's nipple.

lag hoodoo: la cuarta parte

We'll wrap up our discussion of lag caused by viewer graphic settings in this instalment, taking a look at the 'Hardware Options' button off the main Graphics tab in the Preferences window. In the smaller window that opens with this button contains half a dozen settings. In order, these are:

Filter: this is essentially a way of making textures look more realistic, but it comes at a performance cost. It's probably best left off, unless you have a very powerful system, or are making photographs.

Antialiasing: this smooths the jaggy edges of angles. Again, it comes at a cost, and the higher the setting, the higher the cost.

Gamma: this is an adjustment to image brightness, and is probably not worth worrying with. In my experience, it does not make much if any difference to performance, but adjusting it may make scenes more vibrant in some cases. See Wikipedia for more detailed information. In any case, if you are using Windlight adjustments, I believe they override this setting.

Enable VBO: the Vertex Buffer Object extension to OpenGL is a setting to eliminate the calculation and transfer of redundant information in rendering objects. It's generally best left on, but experiment if you like.

Texture Memory (MB): the size of this is determined by available memory on the graphics card, and helps prevent the constant re-downloading of textures from the server. According to Tateru Nino, the SL 1.22 viewer seldom uses much more than 256 MB. Presumably, this is also true of the other viewers. If you have it set higher, and see problems with crashes, adjust it downwards.

If you are running multiple viewers, I suspect, but cannot prove, that it's best to divide the total cache size of your graphics hardware by the number of viewers you are running, and set the Texture Memory no higher than that value.

Fog Distance Ratio: this affects how quickly things fade out in the distance, but is only used if 'Basic Shaders' on the main graphics tab is disabled. The lower the value, the closer the fog, and presumably the better the performance, though I haven't noticed huge effects.

One last item to discuss, back on the main graphics tab, is combination of 'Run Second Life in a window' and 'Window Size'. In my experience, setting the window size smaller than full screen can improve FPS performance, sometimes significantly. Of course, this becomes a trade-off between performance and being able to actually see anything.

Next time, we'll discuss the network performance settings. Until then, may your rendering be beautiful and your lag be low.

lag hoodoo part III

Boadicea's (or Boudicca's) Chariot by Westminster Bridge

© Copyright Gill Hicks and
licensed for reuse under this Creative Commons Licence.

Last week, we took an initial look at the Graphics settings in the Preferences dialogue in an effort to improve our frames per second (FPS) performance. This week, I was planning to take a closer look at all the options on that page, but, due to a combination of jury duty, flu in the family (not I, thankfully!), excitement at winning a chariot race, and plain old forgetfulness, I'll just have to make it short, and touch on a couple of things.

If you open the Preferences window, and select the Graphics tab, next to the the 'Quality and Performance' slider mentioned last week, there is a box labeled 'Custom'. If you select this, a score of controls will spring into view. Some of these may be greyed out, depending upon the Quality and Performance setting and the capabilities of your graphics card.

There is also a 'Recommended Settings' button at the bottom of the window, which will reset the settings to a consistent starting point, and unselect the Custom box at the same time. This is seldom the optimum result, but does provide a way to quickly get back to a known state while experimenting with settings.

If, after opening the Custom controls, you move the Quality and Performance slider, you will find that it is actually adjusting each of these controls. Play around a bit, and observe how the settings change, what their visual effect is, and what their impact on FPS is (Ctrl-Shift-1, remember). Then push the Recommended Settings button again, and re-select Custom.

While I have found all of these settings have some effect, some have more than others. Finding the optimum setting is a matter of trading off performance you can live with for visual quality you are happy with, and these values may change depending on the region you are in, and what you are doing. For instance, when I am chariot racing or in a sailing regatta (did I mention I'm the champion of the Minoan Empire in both sports?), I will set every thing to the absolute lowest setting, because I value performance above every thing else. For most purposes, though, I run at High Quality, with several of the other controls tweaked a bit.

I will wrap this up for now by noting that 'Draw Distanc'e is one of the most powerful controls if you are in a region with a large number of prims, avatars, and/or textures. If you are in a very empty area, it will not make as much difference. I have also found that the 'Water Reflections' and 'Atmospheric Shaders' selections under 'Shaders' can have a big effect.

Until next week!

lag hoodoo part two

As we look at the Lag Meter, under the Help menu on most OpenSim/Second Life viewers, we see three indicators. In this post and the next two, we'll look at what those mean, and how a poor, lagged down user can influence them.

The first one is the Client. This indicator is presented as FPS, or Frames Per Second, and is an indicator of how quickly the local viewer is able to re-render the scene. The faster it renders, the smoother and more immersive the experience will feel. For comparison, standard resolution television renders at 25 or 30 FPS, HDTV ranges from about 24 to 60 FPS, standard 35 mm cinema film runs at 24 FPS, and IMAX runs at either 24 or 48 FPS.

The Lag Meter flags any rate below 10 FPS as red, and below 15 as yellow. My personal observation has been that, below 10 FPS, it starts to feel progressively more and more as if I am trying to walk through hardening cement, and appears more and more as if I am moving through a series of slowly changing pages (which is essentially what is happening). Above 10 FPS, it's generally easier to move, and above 20 FPS or so, it begins to appear much more smooth and lifelike. I have also found that in competitive activities, such as sailing and chariot racing (ask me sometime), if the frame rate drops below 15 FPS, control of my vehicle becomes much more difficult.

So, one might ask, what influences the frame rate? Why doesn't the viewer simply render at 25 or 30 FPS, and be done with it? The answer is both simple and complex, and we'll take more than one week to answer it, but the short answer is, rendering an entire scene can be very difficult, and is impacted by anything that increases complexity. A scene rendered on your computer consists of polygon edges (the wireframe), textures, and lighting. This is true not only of the land and prims, but of all the avatars within the view. The viewer must render all of these things as quickly and efficiently as possible. Having few visible prims makes the job easier, while lots of prims, with lots of textures, makes it harder. Static things make it easier, while moving things--avatars, flexiprims, lots of particles--make it harder.

The rendering is primarily the task of the GPU, the graphics processing unit, and it's supporting electronics on the graphics card. This is an area in which all are definitely not created equal. Take a look at this somewhat outdated http://s3.amazonaws.com/secondlifegrid.net/frameratesbygpu.png (comparison of frame rates by GPU) document. This is specific to older versions of the Second Live viewer, and does not include some of the newer graphics processors, but the relative comparisons still hold true. If anything, newer versions of the viewers are more demanding, and the typical rates will be lower. The ranges are due to several things, including the differences in simple and complex scenes. Also note that ATI GPUs are typically somewhat slower than equivalent nVidia GPUs, even though in a game such as World of Warcraft they may be much closer. Without going into detail, this appears to primarily a difference in drivers between the two GPU makers.

Second to the GPU, the local computer's CPU also handles a lot of the calculations, and the weaker the GPU, the harder the CPU will have to work to compensate. Third, there is memory caching, in both the graphics card and main system RAM. All else being equal, more RAM on both the system and the graphics card is a good thing, as it allows things to be kept available for quick use, instead of having to be retrieved from the server via the network, or from the local hard disk. Finally, there is the network itself. While network is a separate entry on the Lag Meter, it also affects FPS. A processor, whether GPU or CPU, that is not being given things to process as fast as it can handle them simply cannot work at its maximum potential.

So, given that, what are some quick and easy things we can do to increase FPS? There are things that will only affect the local system, and things that will affect not only the local system, but other users as well. We'll start with the former. I will be using the most current Hippo viewer version 0.5.1 set to the English language for consistency as I describe the options; other viewers and other languages may cause some of the settings to vary, or be differently labeled.

The very first thing to do is to open the Preferences window, either Control-P, or from the pull down menu, Edit->Preferences. Select the Network tab, and move the slider for the Disk Cache Size all the way to the right. This maximises the amount of on-disk storage for textures retrieved from the network. Click Apply. Note that this will increase the disk space used locally. You may not see an immediate increase in FPS, but over time, it should help in areas you frequent. Note: if you do not have sufficient space available to increase this cache by 500 MB, then you really should consider either adding more disk space, or removing something from your system.

The next step is to select the Graphics tab. If you have never made adjustments here, you should see a fairly simple dialogue, with a single slider for Quality and Performance. Unless it is already in the leftmost position, try sliding it one step to the left. You should immediately see an increase in FPS on the Lag Meter (Help->Lag Meter) or the Statistics Bar (Control-Shift-1), at the cost of some of the quality of the rendering. This is because the number of details being rendered is being decreased to reduce the rendering time, and thus increase the FPS.

Next time we'll go into more detail on this tab, but for now, if you'd like to experiment more, tick the "Custom" box. This will open up a number of boxes and sliders that you can test to see what effect they have on your system's performance.

One last thing to experiment with is decreasing the size of the viewer window. Tick the box at the top of the graphics tab, labeled 'Run Second Life in a window', if it is not already. Then try choosing different Window Size settings, or simply resize the window frame. You may find that, at smaller window sizes, you see an increase in FPS.

Until next time, cybernauts, may your lag be low!

~*~
Thoria

lag hoodoo

This is the first of a series of articles I wrote for the 3rd Rock Grid community newsletter. I'm reproducing it here in hopes that it may benefit a wider audience of virtual world citizens. There is no shortage of articles on lag available through an internet search, but perhaps I will provide a collection of useful information in one place.

While this was written for 3rd Rock Grid, and is thus specific to OpenSim based grids, it will also most certainly be applicable to Second Life as well. At a more general level, much of what will be discussed may also apply to other VWs, such as Blue Mars, or There.com.

Introduction

Lag is a word that is tossed around in virtual worlds as sort of a catch all word for anything that makes the user's experience feel less than immediate. As lag gets worse, the experience of immersion begins to degrade, going from mildly annoying to exasperating to completely unusable.

I hope over the next few weeks to share some of what I've learned in nearly three years of virtual world experience and nearly 25 years of computer experience. I plan to look at what are the sources of lag, and what we as users can do to reduce its effects. While I have learned a lot working for a major computing hardware vendor, and from personal experience in virtual worlds, I certainly don't know it all, and welcome comments, constructive criticism, or additional helpful information. This is especially true for Macintosh systems, as I do not have one. Most of what I say will be applicable, but there may be some details that vary.

Performance degradation is caused by a limitation of computer resources, when a resource is trying to satisfy too heavy a demand. I started to write a lot more detail on this, but we'll save that for later. For now, we'll take a look at a couple of tools that let us see where lag is occuring.

First, there is the Lag Meter. This is sort of like the "idiot lights" on an automobile instrument panel, and is launched from the Help menu of your viewer. The Lag Meter has three indicators, for "Client" (the user's computer), "Network", and "Server" (the computer or collection of computers that run the virtual world). Each of these may be green, yellow, or red, to indicate whether there is a performance problem, and to what degree. Additionally, there is a line of commentary that provides a bit of (sometimes questionable) insight into any problems. Generally, if all three indicators are green, your experience should be acceptable. if one or more are yellow, you may notice some degree of lag, and if one or more are red, you are almost certainly noticing lag.

Second, there is the Statistics Bar. This may be reached with Control-Shift-1 (or Command-Shift-1), or from the View menu as "Statistics Bar". This provides much more detail than the Lag Meter, but parallels its information. FPS (frames per second) is an indicator of client performance, with a rate above 15 corresponding to green, between 10 and 15 to yellow, and below 10 to red.

Likewise, Bandwidth, Packet Loss, and Ping Sim are indicators of network performance, and the various items under Simulator give information about server performance. We'll look at these, plus some others that are normally hidden, in later installments.

I plan to first look at some easy adjustments that can be made, sometimes for a large improvement in performance, and then move on in later installments to some of the trickier adjustments. It is always important to keep in mind that all systems have some maximum level of performance, beyond which no amount of tweaking will improve things, but with careful observation and tuning, we may at least be able to approach that maximum level.

Finally, so that you may have some place to begin this week in improving your virtual world experience, may I suggest that you do some basic system clean up. On a Windows system, run spyware and virus scans, and defragment your hard drives. On all systems, ensure that you are not running large programs or lots of little utilities that, in aggregate, are stealing system resources from your viewer.

Until next time, happy immersion!

~*~

Thoria Millgrove

bibliophilia redux

About ten months ago I published the entry entitled bibliophilia, which passed on a list of one hundred books that others had considered worthwhile, and I marked those I had read, or was reading.

Now my Cyberspace friend Ribbons Whitfield has referenced it, with her own mark-up, so I thought maybe I should add an update. The erudite Ms Whitfield also confessed to bibliophilia, something that I share with her.

From that list, I have now read Nineteen Eighty Four, by George Orwell, and Jane Austen's Sense and Sensibility. I must say that I think the former is a must read, while the latter I think may be the best of Austen's work. Yes, I liked it even better than Pride and Prejudice.

I am still working, slowly, on War and Peace. That's the book I keep with me for reading when I am waiting some where, and I suspect I may be still working on it in another ten months.

I'm currently reading Eye of the Needle, by Ken Follett, and not on the list. I have a CD audio version of The Kite Runner, by Khaled Hosseini, which is on the list.

As I went through that list again, I notice that I had marked Lolita, by Vladimir Nabokov, as read. In fact, that was an error, as I have not read it, nor do I really have any great desire to, not considering paedophilia to be a great literary topic.

I started on an audio version of Ulysses, by James Joyce, which I downloaded from Librivox, but was disappointed in what I considered as the narrators not taking the material seriously at all. Librivox can be that way of course; some of the works are quite well done, others not so much. But the price is ideal.

Other books I have read so far this year include:

Albom, Mitch: Tuesdays with Morrie

Burnett, Frances Hodgson: Little Lord Fauntleroy

Card, Orson Scott: Ender's Game

Heinline, Robert and Spider Robinson: Variable Star

Hemingway, Ernest: A Farewell to Arms

Hobbes, Thomas: Leviathan

Keillor, Garrison: Pontoon

Tolkien, JRR: The Children of Húrin

poissons d'avril

Yesterday, one of the developers on the OpenSim project introduced an April Fool's "joke" that caused all avatars to render as stick figures. This caused a reaction from many of the users of OpenSim who spent hours trying to resolve the issue. In response, Sean Dague, one of the principles in the project, posted Hey Folks, Please Get a Sense of Humor on his blog. I think he misses the point, in assuming that those complaining have no sense of humour. Worse, some of the comments go obscenely further.

In response, I posted a comment, which appears to have been rejected by the blog moderator. Therefore, I'm reposting my comment here:

Wow. Just wow. Somebody did something stupid in the product, was chastised for it publicly, and now I read whinging about how those people had no right to complain about anything you chose to do. As a developer for over 25 years, I cannot imagine the level of hubris that says of those using my product, even the most bleeding edge version of my product, “screw ‘em”.

There are legitimate reasons to work from the trunk, and anybody working from that has to expect occasionally instabilities and problems, and budget their time accordingly. Jokes are fine, but, when it turns out that a problem that makes the product more or less unusable was intentionally introduced as a joke, well, it demonstrates to me a lack of concern for those using the product.

who am i?

Identity is, to me, a fascinating concept, but I didn't think much about it until a couple of years ago. That was when I got involved in Second Life (SL), a place I first went to investigate the technology.

Perhaps I should start with some things about me. I'm a techie, a software developer and wannabe visionary. I first started investigating SL in 2006 to see what could be done with virtual world technology. If I did see a lot of possibility with the tech, I was also very surprised by relationship.

It turns out that SL is more about relationship–who and where–than it is about technology. And one of the most dramatic relationships, at least for me, has been that between my "real life" (RL)* and my SL selves. That almost sounds as if we're discussing a multiple personality disorder, but I don't think that's it. Rather, I find the relationship of Tho Millgrove and my RL self to be simple and complex. They are both me, yet they're not the same. Or, I could say they are both my identities, but they are not identical, each influencing as well as being influenced.

That is to say, Second Life and other virtual spaces have had a profound influnce on the inner me. I still recall my first month in SL as a time of very vivid dreaming, with my subconscious mind trying to make sense of and integrate this new self into my psyche. In the subsequent time, when things have become much calmer and steadier, there have still been periods of profound disturbance as events and realisations have affected me.

Once, I was experimenting with a text viewer, and wanted to see if my avatar was rendering properly. So I went in world with an alternate avatar–an alt–in the regular SL viewer. The effect was, surprisingly to me, very disturbing. I saw her there, looking like she always does. The normal viewpoint in SL is from a "camera" behind the avatar, and it's not unusual to move that camera view and look at your own avatar from many different angles. And yet, unlike that, this felt felt like an out-of-body experience. I quickly logged the alt out, and shook my head at how odd it had been.

So, ultimately, who am I? Who is "myself"? Is it RL self or SL self, or do they both exist as windows onto an inner reality? I tend to believe the later, and that has a profound effect on how I deal with many of the discussions about things like "immersion and augmentation", role playing, and even friendship, trust, sexuality, religion. I intend to talk about specifics in future posts, but I wanted to make a start.

What do you think about identity and virtual worlds?


* Many SL users prefer not to use "real life", choosing alternatively to use "first life", "atomic life", or "physical life". But, by now "real life" has become rather ingrained in common usage, "first life" only makes sense in the context of "Second Life", and the other two sound to me more like biology terms. So I'll just use RL.

non sequitor

I heard this, or something very close to it, just yesterday from a celebrity who I consider quite intelligent: "I don't believe in God because of all the bad things done in his name."

It's an old argument, but it's an ad hominem one, and it's logical nonsense. Replace "God" with any random noun to see how silly it is. "I don't believe in sex because of all the bad things done for it." "I don't believe in chocolate because of all the colonialism and exploitation that goes with it." Please! If you're going to argue that atheism is more rational than religion, then at least come up with a rational argument.