Server-side Baking / Appearance
Yesterday, I reported on the SUN-74 issue (Apparent avatar skin and eye texture asset corruption with Server Side Appearance), which can impact users with avatars wearing modifiable skin and/or eyes and/or hairbase who enter (via teleport or crossing a region boundary) an SSB/A-enabled region while using a non-SSB/A enabled viewer (e.g. such as Phoenix or the v1.23.5 viewer) and leave them with a corrupted copy of the worn skin / hairbase or eyes. At the time I noted that the matter was under investigation by Linden Lab, and no decision had been made on how to handle it.
Speaking at the TPV Developer meeting on Friday May 31st, Oz Linden provided an update on the issue and spoke more generally on the issue of the use of olfder (non-SSB/A capable viewers) going forward:
We don’t actually know what’s ultimately going to be done about that; that’s a subject of vigorous discussion that’s going on even as we speak, so we’ll see how that plays out. I think it’s fair to say that regardless of what happens with that particular issue … I will just make the observation that there are still people really, really old viewers [and] there is no way, no way at all, that we could even begin to test for compatibility back with all of those viewers.
As it is, as recently as this last week there were 1,665 different viewer version strings reported as connecting to the main grid (these include 151 versions of Singularity, 50 versions of Phoenix, 262 labelled as Firestorm, and so on). Some of these may be “one offs” self-compiled builds (which may or may not have the most recent updates to support something like SSB/A), but even so, given the overall number of viewer strings, it is understandable why the Lab view attempt to ensure so many different viewer versions were fully compatible with anything on the grid is a next to impossible task.
This does not mean that the Lab is going to ignore SUN-74, right now they are still investigating the problem and trying to reproduce it in a consistent manner (which is apparently proving difficult for a number of reasons, not the least of which is that some older viewers simply crash when attempting to repro the corruption). However, what it does underline is the need for people to upgrade to an SSB/A-enabled version of their preferred viewer sooner rather than later.
The reason for this is that very soon the Lab will start undertaking more widespread testing of the new service by enabling it across a number of regions across the grid. These regions may not necessarily be constrained to any of the usual RC channels, but could well be a mix of regions from all of the various simulator channels, making them harder to identify and avoid. This testing will be to gain greater insight into how the service stands up under “real avatar loads” – something which is impossible to carry out to any great depth on Aditi, as there simply isn’t the volume of users active there.
Once this more widespread testing starts, then it is entirely possible that users who remain on non-SSB/A capable viewers are going to encounter issues and problems beyond seeing grey avatars which the Lab are not going to address, simply because the issues can be resolved by a viewer update.
So the word really is, update, update, update.
The Materials Processing viewer is now at a beta release (188.8.131.526764). Please refer to the Lab’s official announcement on the release, and also my overview of the release, which includes a short summary of materials in Second Life.
Currently, TPVs are being encouraged to adopt the materials code as soon as they can. However, given the amount of work being focused on SBB/A at the moment, it could be a while before all TPVs manage to integrate the materials code into their viewers.
Viewer Release Process and Upcoming Releases
Referring to the new viewer release process at the TPV developer meeting, Oz reiterated recent comments on the status of the work, as reported in these pages, saying:
Hopefully, within a couple of weeks we’re going to be shifting to the new release process fully. Testing on that is going really, really well. Needless to say, since it touches viewer upgrades and log-in, we’re being extremely conservative about testing everything as thoroughly as we possibly figure out how to do before we try to touch any production systems. But so far the testing is going really well, and I think we’ll be able to start tweaking that pretty soon.
What this will mean is that as the new process coming into effect, possibly around or before the Materials Processing viewer goes to a release status, we’ll start to see multiple project and beta viewers start to appear as various viewer-related projects and activities within the Lab mature to a point where they are ready for release in some form. In fact there is already something of a pipeline of possible releases forming, which includes:
- A collection of open-source contributions to the viewer which is hoped will appear as a release candidate viewer pretty quickly
- A “pretty substantial batch” of maintenance fixes for the viewer
- Vivox updates, which Oz described as, “Finally getting attention again, and will probably be in a release candidate version ‘real soon’ now”
- An Experience Tools viewer which is also expected to appear “real soon”
- An interest list update viewer, which is believed to be getting closer to being stable
The experience tools viewer is expected to interact with the “experience keys” project code deployed grid-wide on the servers in week 20, and which are believed to be part of the experience tools project initially rolled-out in August 2012 after an initially rocky start earlier that year. The Lab is apparently developing documentation to accompany this work, but it is “not done enough yet” for general release.