Server Deployments week 44
As always, please refer to the week’s forum deployment thread for the latest news and updates.
Main Channel
There have been no updates to the Main channel.
Release Candidate Channels
All three release candidate channels received the same new server maintenance package on Tuesday October 29th, which fixed some crash modes.
The reason for the RC channel updates being moved to Tuesday is because there was due to be a planned outage on Wednesday October 30th at the time the deployments usually take place to allow some database work to take place. This would have likely seen log-ins blocked for about an hour. However, Simon Linden believes the work has now been postponed for a week – although the recommendation is to keep a check on the Grid Status page – see the original notice for details.
SL Viewer Updates
A new release candidate appeared in the release channel on Monday October 28th. Version 3.6.10.282997 has no functional updates, but includes an update to the GPU table.
About the GPU Table
The GPU table is used to define your graphics card to the viewer and the default graphics settings which are applied as a result when you first start the viewer (or if you never adjust them).
Graphics cards are defined by classes (currently 0-5), which can be defined as:
- 0 – Defaults to low graphics settings. No shaders on by default
- 1 – Defaults to mid graphics settings. Basic shaders on by default
- 2 – Defaults to high graphics settings. Atmospherics on by default
- 3 – Same as 2, but with lighting and shadows(now referred to as Advanced Lighting Model in the viewer) enabled
- 4 – Same as 3, but with ambient occlusion enabled
- 5 – Same as 4, but with shadows set to “Sun/Moon+Projectors.”
The table is a .TXT file which is located in a viewer’s installation location on your computer. For Windows, this means it can be found either in C:\Program Files\[viewer name] or in C:\Program Files (x86)\[viewer name] (if you are running a 32-bit version of a viewer on a 64-bit system).
It is not recommended that you amend this file in any way, unless you know what you are doing. You can, however, open it and use it to determine which class your viewer falls under, and the default settings it is given.
To make it easier for those wanting to quickly reference common graphics cards, Garvie Garzo has produced a .PDF file of the table. However, do bear in mind that the table is subject to updates (as the release candidate mentioned above demonstrates), so the PDF may become outdated over time. Also, some TPVs have been working on updating the GPU table themselves.
When perusing the table, cards are listed alphabetically by maker, and the first digit following the card name refers to the class it has been assigned to, while the far right column defines the overall family of GPUs the card belongs to (you may find when viewing the table that the columns do not align well).
The settings within the GPU table are subject to some debate, as they are used to determine which graphics cards present a “reasonable” enough performance in order to have ALM enabled by default. Linden Lab consider anything qualifying as a class 3 or above is capable of adequately running with ALM enabled; some TPVs do not agree.
The problem here is how “reasonable” is defined; it’s a subjective term, and everyone will have their own opinions on the matter. As I reported back in week 39 and week 34, the Lab had statistics to show that class 5 cards GPUs (e.g. ATI Radeon HD 7800, 7900, 8900, 8950 + similar, nVidia GTX 460/460SE, 465, 550TI, 580, 660/660TI + similar) actually performed better with ALM enabled than with it off, while class 4 GPUs showed little difference between having ALM enabled and disabled. However, because measurements do tend to be subjective (again, frame rates, etc., can take on different levels of importance depending upon what you are doing in SL), Oz Linden had been hoping to establish a means by which more controlled testing could be undertaken within the Lab; it’s currently unclear how far this has progressed, if at all.
Interest List Viewer
Andrew Linden revealed that the interest list RC / project viewer (however it appears) is now unlikely to debut before November 12th. “There was a performance regression that we’re working on — lower FPS in project interesting,” he informed the Simulator User Group meeting on October 29th, “Probably because it is rendering more objects — more small objects in view get rendered (that’s my theory anyway).”
Andrew Linden: Anti-griefing Work
Andrew Linden is back working on various pieces of anti-griefing work.
For obvious reasons, he doesn’t want to go into specifics, but he did indicate that he’s looking to address new griefing modes that are aimed at estate managers. He’s also been thinking about ” raising the arms race against landbots”, although he admits he is “still in the planning/discovery phase on that.”
There are a number of other items in his list as well he may well be taking a look at.
Other Items
Slow loading Sculpts?
Some people are reporting they are seeing sculpts loading a lot more slowly since the last set of server-side interest list updates. It’s not clear how widespread this might be or if it is a possible placebo effect. For his part, Andrew Linden felt that sculpts potentially download faster with the interest list viewer code (which, as noted above, has yet to make a public debut), but again he caveated why this might appear to be the case. Andrew indicated he’ll look a little more into this.
Last Owner / Previous Owner
Many TPVs expose details of the “last owner” of an object through the build floater. A request has been passed to make this information, which is stored as a field in the object data, accessible through scripts. Both Simon and Andrew Linden didn’t see why this could not be done, with Andrew stating he’ll see what’s involved and will look to someone to nudge him about it next week.
Inara Pey: Living in a Modemworld 