SL projects update week 18 (1): viewer, SSB/A and materials

Server-side Baking / Appearance

The viewer-side SSB/A code continued in the SL beta viewer with a release on April 24th ( However, the crash rates from that version were sufficiently low for the go-ahead to be given for the deployment of the SL viewer with the SSB/A code incorporated, which reached public release on April 30th (

SSB/A in the SL release viewer: I'm running the SSB/A-enabled SL release viewer and can see both myself and my alt (running SSB/A-enabled Firestorm) rendered correctly, and she can see fully rendered.
SSB/A in the SL release viewer: I’m running the SSB/A-enabled SL release viewer and can see both myself and my alt (running SSB/A-enabled Firestorm) rendered correctly, and she can see fully rendered.

This now means that the following viewers and clients are, at the time of writing, now SSB/A capable:

  • SL viewer (release)
  • Firestorm (release)
  • Kokua (development)
  • Nirans (alpha test)
  • Cool VL (stable release)
  • Kirstens S19.1.19.4 (unsupported)
  • Singularity (release)
  • Lumiya 2.4.4 (release)
  • Metabolt version (Beta)
  • Radegast 2.12 (release)

The remaining major players for Second Life – Catznip, Dolphin and Exodus will doubtless have SSB/A versions out in the very near future.


Cinder Roxley is working on an alternate approach to the issue of the z-offset and is meeting with some success. However, there is still a problem with the distance offset being inconsistently reported between the user’s viewer and by other viewers (so the avatar may appear at a different height above ground / an object when seen by others in comparison to how they see their own height. Cinder is continuing to work on the problem. If she is successful, the code will doubtless be made available to all TPVs should they wish to adopt it.

Current Outfit Folder Corruption

I reported on this issue in week 17, wherein a Current Outfit Folder (COF) corruption can leave a user unable to log-in to SL and – unless they have a Premium account – beyond official help. This has been something of a longstanding issue, as per JIRA SVC-7653, and has an associated work-around. The concern here is that the workaround will no longer work once SSB/A is enabled server-side.

Commenting on the situation, Nyx Linden said, “we’re looking into a number of fixes around COF for followup releases,” before going on, “Yep, we have people looking at this. Please do continue to let us know as you see cases come up. I’ll sync up with our engineers looking at this and make sure that we have these cases covered.”


Whirly Fizzle recently reported an issue arising from the recent SSB/A code – removing any worn item from avatar results in all temp attachments being taken off (see JIRA SUN-69). This problem occurs whether or not an avatar is on SSB/A regions. It was first noted in the SL development and beta viewers, but appears common to all viewers with the SSB/A code, including the new release version of the viewer referred to above (

Server-side Deployment

With the arrival of the viewer SSB/A code into the SL release viewer, deployment of the server-side code is liable to commence on the main grid. As previously noted in these updates, the plan is for a “constrained” number of regions on Agni to be SSB/A-enabled in order to load test the system. It appears likely that these regions will not be a part of the normal Release Candidate channels (although this is not absolutely clear).

The purpose of this action will be to further stress / load test the new server-side baking service and (hopefully) ensure there is sufficient hardware deployed to support the capability and that there are no unexpected issues arising from large numbers of people starting to the use the system.

There is currently no commitment from LL as to how long this “test” period will last, or what will happen once it is deemed to be successful. The most recent word has been that as SSB/A is a configuration change, the deployment will not follow the usual RC channel release progression, but will be a matter of a decision being made on the ability of the new service to support the main grid, and then a “switch” being flipped to enable the service across the entire grid, which may or may not see a rolling restart take place. Obviously, the decision on when to “flip the switch” will in part depend on the volume of users logging-in to SL using SSB/A-capable viewers and using them and passing through the regions which have been enabled with the server-side code.

Materials Processing

The code remains in a project viewer for the time being. There are still a number of bugs to be fixed, including MATBUG-16, which I’ve previously reported, and MATBUG-38. The latter relates to a normal map being applied to an object / object face being given an arbitrary glossiness  even though no specular map has applied, and the glossiness cannot be adjusted using the specular map gloss spinners.

MATBUG-16. Apply a normal map to an object / object face with no specular map, and an arbitrary glossiness is applied (see the right face of the prim), which cannot be adjusted using the specular map options on the build floater (materials project viewer
MATBUG-38. Apply a normal map to an object / object face with no specular map, and an arbitrary glossiness is applied (see the right face of the prim), which cannot be adjusted using the specular map options on the build floater (materials project viewer

It’s likely a further update for the project viewer will be out soon – possibly this week – which addresses further issues.

Questions have again been raised on adding further materials capabilities, such as displacement maps. However, the Lab remains focused on getting the materials functionality they have committed to completed and fully deployed. Once deployed (to the SL release viewer and TPVs), it is also likely to be a while before any statement is made on the matter of future updates in order to allow time for the system to gain use and for the Lab to receive more widespread feedback as well as seeing how the capabilities are adopted by users.

Other Bits

Viewer GPU Table Problem

There appear to be some issues affecting the latest GPU tables from Linden Lab, with some entries being either incorrect or missing. nVidia 550 cards and some GTS series cards. This has caused some problems for users updating to recent viewer releases of their preferred viewer (notably Firestorm, although the problem is thought to be with the SL viewer as well).

Tankmaster Finesmith of the Firestorm team has and updated GPU table available for downdoad. If you are experiencing issues with a recent update of your viewer, you can try downloading the file linked-to above and using it to replace the current gpu_table.txt file in your viewer’s install folder. However, make sure you don’t rename the file when doing so, or your viewer will not be able to find it.

Black Screen

Some Firestom users are experiencing a totally black screen on logging-in to SL. User interface, tags, and hovertips are visible, but the rest is a sea of black. This problem has so far shown up only on machines with ATI graphics cards and older graphics drivers, both Windows and Mac. A similar problem has also been reported on the SL beta viewer by ProductEngine Linden.

The Firestorm team have provided some notes on working around the problem for those affected, which may also work on the SL beta viewer as well for those using it. It has also been suggested that those encountering the problem also double-check to ensure they are using the more up-to-date drivers for their GPU.

Related Links

4 thoughts on “SL projects update week 18 (1): viewer, SSB/A and materials

  1. This week’s Main Channel rollout was announced to be a rollback to a previous version.

    I think SSB/A might be more delayed than we expect.


    1. The SSB/A deployment looks like it’ll be well clear of this recent issues. The initial testing has been estimated at anything from two to eight weeks following the arrival of the viewer code in the SL release viewer – and potentially mosy likely to come in the middle of that period (say around four weeks hence). As Oz described it recently, imagine the time period as a bell curve; the “switch” is most likely to be “thrown” in the middle of the curve – but could could at either end.

      The re-deployment of an older version of server code to the Main channel was due to ongoing handshaking issues between regions.


      1. What worries me is that Oz seems to be talking as if there is no code in the sim server which will need testing. And we don’t know whether the necessary code changes are lurking in current servers or not.

        It shouldn’t mess things up the way some code changes have, but just saying that makes me uneasy.


Comments are closed.