Server-side Baking / Appearance
Yesterday, I reported on the SUN-74 issue (Apparent avatar skin and eye texture asset corruption with Server Side Appearance), which can impact users with avatars wearing modifiable skin and/or eyes and/or hairbase who enter (via teleport or crossing a region boundary) an SSB/A-enabled region while using a non-SSB/A enabled viewer (e.g. such as Phoenix or the v1.23.5 viewer) and leave them with a corrupted copy of the worn skin / hairbase or eyes. At the time I noted that the matter was under investigation by Linden Lab, and no decision had been made on how to handle it.
Speaking at the TPV Developer meeting on Friday May 31st, Oz Linden provided an update on the issue and spoke more generally on the issue of the use of olfder (non-SSB/A capable viewers) going forward:
We don’t actually know what’s ultimately going to be done about that; that’s a subject of vigorous discussion that’s going on even as we speak, so we’ll see how that plays out. I think it’s fair to say that regardless of what happens with that particular issue … I will just make the observation that there are still people really, really old viewers [and] there is no way, no way at all, that we could even begin to test for compatibility back with all of those viewers.
As it is, as recently as this last week there were 1,665 different viewer version strings reported as connecting to the main grid (these include 151 versions of Singularity, 50 versions of Phoenix, 262 labelled as Firestorm, and so on). Some of these may be “one offs” self-compiled builds (which may or may not have the most recent updates to support something like SSB/A), but even so, given the overall number of viewer strings, it is understandable why the Lab view attempt to ensure so many different viewer versions were fully compatible with anything on the grid is a next to impossible task.
This does not mean that the Lab is going to ignore SUN-74, right now they are still investigating the problem and trying to reproduce it in a consistent manner (which is apparently proving difficult for a number of reasons, not the least of which is that some older viewers simply crash when attempting to repro the corruption). However, what it does underline is the need for people to upgrade to an SSB/A-enabled version of their preferred viewer sooner rather than later.
The reason for this is that very soon the Lab will start undertaking more widespread testing of the new service by enabling it across a number of regions across the grid. These regions may not necessarily be constrained to any of the usual RC channels, but could well be a mix of regions from all of the various simulator channels, making them harder to identify and avoid. This testing will be to gain greater insight into how the service stands up under “real avatar loads” – something which is impossible to carry out to any great depth on Aditi, as there simply isn’t the volume of users active there.
Once this more widespread testing starts, then it is entirely possible that users who remain on non-SSB/A capable viewers are going to encounter issues and problems beyond seeing grey avatars which the Lab are not going to address, simply because the issues can be resolved by a viewer update.
So the word really is, update, update, update.
Materials Processing
The Materials Processing viewer is now at a beta release (3.6.0.276764). Please refer to the Lab’s official announcement on the release, and also my overview of the release, which includes a short summary of materials in Second Life.
Currently, TPVs are being encouraged to adopt the materials code as soon as they can. However, given the amount of work being focused on SBB/A at the moment, it could be a while before all TPVs manage to integrate the materials code into their viewers.
Viewer Release Process and Upcoming Releases
Referring to the new viewer release process at the TPV developer meeting, Oz reiterated recent comments on the status of the work, as reported in these pages, saying:
Hopefully, within a couple of weeks we’re going to be shifting to the new release process fully. Testing on that is going really, really well. Needless to say, since it touches viewer upgrades and log-in, we’re being extremely conservative about testing everything as thoroughly as we possibly figure out how to do before we try to touch any production systems. But so far the testing is going really well, and I think we’ll be able to start tweaking that pretty soon.
What this will mean is that as the new process coming into effect, possibly around or before the Materials Processing viewer goes to a release status, we’ll start to see multiple project and beta viewers start to appear as various viewer-related projects and activities within the Lab mature to a point where they are ready for release in some form. In fact there is already something of a pipeline of possible releases forming, which includes:
- A collection of open-source contributions to the viewer which is hoped will appear as a release candidate viewer pretty quickly
- A “pretty substantial batch” of maintenance fixes for the viewer
- Vivox updates, which Oz described as, “Finally getting attention again, and will probably be in a release candidate version ‘real soon’ now”
- An Experience Tools viewer which is also expected to appear “real soon”
- An interest list update viewer, which is believed to be getting closer to being stable
The experience tools viewer is expected to interact with the “experience keys” project code deployed grid-wide on the servers in week 20, and which are believed to be part of the experience tools project initially rolled-out in August 2012 after an initially rocky start earlier that year. The Lab is apparently developing documentation to accompany this work, but it is “not done enough yet” for general release.
Inara Pey: Living in a Modemworld 
There’s an unfortunate attitude on behalf of many users that causes the proliferation of seriously outdated viewers. Part of it can be attributed to an aversion to upgrading their hardware; another part of it can be attributed to sheer laziness; and, finally, part of it must (sadly) be attributed to the extremely popular “LL is the enemy” mentality.
LikeLike
I’m not sure just why the switch from v2 ro v3 happened, but I think the Lab shot themselves in the foot big-tim with v2. I know I struggled to use it because of the default colour scheme. OK, it was the beta I struggled with. v1 had alternative skins nuilt in. So I pointed out the problem but didn’t worry. Then the full release came, and the Lindens had done nothing.
Yes, there is a third-party add-on which gives us new skins, but we have to download it, and install it ourselves. And a mandatory update might very well break that, until an upgrade of the add-on.
That’s what provoked my distrust of the Lindens. They have never addressed a slew of visual problems with the UI, even throwing away solutions. They give us a lousy colour scheme as default. Text sizes are ridiculously small (that’s partly down to Windows not coping will with the change in monitor size and resolution of the last decade). It’s a persistent reinforcement of the idea that they don’t care.
And if anyone wishes to claim that a UI change isn’t a problem, I shall suspect they haven’t heard of Windows 8.
LikeLike
In my eyes, and with the benefit of 20/20 hindsight, V1 was primitive and nowadays I find it to be just plain ugly. I didn’t mind V2’s UI that much; in fact, the colour scheme reminded me a lot of applications that, at the time, had become fashionable among many people who were in my university’s photography team (Apple’s Aperture and Adobe’s Lightroom, more specifically).
Now I can only compare the V1 UI to “old school” UIs like GEM, TOS, Windows 3.1 and the really old versions of the X Window environment for UNIX systems. V2 was a transitional state towards what we now have, which, in the case of TPVs like Firestorm, I like to compare with Gnome 2.
And if you think Windows 8 is bad (well, OK, Windows 8 is utter crap), you haven’t seen Gnome 3 and Canonical’s Unity on Linux and UNIX-like OSes.
LikeLike
More than a few people have no idea why their Phoenix Viewer isn’t working right NOW. Maybe it’s time for mandatory updates.
LikeLike
They’ve been informed and notified numerous times in the past, even in the form of an MOTD as they logged in to SL. And yes, perhaps mandatory updates should be reinstated for a number of things…
LikeLike
The current figures are that around 45,000 people are still using Phoenix. I gather that there has been talk within the Firestorm team of blocking Phoenix from connecting to Second Life – and only SL: users would still be able to access OpenSim grids using it – but this brings with it a number of potential complications of its own.
At the moment, the optimal / preferred way to get people to swap / upgrade their viewer is through communication and education, rather than simply blocking viewers, even with a suitable message as to why the viewer has been blocked (which is something that again, the Firestorm team could do, as they have the capability).
Obviously, the problem with communication / education is that even with blog posts, in-world group notices, MOTD log-in messages, and Jessica, Ed and the rest of the team standing on their rooftops with megaphones and screaming about the need to update at the top of their lungs, people will still cling to Phoenix. Just as other users will continue to cling to v1.23.5 or older versions of other viewers.
So, however you look at it, weaning people away from the viewer they love isn’t going to be easy, whatever course of action is taken.
LikeLike
i don’t think mandatory updates would help with the new from LL equals evil attitude. in fact it might simply confirm their bias. as more things break, or as more early adopter type residents showcase and rave on about how great new features are, more change averse people will begin to wonder if they are missing something, & might even decide to see for themselves if they are missing anything. SSB will be a watershed moment for the grid in this respect. remember your seat cushion can also be used as a flotation device 🙂
LikeLike
We’re going to see a lot of butthurt from the bone-idle (you call them change-averse, but they’re really lazy) crowd that’s been dictating “no mesh” policies in various venues (a few friends of mine are dancers and some of the clubs have a strict “no mesh” policy for their staff, because “some of their patrons use viewers that can’t see mesh”).
LikeLike
i lawled, but really i think it’s fear more than laziness. what if they can’t find a button, what if something somewhere breaks and they don’t know how to fix it etc? what if they go back to feeling like a newb in a place where they normally feel in complete control of everything? anyway, it is time their whatevers stopped dictating and setting limits for everyone else.
BUT one advantage for those who are waiting until the last minute is that there should be that many more people able to help with the transition.
LikeLike
What’s missing: A mesh deformer viewer, which from all accounts has been ready for months.
LikeLike
Pardon me for bursting the bubble, but when the mesh deformer was suggested by Qarl Fizz (ex-Linden), the content creators went in and started demanding that all sorts of other functions be added to it. And there’s no consensus as to what the mesh deformer should entail; if you ask content creator X, their answer will be entirely different from content creator Y’s. So, the mesh deformer is not even half-finished, it’s in limbo and no one knows when it will be completed. Hopefully, LL will get in touch with (how about hiring?) someone who knows about mesh clothing in some other platform and who can say “it needs to do this and that, let’s go ahead and do it now.”
LikeLike
The mesh deformer did briefly catch-up with the current viewer code a while back, but is once again lagging (the code does not appear to have been updated with recent merges since the end of March 2013. There is also further interenal testing LL believe they need to do as a result of feedback on STORM-1716 and avatar weighting, and the resources currently aren’t there. They’ve also expressed a concern that there is no clear way for a designer and a user to be sure that they are using the same avatar base model – and if they are not, then the deformer will very likely make things worse. While there are some provisions within the current deformer for the base model to be taken into consideration, there is apparently concern that it may not be sufficient.
Ergo, I suspect that they are reluctant to make ant commitment on the further availability of the mesh deformer viewer until such time as the testing / concerns have been addressed, particularly – as Qarl himself stated a while back – the project has undergone a degree of scope creep, which potentially puts the Lab on a hiding to nothing, no matter what they do.
LikeLike
This means that, contrary to popular myth, LL are not idly sitting on their arses.
LikeLike
It’s great to see that progress is being made, is there any news on how LL plans to address the problem of Avatar Height Offsets? The current plan (making it part of shapes), just isn’t workable for anyone who…. wears more than one pair of shoes, or uses different poses, or… any number of things.
LikeLike
Hey, Lori 🙂
It’s not been recently discussed, and Nyx’s Monday Content Creation meeting is the place where questions like this are best asked. However, and assuming nothing has changed since the last time Nyx did update on the matter, it would appear to be the case that, from LL’s perspective:
We already know that there will be one viewer-side update rolling out after the server-side deployment has taken place (see the LL blog post announcing SSB/A) – but whether that might also include a further enhancement / update to the z-offset issue remains to be seen.
In the meantime, a possible TPV solution is being worked on, courtesy of Cinder Roxley, and I’ll endevaour to get an update on the status of that work as soon as I can.
LikeLike
actually i find it pretty easy to set it and it saves as part of an outfit just like every other element or tweaked shape i am wearing. so i can change from petite to biggie stuff with it for instance without issue and without needing to return to the shape settings.
the problem with it being a shape slider i think is that people wearing no mod shapes cannot access it. but then of the 2 parts that make up that problem, i would say that a no mod shape is the greater evil.
LikeLike
The no-mod shape aspect is an issue for the current solution, but the problem is also a little broader than that alone.
There are essentially two broad uses for adjusting the avatar’s z-offset. One is to adjust the avatar’s position when moving between shapes of different sizes (from “giant” to “petite”, for example). This was the issue originally put to LL as needing a solution – and the hover slider implementation does (with the exception of the aforementioned no-mod shapes) largely address that issue.
However, the z-offset is also used to make what amount to on-the-fly height adjustments to prevent such things as the avatar appearing to hover in mid-air when trying to ground sit, or of vanishing “inside” a non-scripted sofa, rather than sitting “on” the cushions – or even simply preventing the avatar’s feet sinking into the floor as a result of changing shoe bases. While a case for these uses was put forwar in the form of a JIRA (SUN-38), it wasn’t until LL had started working to address the original use case of avatar sizes which had been put to them.
As such, while the slider solution does (as stated) tend to work with the avatar size issue, it doesn’t work for the broad issue of on-the-fly adjustments (you can’t, for example, use the slider mechanism to adjust your sitting position when you fit yourself sitting “in” an unscripted chair rather than “on” the cushion of the chair, by virtue of the fact the avatar has to “stand” in the shape editing pose when the offset is being adjusted). As such, there is a feeling that more needs to be done to address the issue – and the matter is now being looked at by at least one TPV dev (Cinder).
It remains to be seen if the LAb offer-up a more comprehensive solution which meets the requirements of SUN-38, or whether something like Cinder’s solution works (and may in turn be adopted by LL as a code contribution as well as being taken-up by TPVs).
LikeLike
This is not correct. You can set the
AppearanceCameraMovementsetting to false to enable editing the shape without activating the animation/camera combo. Most viewers has a “shortcut” to this in the “Movement and View” settings, called “Automatic Position for Appearance”.Inconvenient, I agree, but for the sake of completeness, it’s possible. 🙂
LikeLike
My problem with this particular slider is that the adjustment is too coarse; it seems that each increment equals to 5 centimetres or so.
LikeLike
I would like to understand the way you see things.
I see the problem differently. Let me explain:
I rarely, if ever, needed the avatar offset.
– An avatar not wearing any footwear will be touching the land mesh with it’s foot, unless the land mesh is acting oddly (it happens).
– If the boots I am wearing comes with a shoes layer, I use it. If it doesn’t fit, I adjust it or make a new one that works (in case the creator is evil and made it no mod).
– If the boots does not come with one, but seems to need one, I try adjusting the shoes so that the “bottom” of the show is aligned with the shape’s foot and wear a foot mask alpha layer, eliminating the issue.
– If the boots does not come with one and adjusting it does not produce an acceptable result, it is most likely a product flaw made by the creator and not something Linden Lab needs to address.
If someone is using the Avatar Offset:
– to fix AO animations, they are doing it wrong, unless the creator has no clue how to make quality animations.
– because they are too lazy to mod/fix it the way it should be fixed, they can hire someone to do it for them.
– to “level” hug animations, you can refer them to https://en.wikipedia.org/wiki/Human_height#Average_height_around_the_world
If the problem comes from standing on a mesh construction, this is the wrong fix. furthermore, Z-offset appeared before mesh.
P.S.: This is in no way a personal offense. I just don’t get the point of the Offset.
LikeLike
All I know is that there are a number of circumstances where I find it helpful to be able to tweak my offset. Different ground sits for example, poses from my collar, poses from cuffs, furniture, different shoe bases from footwear, etc. etc.
It’s easy to say “well, those are broken”, or “the creator did it wrong”, that may be true, but as I’m not the creator, it doesn’t help me keep from hovering at knee level, or sinking into the ground…
LikeLike
Agree, but having the Lab to publish an official fix is acknowledging these broken products as “acceptable”. This is the point I’m trying to make. Creators should spend more time making quality products instead of getting others to “fix” what they did wrong. Anyway, ranting over before someone bans me from this blog 😛
LikeLike
There are also some things that the Lab never actually considered. For instance, shoes with extremely high platforms (like the ones that are fashionable now in RL and have been, for a good few years before, the “privilege” of exotic dancers); LL’s shoe base simply never had the range of adjustment for this. So, it’s not “broken products”, but simply the fact that LL’s designers never went out to see what exists in RL (let’s face it, most of the shoes in SL reflect existing RL designs) and accommodate its recreation in-world. And don’t even get me started on the human skeleton that LL has implemented; in many poses, it seems like the legs were torn off from the waist down, and this is not a problem of the poses themselves (they’re merely poses that we do in RL all the time – you know, yoga meditation and pilates poses, or sitting on the ground with our legs crossed…), but of the avatar’s articulation and weighting. In this case, if something is broken and borked, it’s what LL had designed.
LikeLike
Never ever even knew of the acatar offset as i adjust all to my shape!
Guess that shape shifters can think on moving out of SL!
LikeLike