This summary is published every Monday and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:
It is based on my Viewer Round-up Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware) and which are recognised as adhering to the TPV Policy
By its nature, this summary will always be in arrears
The Viewer Round-up Page is updated as soon as I’m aware of any releases / changes to viewers & clients, and should be referred to for more up-to-date information
The Viewer Round-up Page also includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.
Updates for the week ending: June 9th, 2013
SL Viewer updates:
Materials Processing beta updated to version 3.6.0.276961 on June 5th and then to 3.6.0.277049 on June 8th (release notes)
Niran’s Black Dragon beta updates to version 2.2.1 on June 4th – core updates: UI and skin changes
Moble Grid Client updated to 1.19.1182 (minor improvements on user interface) and then to 1.20.1185 (show elevation in nearby chat and nearby people list)
Pocket Metaverse updated to version 1.8.1 on June 10th – core updates: general bug fixes; improved About screen accessible from Settings screen, now displays device info (MAC address) necessary to provide Linden Support if user can’t log in
Depreciated / Discontinued Viewers
SL Development viewer – depreciated as of version 3.5.2.274629 April 24, 2013
Zen Viewer – discontinued by developer and no longer available, January 27th, 2013
Phoenix viewer – development and support ended on December 31st, 2012
As usual, the latest updates, feedback and comments can be found on the deployment discussion thread. Anyone encountering a specific bug is asked to file a JIRA.
There was no SLS Main channel roll out this week
On Wednesday June 5th, the Release Candidate channel received the following packages:
BlueSteel and LeTigre were updated with a new server maintenance project. This project addresses a disconnection issue and also fixes a crash mode – see my notes from week 22, and a fix for a crash mode
Magnum remained on the same interest list improvement project as originally deployed to LeTigre in week 21, and to Magnum and BlueSteel in week 22, with some updates. Two of these fix what Andrew Linden describes as “two rare crash modes”. The package should also include the same disconnection issue fix.
Interestingly, the “large” scripts issue I reported on in part 1 of this update was given as the reason why there was not Main channel deployment this week. As previously reported, the fix for this issue, which prevents the text of previously saved scripts from being displayed in the script editor for users on slow connections, failed to make the cut for the week 23 deployments.
There are continuing reports of “invisible avatars” on Magnum regions. This issues was first reported following the week 22 deployments, and described as “on an in-region teleport when landing all surrounding avatars de-rezz and cannot be seen until the person re-logs. Everything else appears normally.” The problem appears to be random in nature, and was also noticed at one club which enjoys a high level of attendance. and which still appears to be encountering the same issue. During the Beta Server meeting on Thursday June 6th, this issue was discussed, and appeared to be most strongly linked to v1-based viewers.
SL Viewer News
The next release of the materials beta viewer arrived on Wednesday June 5th (3.6.0.276961 with the release notes here), and as I indicated in part one of this report, sees the beta once more installed into the “correct” folder (SecondLifeBetaViewer). This means the initial beta release needs to be uninstalled separately, as the updated version obviously won’t over-write it.
The materials project beta viewer had its first update on June 5th, with the release of 3.6.0.276961
In terms of beta releases in the future, it’s worthwhile again pointing-out that once the new viewer release process comes into effect, beta viewers will be installed into folders identified by their project name (e.g. something akin to “SecondLifeBetaMaterials”). Viewers should be fairly well self-contained (although they may still share the same default settings location, as that remains to be seen once things start rolling), so the uninstalling of individual beta versions (or RC versions) shouldn’t be a problem once they reach release status.
Work continues in preparing the new viewer release process for … release (or implementation). It’s still unclear whether it will arrive before or after materials moves to the release viewer. As reported in week 22, the current pipeline of releases we should be seeing as the new release process rolls forward 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
Server-side Baking / Appearance
Investigations have been continuing into the SUN-74 issue which affects non-SSB/A updated viewers (notably Phoenix), with Nyx Linden commenting at the Server Beta meeting that, “Thanks to the support from the phoenix/firestorm team, we’ve been able to identify the cause of that issue. We’re looking into what options are available to us. [It] took some backflips to get it in a debugging environment, but managed to hunt it down – a combination of factors from not having the last 4 years of appearance fixes :)”
Apologies for the slight delay in getting this update out, real life is proving a little time-consuming at the moment.
Server Deployments, Week 23
As usual, the latest updates, feedback and comments can be found on the deployment discussion thread. Anyone encountering a specific bug is asked to file a JIRA.
Second Life Server (Main) Channel
No rolls are planned for the week 23.
Release Candidate Channels (RC)
On Wednesday June 5th, the Release Candidate channel should receive the following:
BlueSteel and LeTigre should get a new server maintenance project. This project addresses a disconnection issue and also fixes a crash mode – see my notes from week 22, and a fix for a crash mode
Magnum will remain on the same interest list improvement project as originally deployed to LeTigre in week 21, and to Magnum and BlueSteel in week 22, with some updates. Two of these fix what Andrew Linden describes as “two rare crash modes”. The package should also include the same disconnection issue fix.
A further fix had been planned for the RC channels. This relates to people’s inability to download “large” scripts. This relates to the code path used for script uploads / downloads having a bug, such that you can write a lengthy LSL script and save (upload) it, but on trying to edit it once more, the text of the script will not display. The issue is thought to be related to bandwidth use, and while a fix has been developed by Andrew Linden, but it failed to make the QA cut for this week’s RC releases.
Viewer News
There have been reports of issues with the materials beta viewer, including:
Crashing when logging-in to SL on systems using Intel graphics
Issues with transparent alphas showing as white and semi-transparent alphas showing as black, which also appears linked to systems with Intel-based graphics
The Lab is currently working on a fix for the Intel issue, but the alpha issue is apparently providing difficult to consistently reproduce
That the materials beta viewer (3.6.0.275764) installs into a different folder to previous SL beta viewers (SecondLifeBeta rather than SecondLifeBetaViewer), as reported in my overview of the materials beta release, appears to have been an error on the Lab’s part, and it appears likely the additional releases will revert to the SecondLifeBetaViewer folder until such time as the new viewer release process comes on-stream.
Server-side Baking / Appearance
The Lab continues to investigate SUN-74, although there has been no major progress since my last update. The JIRA itself has been updated as a result of further TPV testing.
In terms of any deployment time frames, the Lab still will not be drawn on dates at the moment (again, understandably, even the likes of SUN-74 and the need to try to push more users into updating to viewers which do support SSB/A). Replying to a question on possible deployment beyond the current close beta regions at the Content Creation UG meeting on monday June 3rd, Nyx Linden would only say, “SSA will be deployed slowly and carefully when its ready, we’re working with third-party devs to make sure the last of the bugs are found and hunted down.”
Interest List Update
Andrew Linden – who marked his 11th rezday on June 4th, 2013!
As Andrew has been involved in trying to resolve the “large” script bug described above, he’s not had time to make further progress on the “Meeroo issue”, which can affect other scripted animals, etc., as well, and which he describes as:
If you turn your camera away from a crowd of Meeroos, wait several seconds, then turn back around… the Meeroos will be updated, but not quite in the right order. So sometimes you’ll see a head move to the new position, then a fraction of a second later the rest of the body. So I have a theoretical fix that doesn’t crash the simulator (anymore).
As noted recently, he has developed a partial fix for this problem was deployed as a part of the current interest list updates, and he now hopes he’ll be able to focus on developing a more complete fix, which will mark the final aspect of server-side interest list work for the moment.
This summary is published every Monday and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:
It is based on my Viewer Round-up Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware) and which are recognised as adhering to the TPV Policy
By its nature, this summary will always be in arrears
The Viewer Round-up Page is updated as soon as I’m aware of any releases / changes to viewers & clients, and should be referred to for more up-to-date information
The Viewer Round-up Page also includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.
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.
Whirly Fizzle demonstrates one aspect of the SUN-74 issue – on a non-SSB/A viewer, her MOD skin has turned black / invisible and her MOD eyes have turned white as a result of entering an SSB/A-enabled region and responding with YES to the given prompt.
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.
After recent delays as the code passed through QA, the Materials Processing viewer unexpectedly reached beta release on Friday, May 31st with the release of version 3.6.0.275764, accompanied by a blog announcement from the Lab.
Materials processing brings normal and specular maps to object surfaces in Second Life (prims, sculpts and mesh – but not avatar skin / clothing layers). The capability has been developed as a collaborative effort between TPV developers (notably from the Exodus, Catznip and Firestorm teams), content creators and Linden Lab.
Note: The following two sections are not intended to be a technical discussion on computer graphics mapping or a detailed analysis of normal & specular maps. It is intended purely as a broad, non-technical of the latter.
Normal Maps in a Nutshell
Normal maps (sometimes referred to as bump maps, although they are more rightly the most common form of bump map) are a means of faking high levels of detail on an otherwise bland surface by means of simulating the bumps and dips that create the detail. Normal maps can be created in several ways.
For example, when working with 3D models, a common method is to make two models of the same object: one a very complex, highly detailed model with a high polygon count, the other a much lower polygon count model with significantly less detail. An overlay process is then used to generate a normal map of the detailed model’s surface features which can be applied to the less complex model, giving it the same appearance as the highly detailed model, but for just a fraction of the polygon count, reducing the amount of intensive processing required to render it.
Using a normal map to enhance the detail on a low-polygon model. The image on the left shows a model of some 4 million triangles. The centre image shows a model with just 500 triangles. The image on the right shows the 500-triangle model with a normal map taken from the model on the left applied to it (credit: Wikipedia)
Another common way to produce a normal map is to generate it directly from a texture file. Most modern 2D and 3D graphics programs provide the means to do this, either directly or through the use of a plug-in (such as the nVidia normal map filter for Photoshop or the GIMP normal map plugin). When combined with diffuse maps, the normal map creates the impression of surface detail far greater than can be achieved through the use of the texture alone.
Normal map from a texture: left – the original texture (diffuse map) and its normal map shown as a split view; right – the material resultant from applying both maps to surfaces inside a game (credit: Valve Corporation)
Specular Maps in a Nutshell
In the real world, every highlight we see in an object is actually the reflection of a light source. Surfaces and surface details reflect light differently to one another, depending on a range of factors (material, lighting source point(s), etc.). Specular maps provide a means of simulating this by allowing individual pixels in an object to have different levels of brightness applied to them, giving the illusion of different levels of light being reflected by different points on the object.
When life gives you lemons: a mesh lemon with (l) a normal map applied, and (r) a normal and a specular map together. Note how light is apparently being reflected across the surface of the latter (credit: Mind Test Studios)
Like normal maps, specular maps can be produced in a number of ways, both within 3D graphics modelling programs and in tools like PhotoShop. As shown above, they can be combined with normal maps and textures to add detail and realism to 3D models and flat surfaces.
Second Life itself already includes a very dynamic example of how materials can be combined to create in-world effects in the form of Linden Water. This is created using an animated normal map to create the wave-like effect for the water, while an animated specular map adds the highlights and reflections. The result is a very realistic simulation of moving water able to catch and reflect sunlight.
Some key points about materials processing:
Effects will currently only be visible when using the Materials Processing beta viewer
In order to be visible in your world view, whether you are creating objects using materials processing OR whether you simply want to see them in-world, you must have the Advanced Lighting Model (previously “Lighting and Shadows” and often referred to as “deferred rendering”) option in Preferences > Graphics enabled
Note that this does not mean you also have to enable shadows themselves – you can leave the drop-down set to None and still see materials in use in-world, thus minimising any impact on your frame rates
The Lab has done a lot of work on the rendering pipeline to improve performance; as such, if you’ve not run with the Advanced Lighting Model / deferred rendering enabled on your computer due to previous performance issues you might find you can now enable Advanced Lighting Model in your viewer without experiencing a dramatic loss of frame rates
When creating objects which use materials processing, note that they will automatically move to the “mesh” accounting system for land impact, which can affect the impact value assigned objects and models
Materials capabilities do not work when under Linden water.
Inara Pey: Living in a Modemworld 