The following is summary of changes to SL viewers / clients (official and TPV) which have taken place in the past week. It is based on my Viewer Round-up Page, which provides 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 being in adherence with the TPV Policy.
This summary is published every Monday, and by its nature will always be in arrears. Therefore, for the most up-to-date information on viewers and clients, please see my Viewer Round-up Page, which is updated as soon as I’m aware of any changes, and which includes comprehensive links to download pages, blog notes, release notes, etc., for Viewers and clients as well as links to any / all reviews of specific viewers / clients made within this blog.
Updates for the week ending: 15 July, 2012
SL Viewer updates:
Beta version: rolled 126.96.36.1991355, July 10
Development: rolled to 188.8.131.521706, July 13th
Pathfinding rolled to 184.108.40.2061768, July 14
Dolphin rolled to 220.127.116.1114 on July 14th, which had an issue with broken shadows and so was followed by 18.104.22.16807 on July 7th – core changes: code in SLPlugin has been changed in order to limit the number of virus warnings from anti-virus s/w; FIRE-6171/VWR-28846; ‘Save as’ dialog deadlocks on Ubuntu 12.04; FIRE-4730 – Client AO breaks attachments with animations, for example shoes with “Ankle locker”; additional Windlight settings from Firestorm; Fixed: Don’t block texture fetch threads for 2 minutes if the CURL callback fails (release notes)
Niran’s Viewer rolled to 1.44 on July 9th – core changes: use of LL’s Viewer rendering code; performance improvements; faster rendering of shadows, local lights, occlusion, etc.; integration of tone mapping from the Exodus Viewer
Zen Viewer rolled to release 22.214.171.124 on July 9th – core update: fixed a Merchant Outbox Network Connect Error (release notes)
Cool VL Viewer made two releases:
The release version rolled to 126.96.36.199 on July 13th, reported as a bux fix release fixing breaks to the texture vertical offset spinner and the land brush force slider in the build tools floater
An experimental build 188.8.131.52 was also released on July 13th, which is the first phase of a backport of the viewer v3.3 renderer to the Cool VL Viewer
Singularity rolled to 1.7.0 on July 16 just prior to my viewer round-up being updated, and so makes this report; core updates – Multi-Wear release; general graphics engine update; region windlight support; RLVa partial update to 1.4; LSL editor update; sound system bug fixes & new sound system FMOD Ex; mouselook gun aiming incorporated; new build preferences; radar now indicates gesture/sound/particle/animation spam; holding Shift while crouching works as crouch toggle (release notes)
On the 29th June, Linden Lab announced Project Shining, aimed at improving avatar and object streaming speeds. At the TPV/Developer meeting on Friday 13th July, the project was discussed in terms of how the various elements within it will affect Second Life viewers.
The following is a summary of that discussion, based on the recording of the meeting, and focused primarily on the viewer changes / updates that will be most directly seen / felt by the majority of users.
Commencing at 22:30 into recording.
The aim of this project is to improve the underpinning HTTP messaging that is crucial to simulator / simulator and simulator / Viewer communications. Monty Linden is leading this project.
LL will release a project viewer containing a new “wrapper” implemented around how data is handled and a new texture fetch library (see time frame comments at the end of this article)
Providing there are no major problems with the project viewer, the initial code release will move to a release version of the viewer
This will be followed by changes to group services and a “more ubiquitous” use of the library in the viewer – which is where Oz’s warning to TPV developers comes into play, as some services and the behaviours will start to change to improve throughput and reliability – and may even help improve the SL experience for those on older routers.
As a side note, some of this work has involved router testing aimed at determining what router hardware is compatible with Second Life. While it is hoped that work around the HTTP libraries will improve the SL experience for some using older router hardware as noted above, the tests have revealed that certain types of older router – Linksys WRT and Belkin G series routers were specifically named – are not compatible with running Second Life.
Commencing at 32:38 into the recording.
The aim of this work (Project Sunshine) is to improve issues around avatar baking and to eliminate bake fail issues. It will primarily focus on moving the emphasis for the baking process from the viewer to a new Texture Compositing server. The viewer will retain some elements involved in avatar baking – the actual baking of the avatar shape (i.e. shape values and IDs) will still take place on the viewer side, for example.
Precisely how this new service will work on the server-side of things is yet to be fully determined by Linden Lab. However, work is progressing on the viewer side of the equation, with the current key points as follows:
The new service will use the Current Outfit folder to drive the new baking service
TPVs not currently supporting Current Outfits will have to implement it, otherwise they will effectively fail on avatar baking
The basic process will be that when it is time to send a rebake request (e.g. after a user has finished editing their appearance) the viewer must send a new message to the baking service which effectively says, “Look at the contents of my Current Outfit folder and give me back a new appearance based on that”
Viewers in general will have to support this new message that is sent to the service, and change how they perform the fetching of avatar textures; for the technically inclined, this will be HTTP without UDP fallback.
Currently, the plans is for LL to integrating the new way of doing avatar baking into their viewer code, which will be available for TPVs to integrate – although none of the Linden Lab 1.x code will be updated to support the new process, so this will effectively break their own Viewer 1.23.5, which currently is still in use within SL.
The viewer code will support both the “current” method of avatar baking (within the viewer itself) and the new baking service (using the Texture Compositing server) until the new service is fully rolled out across the grid. This means that if a user is in a region that does not make use of the new baking service, avatar baking will continue to be handled using the viewer-side mechanism we currently have. However, if the user is on a region that utilises the new baking service, avatar baking will be handled through that. The viewer will be able to recognise whether it is connected to a region supporting the “new” method through the region capabilities.
In order to ensure as smooth a transition to the new baking process as possible, LL are proposing a relatively long lead-in to the new service, making the code available well ahead of the new service being enabled, allowing TPVs to integrate it into experimental builds. The server-side changes will initially be implemented on a number of beta grid regions for testing with viewers there, prior to being scaled-up. The server changes will then be released onto the main grid in a controlled manner and then scaled up from there.
What Does This Mean for Users?
If all goes according to plan, and providing that you keep up-to-date with releases of your preferred viewer, this actually shouldn’t mean very much in real terms. There are however a number of things to be aware of:
If you use a viewer that is not updated to use the new code (i.e. the official viewer 1.23.5 or a viewer that is not updated to use Current Outfit folder and / or to support the new bake request message / HTTP texture fetch mechanism) OR you continue to use an old version of a viewer rather than updating, there will come a time when your avatar – and those around you – will not bake correctly
There are two issues that may occur during the transitional period when both the “current” and the “new” baking methods are in issue:
When teleporting or crossing between regions that use the different methodologies, users will experience their avatar rebaking, as the viewer will effectively be using two sets of data for the bake process
If there are two adjacent regions, one of which is uses the current avatar bake process and the other is using the “new” baking service viewers in one region will not be able to correctly resolve the textures of avatars in the other region
It is hoped that the transitional period where both methods of avatar baking are active will only last for about two weeks.
Object Caching and Interest Lists
Commencing at 57:25 into the recording.
When you enter a region at the moment, your viewer receives a huge amount of information on what requires updating, much of it relating to things you can’t even see from your position in the region. The data is received in no particular order, with the familiar result that things appear to rez in your view in a totally random order – quite often with the thing you actually want to see being one of the last to rez due to the mechanics of Sod’s Law. What’s more, if you have previously visited the region, the chances are that much of the information being sent to your viewer is already cached.
The focus of this project is to optimise the data being sent to the viewer, information already cached on the viewer and the manner in which that data is used in order to ensure it is used more efficiently so that things rez both faster and in a more orderly manner than is currently the case.
At this point in time, this work is in a greater state of flux than the HTTP library and avatar bake projects. This is more a process of optimisation both on the server-side of things and within the viewer itself, rather than that of new functionality within the viewer per se. There are no general time frames for this work at present, but there will be updates once things become clearer as to how the optimisation is going to be addressed.
The precise timeframes for implementing these changes have yet to be properly defined. However, Oz Linden hopes that there will be at least a two month period between Linden Lab making the code for each of these project elements available for integration by TPV developers into their viewers and the point at which the Lab states the code must be in use.
At the moment it is likely that the HTTP library element of the project will but rolled-out first, although this is unlikely to be within the next two months, for the reason given above. Project Sunshine, dealing with avatar baking, will then follow after that – or although how soon after has yet to be determined; as described earlier in this article, this will be a very controlled roll-out. It is possible that the object caching / interest lists part of the project many not be rolled-out for another six months. However, timeframes are still in discussion within LL, so any of this may well change.
Expect updates on all three of these project elements as and when more information is supplied by Linden Lab.