We've all had reason to bitch at LL in the past for doing things that have, to be charitable, been less than successful in not royally screwing up the grid. To their credit, they've gotten things worked out and running well again, each time. Even so, the experience has been less than promising.
Eventually, you'd think they'd feel snakebit and shy away from big changes. Thankfully, they haven't. They took on one of the biggest problems in SL, bake fail, and seem to be well on the way to banishing it from the grid once and for all.
Oz Linden has said that SL is the only place where it's not unheard of for someone to go to a business meeting and ask, "Where did my pants go?". That's not a recommendation, folks. What it is is bake fail: your avatar's appearance doesn't turn out the way you'd intended it to from wearing clothing and such because some parts of it fail to be shown properly.
That's the whole idea behind server-side appearance. Its purpose is to fix bake fail once and for all.
The original way of doing avatar appearance, before multi-attach, was that your viewer would select the system clothing layers (shirt, underpants, skin, etcetera) to wear, either from your selection as you were putting things on or from a message from the server at login time. It would obtain the information from each piece and assemble them, then tell the server "all right, I'm wearing this list". Your viewer would then put them all together, make one texture for each major body section (head, upper torso/arms, and lower torso/legs), then upload that texture to the sim and let it pass that out to everyone to show on your avatar. That last process is called "baking".
The limitation is that the first way of doing it could only handle one attachment per attachment point. That was fine until you got to things like furry avatars who wanted to wear accessories and furry body parts on the same attachment point at the same time. The Emerald viewer came up with one way of addressing this problem, namely to define secondary attachment points at the same location as the primary; this worked, as long as the user looking at the avatar was running a compatible viewer. Needless to say, many weren't. Without server-side support, though, ti was the best that could be done.
LL added the server-side support to go along with an early release of Viewer 2. Part of that support was the Current Outfit folder (COF), which regularized and standardized handling outfits no matter how many things were attached on any given point or any clothing layer. Phoenix added proper multiattach support and dumped the old way quickly; everyone else added it as well except for the CoolVL Viewer, which did it its own, incompatible way. (But that's another flamewar we've already had.)
The Current Outfit folder and multiattach/multiwearables made life a lot simpler, but they didn't change how the avatar textures were baked. Things were still shipped back and forth between the SL servers and the viewer. Each time something was sent over the wire was an opportunity for things to screw up, and when they did, you saw the Ruth shape, or the infamous poo-colored cloud, or last week's outfit, or just plain gray. The same thing could happen for lots of different reasons on the user's computer, including things as prosaic as running the viewer on a secondary monitor. (The bake process actually used the normal viewer's avatar display routines to draw the various textures on the avatar, then read the texture back out of graphics memory. This didn't work on a secondary monitor.)
SSA (originally called server-side baking, and now you know why) is designed to eliminate that kind of error. The key is that, with the COF, everything needed to create the avatar's appearance is present at the SL servers. Since it's there, they can simply add another set of servers, called the "bake ovens", to bake the textures and ship them out. No need to traverse the Internet multiple times, each time risking the data getting lost by some $6 consumer-grade cable router that can't handle a real workload or having DNS croak in the middle of things or any of the myriad failure modes that make SL such joy to troubleshoot. Just look in the COF, tell the oven to bake the textures from this list of assets, get the baked texture back, boom, you're done.
Of course, it's not quite that simple in practice. Not only did the bake ovens have to be built from the ground up, but the viewer code had to be rewritten to deal with not having to do the pile of work needed to bake the texture and then upload it. There was a lot of code refactoring that went into the viewer side of SSA. You heard us talk about how it was a big change? This is why. This is also why we chose not to add it to Phoenix, because it would have been a lot of work we'd have had to largely pioneer.
LL did all this, and they did something unusual: they coordinated their SSA efforts closely, and carefully, with the TPV community. That's because this would not work unless the viewers were ready first, before the server components were turned on. Then they were careful to test thoroughly. And test. And test some more. Then they got the TPV community involved in testing. And we tested every way we could think of. Only then did they start rolling it out to the grid. Even that was done differently from normal. They rolled it out to one or two RC channels, from 5 to 15 percent of the grid, and left it that way for a few weeks, to get lots of experience with how it was working before they flipped the switch for everyone.
All that care paid off. Yes, there are a few problems, but those are of much lower magnitude and severity than those associated with other recent big server rollouts. There are some folks who are showing up as gray; those who are actually running SSA-capable viewers (yes, we do get complaints from folks who appear gray, only to be surprised when they get told that Firestorm 4.3 isn't going to work any more!) usually have other issues like inventory loading and such that aren't related to SSA.
Folks, LL got this one right. They took their time to test thoroughly, they coordinated with the TPV community before dropping it on the grid, they listened to feedback, and they introduced it slowly and carefully, measuring as they went.
Will this be the end of bake fail? There's still work left to do, but there's good reason to believe that yes, it really will be.
And people who complain about LL adding features before fixing basic problems: This is an example of fixing basic problems. Bake fail was the single biggest cause of support questions for the Firestorm support team. Nobody will be more happy than they are to see it go away.
We complain at LL when they screw up. Let's cheer them on when they get it right. This time, they got it right.
No comments:
Post a Comment