Forwards and Backwards Compatibility
A key concern raised – and also addressed in the wiki page – was that of forwards / backwards compatibility between the new system and the old system.
Project Sunshine has been designed with the assumption that all viewers will be updated with the new viewer-side code before the server code gains widespread adoption across the grid as it will take time to test and scale-up the server code and deploy it across all the release channels (including Release and Main Candidates).
As such, the viewer code developed by Linden Lab is designed to work whether or not the server-side code has been implemented. Essentially, the viewer will continue to use the old-style avatar baking protocols until such time as it connects with a region which has the new protocols enabled. At that point, the user’s appearance message will be converted to a server-generated message that will persist even if the viewer subsequently connects to a region which is not running the new code, and new-style appearance messages will remain flagged as such. Since textures are fetched from a central service, updated viewers will be able to fetch an avatar’s textures even if the server does not support it.
The only exception to this is when forcing a rebake (CTRL-ALT-R) or changing outfit when in a region which is not running the new baking protocols. When this happens, the viewer will revert to uploading local bakes for distribution by the server (as is the process now). These will be automatically overwritten on connecting to a region supporting the new protocols.
However, the server-side of things will not support any form of “backwards compatibility” – it will only work with updated viewers. This means that once the new service has been fully deployed:
- The viewer will no longer be able to upload avatars textures to the simulator as it currently does; that part of the pipeline is being removed from the simulator code
- Anyone logging-in to Second Life using viewer which does not support the Current Outfit folder and/or which does not have the viewer-side code implemented will be unable to see fully textured avatars around them. Other avatars will either fail to render and remain as clouds, or will render as “grey ghosts” which never texture
- In addition, while someone logging-in to Second Life using a viewer without the new code may look perfectly OK in their own world view (because their appearance has been generated by their viewer), they will be ghosted or greyed out to those around them using the new service.
In terms of viewers, the majority in use with Second Life already support the Current Outfits folder, which means the emphasis for most TPVs will be in the implementation of the the viewer-side baking code. As such, and as both LL and TPVs reach a point where they can start releasing viewers for general day-to-day use and the server-side code starts being deployed, the majority of users shouldn’t notice any change whatsoever, as the new code does not require any changes to the viewer UI or anything (although there will be a knock-on effect with temporary texture uploads – see below). Nor should the differences between how the two baking services work be in any way visible – other than bake fail issues (hopefully) going away, or at least seeing a dramatic reduction in their occurrence.
However, for those using viewers which do not support the Current Outfits folder (such as the official 1.23.5 viewer, which is still used by some) Second Life will become increasingly grey / cloudy where other avatars are concerned as the server-side deployment of the new service progresses. Even so, LL have no plans at present to physically block any viewer which does not support either the Current Outfits folder or the new baking code from accessing the grid once the new service is deployed.
Approximate Time Frames
There are still no definitive time frames for the deployment of the new baking service. However:
- TPVs have been given the go-ahead to start merging the viewer-side code with experimental branches of their own viewers and running it on an initial test region created on the beta (Aditi) grid for precisely this purpose, with the aim of having all major testing completed by around mid-February
- LL will continue to work on their viewer code in the interim to deal with a number of known issues and bug, and expect to update the code with a few patches – which will also be made immediately available to TPVs
- It is hoped that by around mid-February, the viewer code will be sufficiently well advanced to be merged into the viewer development code branch and from there into the beta code branch, which could trigger the start of server-side code deployments. However, this is dependent upon the issues / bugs / problems TPVs may encounter with the code as well as issues uncovered in more general testing and reported through the project JIRA.
- Any deployment of the server code will be dependent upon further and significant load tests. These are viewed as essential in ensuring the new compositing service has sufficient hardware for it to support avatar baking across the entire grid. Plans for this testing have yet to be finalised, but may include deploying the service to small sections of the main grid ahead of any “official” RC channel deployments, as well as the potential for LL to request assistance in carrying out “pile-on” tests with the service in the New Year
- A further issue which may impact deployment plans is in ensuing the new service to provides “pixel perfect” baking which does not have unintended consequences in terms of texture appearance and alignment, etc. This work is still ongoing, although Nyx commented the Lab was getting “pretty darned close” to matching the current baking service, the aim again being that when the service is deployed, users will be unable to see any visible difference between the old and the new service – other than no longer experiencing the headache of bake fail.
Taking all of the above into account, it would seem reasonable – but not certain – that the service could see deployment underway by mid-March.
Points of Note
The new avatar baking service is HTTP based for texture fetching. This is not the same code / pipeline as Monty Linden has been working on to improve in-world texture fetching and rendering, but it does use the same framework. This means that users will need to ensure they keep the HTTP option in their graphics preferences checked at all times (viewers tend to have this option enabled by default).
Alpha Mask Creation
Linden Lab recommend that when creating an Alpha mask for all / part of the avatar body via the Edit Outfit floater, the alpha transparency check boxes should be ticked where appropriate, rather than a transparent texture being applied. This will assist the avatar rendering process by simply rendering the required part of the body transparent, rather than fetching / applying the transparent texture.
Temporary Texture Uploads
One side issue of the new service (and the one likely to cause controversy) is that once it will disable the “temporary textures” upload capability common to most TPVs. This does not mean that it will no longer be possible to preview textures without payment to the main grid for testing purposes – the new baking service will not impact the Local Textures capability found in the official viewer and most TPVs. However, what it does mean is that textures uploaded using the “temporary textures” facility will not be viewable by others (as they can be at the moment) in the same way that textures uploaded using the Local Textures option cannot be seen by others. It also means that temporary uploads using scripted agents (for demonstrating clothing designs, etc.), also will not longer work.
- Project Shining blog official post
- Project Shining: what it means for the viewer
- Project Sunshine wiki page
- Sunshine project viewer (not recommended for daily use): Windows, Macintosh, Linux
With thanks to Tara Lynn for pointing out the keystroke error :).