The Server-side Baking / Appearance (SSB) project took a significant step forward when, as reported in my week 14 projects update, the viewer-side code reached the SL development viewer. Barring any significant issues, it should also be appearing in the SL beta viewer very shortly.
While it will still be a while before the new service makes its debut on the main grid, viewers supporting the new service are liable to start appearing over the coming weeks and communications from the Lab and TPVs on the subject are liable to increase. As such, it seemed appropriate to blog on the most recent discussions on viewer updates in general (LL and TPV) and on the upcoming server-side code deployment, using the TPV Developer meeting on Friday April 5th as a reference.
A Quick Recap
For those who are still perhaps unaware of what Server-side Baking / Appearance is, I have an overview of the project, with detailed information on what it is, how it will work and what will change. However in short.
- What is it all about? Primarily solving the issue of “avatar bake fail” (when your skin or clothing layers appear blurry to you or those around you, or when you change outfits and you see yourself wearing the “new” outfit and those around you still see you in the “previous” outfit). This happens because the current process of “baking” your avatar’s appearance (the skin and clothes it is wearing) is driven by the viewer, and hiccups c in the viewer / server communications can result in the server failing to receive all the necessary information following a change of outfit & is unable to process it, leading to the problems mentioned above.
- What does it do?
- The new service moves much of the emphasis for the baking process from the viewer to a series of dedicated servers (sometimes referred to as the “ovens” required to do the baking), which should reduce the amount of viewer / server communication and ensure the “bake” process is more robust.
- As some of the work is still carried out by the viewer, it also is being updated with new code
- Why Should I Care? The new service is incompatible with the avatar baking mechanism currently in use. This means that once the server-side of the new baking service starts to be deployed on the main grid, viewers which have not been updated to use the new service will no longer function correctly; people using them will see those who are using updated viewers as permanently grey figures (other than attachments).
Where Things stand and the Road Ahead
In order to try to make the switch-over between the “old” and “new” baking services as smooth as possible, and minimise the issue of “grey” avatars, the actual deployment of the new service will effectively be in two parts:
- Because the viewer side of the SSB code will work with the existing baking service, this will be deployed first, in the hope that people will upgrade their viewers as new versions (both the official viewer and TPVs) become available
- The server-side code will start to be deployed on the grid as the viewer code reaches the SL release viewer; however, this will be a gradual process, driven in part by the number of people either updating to or transitioning to SSB-capable viewers.
The Viewer – LL and TPVs
As noted above, the viewer code for SSB is now available in LL’s development viewer (as of release 3.5.0.273529), and will shortly be arriving in the SL beta viewer before moving to the release viewer (possibly in around two weeks, although this does depend on whether or not unforeseen issues arise when the code is in either the development or beta viewer).
Third-party viewer developers have also been working on integrating the SSB code into their viewers (and several already have pre-release / alpha / experimental versions of their viewers with the code already implemented, which they have been making available to their users for testing purposes). As such, TPVs are liable to be releasing updates to their viewers in the next few weeks which users will be strongly advised to take for the reasons noted above.
Quite when TPVs will start releasing SSB-capable versions of their viewers is going to be something of a balancing act. Given that there is a chance that unforeseen bugs / issues are found within the viewer code while it is in the SL beta viewer channel, some may opt to not make any release until after the code reaches the SL release viewer channel in order to avoid the risk have having to make two (or more) updates in quick succession as a result of bugs being found. Others may opt to make a release alongside the upcoming SL beta viewer release, and track how things progress, updating their viewer as required.
Communications
A vital part of the deployment process is that of communications. Therefore, in the coming weeks users can expect to see both LL and their preferred TPV developers communicating directly on SSB as viewers become available / server-side deployment commences in order to encourage as many as possible to update to a viewer supporting SSB ahead of the the server-side deployment.
Another reason for a communications push from LL and TPVs is that many users are either using viewers which will not be updated with the necessary SSB code (such as the SL 1.23.x viewer or Phoenix, for example), or are using self-compiled versions of a viewer and may not have incorporated the SSB code (there is an estimated 370+ self-compiled versions of Firestorm connecting to the grid for example). LL therefore want to ensure that as many people as possible using such viewers are aware of the changes and thus decide what they are going to do in terms of upgrading / transitioning.
The Server-side of the Equation
While there have been extensive internal tests at LL for the new service as well as more open testing on Aditi, which has included a number of pile-on / load tests, LL are still very sensitive to the fact that the success of the new service hinges upon it being able to handle the load placed on it when it is deployed to the main grid.
So how are things likely to progress? Well, in Nyx Linden’s words, when speaking at the TPV Developer meeting on Friday April 5th, “Veeeerrry carefully…”
Essentially, what is likely to happen is:
- The viewer code will move to the SL release viewer, and a period of time will be allowed to elapse as people start using the new viewer. During this period:
- Those TPVs which haven’t release SSB-capable versions of their viewers will do so
- The communications campaign will start (if it hasn’t already) to encourage users to update to an SSB-enabled viewer (LL or TPV)
- Around the same time (if not when the viewer code is in the beta viewer), the server-side code will be released to a small number of main grid regions (possibly the Snack RC channel), where LL will monitor the load numbers carefully to ensure there is enough hardware on the back-end so that it will actually scale as deployment progresses
- The code will then be deployed to at least one Release Candidate (RC) channel, where further load monitoring will most likely take place, prior to the code being deployed to the grid as a whole.
How long the code will initially remain on a small number of regions prior to being deployed onto one (or more) RC channel(s) is subject to both the load monitoring LL will be performing and (to a slightly lesser extent), the number of people seen to be upgrading / transitioning to SSD-enabled viewers (which will be monitored by both LL and TPVs).
Both the Old and the New
Given this approach, it will mean that there will be a period of time when both the “old” and the “new” baking services will be running side-by-side on the grid. As already explained in this article:
- This is unlikely to affect those who have updated to an SSB-enabled viewer, as the “new” viewer code works with both systems. The only thing they might notice when moving from a region using the “old” baking service to one using the “new” baking service is that their avatar may briefly “flash” to grey and back, as the viewer switches to the “new” service for the first time
- Those running on a viewer which is not compatible with the “new” baking service are going to see an increasing number of grey avatars around them, as the server-side code deployment progresses.
Avatar Height Offset
Many TPVs have a “z-offset” capability which allows for rapid-fire adjust of an avatar’s centre relative to the ground. This is useful when changes of avatar shape or shoes, etc., leave your avatar apparently standing “in” the ground or hovering over it, or when an animation / pose leaves your avatar floating serenely in the air (such as a kneeling pose). The new server-side baking code effectively “breaks” this capability (see SUN-38).
In response to concerns on this breakage, LL implemented a fix which utilises the Edit Shape option within the viewer. While this did address the concerns of the breakage as they were original put to LL, the fix failed to address wider issues of adjusting an avatar’s height in relation to animations / poses (e.g. “raising” your avatar’s height when you find yourself sitting “in” and armchair rather than “on” it).
While there have been various updates and fixes to this approach (including one recent update to fix a problem whereby very small avatars could end up with a “negative” height which, in Nyx’s words, “Did some very interesting things with the camera and a few other things”), the approach taken by LL remains unchanged, and the issue of making accurate pose height adjustment remains.
“The system is based on values based on wearables, which is how our back-end is able to generate it, so the in-viewer interface doesn’t work quite as well if you’re trying to modify wearable values on-the-fly,” Nyx Acknowledged, before going on to state that while he’s working on making a couple of further tweaks “just to get behaviour correct”, but which are “not necessarily requirements” which TPVs need to pick up – which can probably be taken to mean the approach to adjusting height is unlikely to dramatically change prior to SSB being deployed.
Summary
- The Server-side Baking project is making progress, and will soon be making its presence felt on the main grid
- The viewer-side code is now in the SL development viewer and will be progressing into the SL beta viewer shortly, where it is likely to remain for around a couple of weeks (depending on any issues arising), before it arrives in the SL release viewer
- TPVs will start releasing SSB-enabled viewers either while the code is in the SL beta viewer or shortly after it arrives in the SL release viewer
- There will be an unspecified period following the SSB code arriving in the SL release viewer and before the server-side deployment commences, to allow people to cut-over to an updated version of their preferred viewer
- The server-side deployment will be somewhat gradual as LL monitor loads, etc., and ensure sufficient back-end hardware is available. However, while gradual, it is unlikely to be unduly protracted.
Inara Pey: Living in a Modemworld 
So they want deformable mesh to do every possible use case before they will make any movement on it but are willing to release SSB without fixing known z-offset issues? Priorities. The lab does not have them.
LikeLike
I wouldn’t say that is entirely the case.
While there have been delays on LL’s side of the fence, the deformer project has also had additional requirement placed on it by the community. There have been expectations that it will do more than the original specification / than was coded by Qarl; there’s been the whole issue around shapes; questions whether the original code can handle various weighting requirements, etc.
As such, and while it is easy to place the blame entirely on the Lab’s shoulders, the history of the project doesn’t really reflect that.
LikeLike
Is there any information on whether the human skeleton used by SL affects the mesh deformer’s function?
LikeLike
Great overview thanks for the update!
LikeLike
You’re welcome!
LikeLike