Lab formally announces Server-side baking / appearance

Regulars to this corner of the SL blogsphere know I’ve been covering Project Shining – the various projects the Lab is currently undertaking to improve Second Life on the technical front in order to give us all a (hopefully) better experience.

Part of this work includes Project Sunshine, which is more colloquially know as server-side baking (SSB) or server-side appearance (SSA) or server-side baking/appearance (SSB/A) – the choice is yours, depending on personal preference, and which I’ve covered throughout numerous reports in this blog. The primary aim of project Sunshine is to resolve the issue of avatar bake fail – those situation wherein your avatar (or other avatars) fail to render correctly to either yourself or to others around you.

Today, the Lab itself moved to formally announced the forthcoming arrival of SSB/A with a special blog post of their own on the matter, which includes a short video explaining matters:

As the post indicates, SSB/A is being deployed in three parts:

  • A viewer update  – which is available now for the majority of commonly used SL viewers
  • The deployment of server-side changes, which should be commencing shortly
  • A further viewer-side update once the server deployments are completed.

The server-side deployment will take a while to complete, as the new service will require a degree of testing. As such, it is expected that a number of regions on the main grid will be enabled for SSB/A (if they have not been already), and these will be used to measure performance over a period of time prior to a decision being made on “throwing the switch” to enable the entire grid is SSB/A enabled (the test regions may even be scaled-up over time, depending upon how the initial testing goes.

Server-side baking: find out what it is and why you'll need to update your viewer if
Server-side baking / appearance: must viewers should (or will shortly) support SSB/A – make sure you update to a current release of your preferred viewer to avoid seeing grey avatars as the server-side of the new capability is deployed in the coming weeks.

As you won’t be able to tell which regions are using the new SSB/A service and which are using the existing avatar baking service, it is important that you make sure you are using a viewer which supports both capabilities – otherwise you might find yourself encountering grey avatars in increasing numbers. This means updating to a viewer which has the SSB/A code; at the time of writing, these are:

Doubtless, Catznip (R8 with SSB/A has been in development for a while), Dolphin and Exodus will have SSB/A-capable viewers out shortly as well.

Those wishing to obtain a further overview on SSB/A and also on the most recent updates out of LL on the server-side deployment plans are welcome to refer to the following reports from this blog:

Advertisements

23 thoughts on “Lab formally announces Server-side baking / appearance

    1. 🙂

      I actually missed it the first time around – someone else pointed it out to me, so couldn’t resist the small update in the Related Links :).

      Like

  1. There’s a fine line to walk between encouraging adoption of the new Viewer generation and persistent vagueness on the issue, And the lab is still making vague “real soon now” announcements.

    Like

    1. I don’t blame them for this kind of announcement. They’re basically telling everyone “look, we’re going to do this, when we do this your old viewers will be useless, so update now and don’t say we haven’t told you beforehand.” In the meantime, they’re acting cautiously and testing things extensively to iron bugs out.

      Like

    2. “Real soon” can be annoyingly vague at times, I agree. However, In this case I can well understand the caution when it comes to announcing dates. This is a huge, fundamental and visible change to SL which needs to be eased-in if the Lab is to avoid the risk of generating more issues they they’re solving.

      While there was extensive testing on Aditi, such testing is still limited as the population on Aditi is nowhere near representative of that on Agni, so caution is required in order for the Lab to correctly test the ground and ensure sufficient hardware is stood-up to support the new composite service, the infrastructure is handling the growing load as anticipated, and so on.

      Aditi was also prone to problems of its own during testing, which the Agni servers don’t have. So again, there is a risk that for all of the testing carried out on Aditi, something might have slipped through in the mistaken belief it was an Aditi issue, rather than an SSB/A issue. This is why the Lab has / will open-up two special test regions accessible by TPVs only ahead of any deployment of SSB/A – so that they can carry out further testing of the code to make sure things are as robust server-side and viewer-side as planned ahead of deployment. This further gives rise to caution on the Lab’s part where dates are concerned.

      The level of stress / loading testing required is unclear; so the length of time required for testing is unclear and thus providing an accurate date for deployment is difficult. It might be that the Lab select a good handful of regions with high volumes of avatars and quickly find out the service is more than capable of handling the loads based on what they are seeing – giving them confidence enough to “flip the switch” configuration-wise on the servers sooner than expected. On the other hand, they may select a far broader cross-section of regions which takes longer for them to accurately judge whether the new service handles the load and whether there are still unforeseen issues to be addressed before flipping the switch. Right now, this is uncharted waters for the Lab.

      There’s an additional factors here as well; as soon as the SSB/A configuration change in made to the initial “test” regions, it means that anyone on an older viewer entering such regions will see grey avatars around them, and the incidence will increase over time. Similarly (and I believe I have this correct) anyone with an SSB/A-enabled viewer enters a region running SSB/A, they are switched to the “new” system, and remain on it until such time as they relog on a region running the current system. This means that while they and everyone else in their world view renders correctly, and anyone else running an SSB/A-enabled viewer see them render correctly, there is a risk someone running a “non-SSB/A” viewer will sem them as a grey avatar. Ergo, encouraging people to switch to an updated viewer now could help minimise confusion.

      Finally, there is the argument that were they to announce in advance, that’s their colours pinned to the wall as a nice, big target for pot-shots should anything “go wrong” and they are then forced to announce a delay in the deployment, regardless of any caveats they orginally gave when announcing the planned date and/or any jusitifable reasons for the delay.

      Like

  2. I must agree with Mona on this and even if i have already a few Ssb viewers instaled and working, i’ll use a non ssb version till when i will have the need to change, as ssb viewers will still have to be updated at least once!

    Like

    1. You should be better-off using an SSB/A-enabled viewer. If you wait for the post-deployment viewer update, you’re going to be seeing a lot of grey avatars around you in the interim. The updates planned for the viewer shouldn’t substantially change the user experience compared to the code already in SSB/A viewers right now.

      Like

    2. I was using Firestorm 4.2.2.29837 (non-SSB/A), then 4.3.1 and now 4.4.0.33720, which supports SSB/A (and has LL’s tiling bug fix – which itself still isn’t entirely perfect if you want your snapshots to be of higher resolution than those generated by high-end full-frame professional DSLR cameras). According to Firestorm’s team, the latest release has issues of its own, but if I’m honest, I’ve yet to encounter them (although I did enable the suggestes workarounds and solutions even before encountering them, just to stay on the safe side). Also, with 4.4.0 my SL experience is much faster and smoother than with 4.2.2.29837 – it actually feels like I’ve got a faster machine than I used to, and the reason is that it incorporates the improvements in the rendering pipeline that previous releases did not get to take advantage of.

      Like

  3. I can switch in a second, has i have at least 4 already enabled ssb viewers installed!
    Singularity, Firestorm and Niran’s wich i’ll use mainly!
    The reason for not doing so, is that it takes a lot more time now, to see the clothing lawers rezzing and to see other avatars that are using ssb viewers.
    So when i will start to see the grey avatars i can change at once!
    Still for now using Niran pre ssb last version is still the fast way to see waht surronds me and as well to see my changes in outifts!

    Like

  4. Mona, Niran and not only, already had those improvements long ago, gues the reason why its already climbing up on the official Tpv list as the most stable TPv behind ragedast (hard to beat that, lol) and Firestorm!
    Also the reason that made such a fuzz, ehen Niran posted saying that firestorm was delaying progress, before this last release! as they didnt made any new version with all the sinnhy stuff that really makes Sl much better now!
    And just to state how good Niran is, a newbie that was using latest LL viewer, made the change to niran’s yesterday as per my advise and was amazed by the results!
    But Niran has a cost, no mac support, and for windows a good hardware needed, still the same that any will need to run firestorm or any other viewer using deferred rendering and ambient occlusion + shadows (yes i k now ll renamed that i cant remember for what, lol).
    Personnaly i wish that all could be in world using all the graphics settings at max, even if without shadows enabled, cause all would see how some builds make so many things to bright when using advanced ambient graphics (is that how LL refers about dr and ao +shadows?), besides the non rendering of the infamous inv prims that so many keep using1

    Like

    1. Let’s not get into “viewer wars” here. The simple fact is that all viewers have their own areas of appeal, and all have their own peculiarities. Some run well on given hardware, where others may not. That’s why having choice is important: so people can find the best blend of hardware + viewer to suit their enperience.

      As to who said what about any viewer other than their own – those are subjective and personal opinions, often coloured by personal bias. I’ve certainly no idea where the idea that any TPV has “delayed” anything (outside of their own development cycle – which they are obviously entitled to do). This certainly isn’t the case with SSB/A, which has slipped against the (very broad) schedule first put out by the Lab purely as a result of extra work being required within the system as a whole, rather than as a result of any particular TPV attempting the “delay” things.

      Like

  5. The reality is that We all hope that finally, cause the promise of ending the lag is as old as Second Life itself, this way will be really the one that will make SL as good as it deserves for its users!

    Like

  6. Well used the latest Niran alpha ssb version and i can notice 2 things since yesterday and last time i used a ssb viewer!
    Crossing sims at Sansara are behaving pretty well with a bike, as i did cross more then 200 sims with no crashes and only a few sec of delay in a few, and no camera problems at all!
    Rezzing is much faster now, at least on the places i went, using http textures checked!
    So guess that ill be using a Ssb viewer!

    Like

    1. Any difference noted is unlikely to be the result of SSB/A code changes, as this has zero bearing on region crossings.

      SSB/A only affects avatar rendering skin and clothing layers). Nothing else – not even avatar attachments.

      However, new interest list code changes on the RC channels may well be helping when crossing into reagions running the newer code.

      Like

  7. Inara, I’ve thanked you a thousand times in my head for your blog and posts such as this one, but I decided to record it this time. I’m very grateful to you for laying out this information in terms the average (and even not-so-average) user can understand more easily, and always so promptly. Each year brings a lot of changes to SL, and this year seems like even more, and even more complicated. Or perhaps I’m just more aware of the changes. Whatever the case, thank you very much for taking the time to share! 🙂

    Like

    1. Wllow,

      Thank you :). Glad that the blog helps, and hope it continues to help. There has been a lot going on with SL for the last year or so, with LL quietly tinkering away, and it’s all starting to show signs of coming together :).

      Like

Have any thoughts?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s