We now have SSA enabled on the Le Tigre Release Candidate channels. For a list of regions running SSA see my article: Le Tigre Regions List. So, what is it like? Well, my opinion is it really depends somewhat on the viewer you are using, but generally better.
Non-SSA Region
So, far my best experience has been with the Production release of the SL Viewer version 3.6.1-278007. I’ve had some crashing as I tp from SSA to non-SSA regions. But, otherwise, it is the best I’ve seen.
The Beta version of the SL viewer is another story. It is the worst of those I tried. I expect that to change. It is called beta for a reason.
I’ve been switching between viewers and visiting the same places. Since I have separate caches for each brand of viewer, I should get very similar results for first visits to a region with each viewer.
My Firestorm 4.4.2 (34167) does pretty well. It is a bit slower rendering things in a region. But, that is perceptual thing on my part. I found some textures just never render.
I did run into the problem that some hair just would not render. The shape would rez. But the textures would never render. It just stayed gray.
Exodus is about the same. I did find some textures that just never rendered.
Cool VL Viewer was also pretty good but it gets confused about what my last outfit was. It decides to restore my outfit to something I wore when using Cool ages ago. I think you have to change outfits in Cool. Otherwise it doesn’t acknowledge outfit changes in other viewers. Plus when you go back to another viewer your outfit is mostly the Cool outfit, but it’s not quite right. Annoying.
Please see Henri’s comment below. The outfit problem has been handled. (7/12)
People that came in behind me always seemed slower rendering than those that rezzed in front of me. Even after I turned to look at them.
I got an nVidia timeout while using Cool. I’ve heard that is an nVidia driver problem and that the current Beta version of the SL Viewer has this problem too. I haven’t hit it. There is a work-around fix from Microsoft that nVidia mentions.
SSA
Avatar rez and render speed is very different depending on whether one is in a SSA enabled region or not.
In SSA regions avatars rezzed (meaning I can see their shape) in just a couple of seconds and rendered (meaning I can see color) completely in another 5 to 15 seconds. Most of the avatars behind me also rendered.
In non-SSA regions the avatars were taking 15 to 60 seconds to render. Also, some were rather slow rezzing. Plus those behind me did not render until I turned around and looked at them. They did rez. So, they were gray people shapes. In Exodus they remained a green blob longer than in SL Viewer. In Firestorm some remained orange particle dots longer.
I did see a few avatars with each viewer that refused to rez and/or render. Checking profiles I found them to be long time players, 2 or more years old. I am assuming they are using non-SSA capable viewers.
I did find some textures just won’t render. It did not seem to matter which viewer I was in. Since I was changing viewers I was changing cache too. So, I don’t really know what the problem is.
I think things are better with SSA. A time change from 15-60 seconds down to 5-15 is not earth shaking. But, never having bake fail will be wonderful. I can’t even guess at the number of times I’ve been changing clothes and could not get my avatar to fully render. My Ctrl-Alt-R keys were wearing out.
Re-Baking
With SSA rebaking is going to be different. Since all the baking happens within the SL SSA system there is little if any chance of image corruption. Pressing the rebake keys is not going to force the system to rebake your image. It will force your viewer to download a new copy of the baked texture cached in the SSA system.
Your cached image will be saved for an undetermined about of time. Outfits like the library avatars that are worn often will be essentially permanently cached. Depending how frequently and outfit is worn, it will cache for a longer period.
There is something like a UUID for each combination of things the avatar can wear. The items make a value unique to the entire outfit, well the parts of that have to bake. If someone else manages to wear the exact same combination, they will get the pre-baked texture. The Lindens only expect that happen very rarely, except with Library avatars.
If you change outfits every day and say a week later put on a previously worn and baked outfit, you might get your previously baked texture. But, Log says while possible it is unlikely. But, if you wear yesterday’s outfit after a change to another outfit, you will probably get the previously baked texture.
As fast as the system seems I am not sure you will be able to notice when you get a newly baked texture and when you reuse one. So, which texture you actually get is probably irrelevant.
So, if you can manage to get a corrupt cached image, pressing rebake is not going to fix it. You will need to add something to change the content of the COF (Current Outfit Folder). I understand some third party viewers may add a feature to force the SSA system to rebake a texture and send you a new one. We’ll see if that becomes a problem or not having such a feature is the problem.
Testing
If you are interested in testing SSA you need some places in Le Tigre and outside the channel that has lots of people. You can try these places:
- Arapaima – Blue Steel –30± people
- Orburs – Magnum –25±
- Myanimo – Le Tigre – 30±
- Vilania – Le Tigre – 25±
- Ungren – Main channel Second Life Server 13.06.21.277682
KarenMichelle reported her testing in a post in the SL Forum: Deploys for the week of 2013-07-08.
There is a rumor that using a skin that is 50% gray will make your avatar invisible on SSA enabled regions.
Plus a non-SSA viewer user can change appearance in a non-SSA region and then go to a SSA enabled region and render. That didn’t used to work. But, if they change in an SSA enabled region they go gray.
ETA
Log Linden talking at the Server Beta User Group meeting thinks the SSA system will probably spend another week in an RC channel. It may move from the Le Tigre channel to the larger Magnum channel. That means it will take longer to roll grid wide than I anticipated.
Congrats to the team who worked long and hard on this – we started well over a year and a half ago and I can’t speak to what they encountered along the way, but I know they were trying the whole time.
Also, I do think it’s pretty amazing that your longest render time now is the same as the your shortest render time before. I’d wish for 1-2 seconds, but if they can average under 10 seconds they’ll have succeeded.
In sparsely populated areas, avatars do render faster. Also, some of the delay may be the viewer. My range was based on what I saw in the Welcome areas where a new AV was popping in pretty often. Some times with 2 or 3 piling up on the rez-point.
I think it is pretty awesome.
Good to hear from you.
There is a compatibility setting in the Cool VL Viewer, to allow switching to another viewer after a Cool VL Viewer session and seeing your outfit properly restored into that other viewer (the setting is in the Preferences floater -> “Cool features” tab, “Inventory” sub-tab), by creating inventory links for attachments in the COF (something the Cool VL Viewer doesn’t bother doing by default, because it doesn’t use the COF for restoring outfits on login and SSB only cares about COF links for body parts and clothing items).
Also, all modern Cool VL Viewer versions now restore fully your outfit from the saved outfit.xml file without letting stuff getting mixed between what you wore in an other viewer and what you last wore during the last Cool VL Viewer session: while you will find your avatar wearing what it last wore when using the Cool VL Viewer, there is no mix-up issue any more.
The COF is a flawed concept (implemented in a comically (and dangerously) complicated and convoluted way that no serious QA would allow to pass through anywhere else than at LL) that leads to many race conditions and (sometimes inextricable) issues when the asset servers is glitchy, and that’s the reason why I don’t use it in the Cool VL Viewer (but for SSB compatibility).
Thanks for the information. I’ll add a note in the article to see this comment.
I do disagree with your last paragraph. They are dealing with a legacy system you know little about. Nor do you know where they are going. From your viewpoint COF may be flawed. But, from within the Lab it may be the only reasonable economic solution that fits for past, present, and future. Until you can show you know the proprietary server code and SL system, we will disagree. I’ll give you there may be better ways, but probably not within the set of constraints the Lab has to deal with.
Nalates, I know pretty well what I am speaking about… I have got an intimate knowledge with this part of the viewer code and even proposed to LL a protocol that would have prevented entirely the need for COF support with SSB. The COF was invented back in the days of Snowglobe v2, when LL implemented multiple wearable layers and attachments, and this just because they didn’t want to expand the existing protocol (there is an UDP message that is sent by the server on login and tells the viewer what the avatar was wearing last time you logged off: LL simply didn’t expand this message to take into account multiple layers and multiple attachments per joint).
Please, don’t take me for a script kiddie… I’ve got over 35 years of experience in programming and if I tell you a piece of code is flawed (which the COF viewer code actually is), then you can bet your money that it is indeed flawed.
I haven’t taken you for a script kiddie. You have proven multiple times that you know, understand, and can improve on the SL Viewer. I just do not believe you have the same level of knowledge and wisdom about the server code.
The server side code is not the issue, here… Before SSB came out, COF was dealt with entirely viewer side (and only used for the initial outfit restoration on login) since for the server(s), the COF had no function whatsoever; now, with SSB, the COF is also used as a communication channel between the viewer and the baking server so that the latter can retrieve the UUIDs of the textures to bake from, which are themselves stored in the parameters stored in each wearable item pointed to by the inventory links stored in the COF… yes, that’s three levels of indirections… how reliable is that ?… Well, just as reliable as the asset server can be and as reliable as the request to create (and destroy) inventory links in the COF can be (that request being generated by the viewer)…
In any case, even without considering SSB, the initial outfit restoration out of the COF is subject to many race conditions: for example, it depends on how soon the links appear in the COF when the inventory is loaded on login by the viewer, how fast the linked items also appear (remember that they can “live” in different inventory folder which will load at different time as well depending on their depth in the inventory tree), and the respective order of such events (not even mentioning networking issues that can worsen the randomness level of the occurrences of all such events), leading to a ridiculously intricate multiple callbacks logic in the viewer code, which is intrinsically unreliable.
The old protocol (the initial outfit message sent on login by the sim server to the viewer) was infinitely more reliable, as is my work-around for the lack of such an (updated with multiple layers/attachments) message, namely the outfit.xml file that is stored on your hard disk and can’t be subject to race conditions.
I still see the server as half the equation. You may well be right about every point you have made in regard to the viewer. But, that is only the client half of the system.
Oh, also, the Cool VL Viewer allows you to rebake in SSB sims (by requesting a COF version increment to the server) and, if this is not enough, you may even switch on the “Advanced” -> “Character” -> “Aggressive rebakes” so that it forces a COF link refresh on rebakes, that in turn forces the server to rebake your avatar from scratch (it’s like if you changed your outfit).
That is awesome. Thanks for saying.
I am assuming that when you say:
“There is a rumor that using a skin that is 50% gray will make your avatar invisible on SSA enabled regions.”
You mean the texture of the avatar’s skin contains 50% gray color?? Sorry, I’m confused. Well, mostly confused about all of SSA but trying to keep up with the blogs for explanations, your’s especially.
I find that SSA on the whole seems to have worked well for me.
Yeah, for those using Photoshop, GIMP, etc. it is common to use a 50% gray color for a number of tasks. RGB = 128,128,128. This is common enough I forget some people are not familiar with the idea.
I expect that this is a bug and will get fixed. Some would like to see it stay. It has the possibility to allow us to reduce textures on the system avatar. We could use 3 – 64×64 50% gray textures for skin and skip using an alpha layer, thus reducing texture use. I just doubt the Lab will go for that.
And SSA does seem to be working well.