SL projects update: week 16 (4): More on SSB, materials and FMOD Ex

Server-side Baking / Appearance

Viewer Releases

An updated beta viewer was released on April 19th (, with release notes here), which contains a range of updates, including several for SSB/A. Speaking at the TPV Developer meeting on Friday, 19th April, Oz Linden indicated that the current plan from the Lab is that this is likely to be the last beta viewer release for the SSB/A code unless a major blocker shows up. Assuming this doesn’t happen, then it is more than likely the SSB/A will move to the SL viewer release channel and arrive as a viewer update towards the middle of week 17 (week commencing Monday, 22nd April), which should hopefully be an automated update for most users on the SL viewer, given the majority appear to keep that option active on their viewers.

Given us, it is liable that we’ll start seeing more TPVs updates appearing in the near future – and people using TPVs are going to need to start installing and using those updates rather than remaining with older versions of their viewer if they are to avoid the “grey people” syndrome as the server-side of SSB/A is deployed.

Users will need to update to version of their preferred viewer supporting SSB/A as they are made available to avoid seeing grey people
Users will need to update to a version of their preferred viewer supporting SSB/A as they are made available if they are to avoid seeing grey people once the deployment of the server-side of SSB/A commences

Server-side Deployment

The precise means by which the server-side will by deployed is still not absolutely clear. As noted a number of times in this blog, Nyx Linden is hoping that things will progress somewhat cautiously, possibly starting with a set of “carefully selected and constrained regions on Agni” as the viewer code reaches the SL release viewer. This still appears to be the case, but it is possible that it will not – as Nyx has previously hinted – roll through the Release Candidate channels.

“I don’t know whether it will go through the normal RC process,” Oz Linden commented at the TPV Developer meeting, “Because it’s not actually a server software change; it’s a configuration change, so they don’t need to deploy it through the RC progression. All they have to say is, ‘Yes, throw the switch!'”

If this approach is taken, it’s currently not clear whether or not it will require a region restart.

In terms of time frames as to when this might happen, things are similarly unclear at this point – a lot depends on how well the testing on the selected Agni regions progresses. However, Oz suggested that the time frame in which the “switch may be thrown” to be anything between 2 and 6-8 weeks from when the viewer-side code appears. His analogy was that of a bell curve, wherein the switch-over could occur at the top of the curve – but could, if circumstances dictate, occur at either end of the curve.


It is still hoped that there will be a concerted effort on the Lab’s part to communicate server-side baking ahead of any server-side flipping of switches. A blog post is apparently in preparation, which should go out when the SSB/A code is issued in the release viewer; whether this will be supported by other means of communicating the changes is unclear.

However, communications on the whole is not easy – even with the TPVs also liable to be spreading the word through blogs, etc., (as Firestorm have already). This is because even with the official blog, TPV blogs and blogs such as this one, the vast majority of SL users do not read blogs.

Matters are also further complicated by the fact that there are over 1700 different viewer strings which are used to connect to SL (even if not on a daily basis). These not only include the official viewer and current versions of TPV-registered viewers, but also many instances of older versions of TPVs, Snowglobe (1.x) based viewers, several versions of the official 1.x viewer (some of which date back over 5 years), viewers which are not registered with the TPV directory, self-compiled versions of various viewers, and so on.

As such, whatever the effort made to communicate the arrival of SSB/A is liable to be missed by a good number of users and people are going to find themselves facing grey avatars as a result of the switch to SSB/A, because many of these additional viewer strings will not have the necessary viewer-side code. This inevitably means that there is going to be some disruption and upset. While this in turn doesn’t mean that attempts to communicate the coming change shouldn’t be made – but it does mean that even with the best efforts of the Lab and TPVs combined in communicating SSB/A, there is going to be an outcry. So anything all those who are aware of the upcoming changes can do to communicate it to others – particularly when there is a visible log post from LL on the matter which can be referenced – can only help lessen the volume of that outcry.

Materials Processing

As noted earlier in this week’s updates, a further release was made for the Materials Processing project viewer (, April 17th). Work is progressing on both the viewer and the server for materials, although there is still some way still to go before things start to settle down.

Commenting on progress at the TPV Developer meeting, Oz extended his thanks to all who have been assisting with the testing (and filing bug reports) before continuing, “We think we’re pretty close to being frozen on the shader changes and on the rendering pipeline side.”

He went on to explain that while it is generally acknowledged that the project viewer’s UI is “pretty buggy” in terms of the materials options, and that there are a number of UI issues to be sorted out, the Lab’s approach has been to focus on the rendering side of things, the thinking being that if you can’t tell what the rendering code is doing, you cannot be certain whether or not an issue seen through the viewer is a rendering pipe issue or an actual viewer UI bug. However, it is anticipated than the rendering updates will be out of LL’s QA “very, very soon” and attention will then switch back to UI issues and fixes – such as getting materials updates to happen consistently and smoothly, as with MATBUG-16, which I’ve previously noted in this week’s reports.

More work is required on the viewer-side of materials processing, such as smoothing out issue like MATBUG-16, which sees problems occurring with applying materials to different faces of the same object (in this case, applying a normal map to the green face of the prim sees the map also applied to all the other faces)
More work is required on the viewer-side of materials processing, such as smoothing out issue like MATBUG-16, which sees problems occurring with applying materials to different faces of the same object (in this case, applying a normal map to the green face of the prim sees the map also applied to all the other faces)

One issue which may be occurring between the viewer and the servers, as identified with tests on OpenSim and reported by Latif Khalifa, is that both UDP and HTTP are being used within the materials code – with UDP being used for applying textures (diffuse maps) to object faces, and HTTP for everything else – and the simulator code appears to be particularly sensitive to the order in which the two messages (UDP and HTTP) come from the viewer, such that if the UDP message is received after the HTTP message, the materials settings are effectively erased.

Gamma Correction

Gamma correction is a feature which was first introduced in the Exodus viewer around a year ago, and has subsequently appeared in some other TPVs. Speaking at the TPV Developer meeting, Geenz Spad, one of the architects of the materials processing capabilities said:

If you have this [gamma correction] you will want to remove it before merging materials. With materials, we do have gamma correction within the viewer; it is always enabled whenever you have deferred rendering [the Advanced Lighting Model in Graphics Preferences] enabled … If you have Exodus’ gamma correction code, you will want to remove it; it will conflict; it will not work well when you actually try to merge materials. So just a heads-up that if you have merged it, now would be a good time to start removing it.

Beyond this, and given the status of the materials viewer-side code, the Lab’s recommendation is that TPVs do not attempt to merge the viewer code at this point it time, as doing so is liable to creative more headaches for TPVs until the code is in better shape – although the hope is that the Lab will be in a position to green-light the use of the code sooner rather than later.


FMOD is used within the sound system for the Viewer, and until recently, Linden Lab has provided a script which pulls library files from a FMOD repository for use in viewer builds. However, following a clean-up of their archives in 2012, FMOD removed the some of the legacy files required for this, as was reported at the time in JIRA OPEN-150. These are something which is particularly visible to the vast majority of users, as it is all “behind the walls stuff”, as Monty Linden might say, but it is an important element within the viewer.

As a result of the FMOD changes, the Lab has opted to use FMOD Ex, and this is now starting to be deployed into the viewer channels, with an initial release to the development viewer ( on April 18th. This is liable to receive a further update prior to progressing, as Latif Khalifa has submitted a fix for an issue with music stuttering every few seconds when using FMOD Ex (see OPEN-173).

If all goes according to plan, the FMOD Ex updates (and a few other fixes) should be appearing in the beta viewer as the next set of updates to follow-on from the SSB/A, and could be doing so as early as the latter half of week 17 or early in week 18.

There are still some issues around how TPVs will integrate the required FMOD Ex files into their builds, as the mechanism by which the files could be pulled from the FMOD repositories (managed by a script supplied by LL) does not work with FMOD distribution model using with FMOD Ex, and attempts at the provision of a pre-packaged option would likely result in lawyers having to be involved due to licensing, and therefore, in Oz’s words, “That’s not all that likely.” In the meantime, some TPV developers are themselves looking at options for FMOD EX builds.

Related Links