Update February 24th: Henri Beauchamp has filed a SUN JIRA on the Z-offset issue mentioned in comments following this article. Z-offset is an opton found in many TPVs which allows the vertical height at which an avatar stands / kneels / sits / lays to be adjusted through the viewer, allowing users to compensate for their avatars appearing to float in mid-air. The SSB code effectively “breaks” this capability. The JIRA description carries a comprehensive description of the issue for those unfamiliar with the problem.
Update, February 23rd: The Catznip team (which includes Kitty Barnett, have added a post to their blog on the subject of RLVa and SSB. Be sure to read it!
Following the recent Server-side Baking (SSB) pile-on / load test, I took a little time out to try-out the various viewer versions which are starting to appear which provide SSB support. This was not intended to be an extensive break test or anything – just something to sate my own curiosity on a number of points.
As such, the tests I conducted were simple, and as they were performed on Aditi, they may have been influenced by some of the inventory issues being experienced there. For the tests, I used my main account, and my CTA – Crash Test Alt, which routinely gets used when testing experimental viewers, etc.
Testing covered the Cool VL experimental branch, Singularity Alpha release with SSB support and Radegast 2.8. Throughout the tests, my CTA was running the official Sunshine (SSB) project viewer 3.4.5.270409. Testing did not include Lumiya, which has SSB support implemented. The reason for this is that I remain unable to log-in to Aditi with Lumiya.
I started with a couple of baseline tests to remind people of what is going to happen once SSB is deployed to the main grid.
Following this, I switched to using Singularity first and then Cool VL.Results wer as expected – both accurately rendered outfits and outfit updates without any significant issues.
Testing Radegast 2.8 also generated the expected results: outfits rendered correctly in both the Radegast 3D viewer, and in the SSB viewer, as did any outfit changes made via Radegast. Furthermore, and as expected, outfit changes made using one viewer were accurately reflected when logging into another viewer (so outfit changes made in Singularity were accurately rendered by Radegast, for example).The only issue I actually encountered was that footwear would not render correctly – which is not an SSB issue.
SSB and RLVa
While carrying out these tests, I also took a look at RLVa on SSB, and confess to not finding any obvious issues when using Singularity or Cool VL (which uses RLV). All RLV/RLVa options functioned as expected:
- Items “locked” as non-detachable remained undetachable until “unlocked”
- Restrictions applied through RLV/a all functioned as expected (e.g. map restrictions prevented access to the World or Mini-Map; inventory denial prevented inventory access, etc.)
- Remote access to #RLV Shared Folders worked as expected (i.e. remote changes of outfit worked and were accurately rendered)
- Remote (HUD-based) access between avatars worked as expected
- Control zone restrictions applied / released as anticipated.
This does not necessarily mean that RLVa is not “broken”. I actually have no idea if the Cool VL experimental or Singularity Alpha contain specific updates for RLV/RLVa outside of any work Kitty Barnett may be undertaking for RLVa and SSB.Aslo, just because the basic functionality of RLVa appears unaffected by SSB does not means that there are deeper, more subtle issues which need to be addressed in order to ensure all of RLVa continues to function correctly under SSB.
Summary
SSB is beginning to find its way into TPVs and appears to be working well – which is not to say that there are not bugs and issues still to be resolved with the service as a whole. Doubtless, we’ll find out more on this as LL continue to analyse the results of the initial pile-on test, and further tests are undertaken in the future. As a result of this quick-and-dirty play with the service over a number of viewers, I’m certainly curious to know if some of the issues encountered during the pile-on / load test (such as a noticeable slow-down in the time needed for outfits to render after a change) might be indicative that the system still needs tweaking in order to handle larger numbers of outfit changes, rather than all the problems being related to other issues on Aditi itself.
In terms of potential RLVa issues, I draw no conclusions; as mentioned above, the fact that the most obvious RLVa functions worked OK for me is not to say RLVa and SSB are without issues; there is much which goes on “under the hood” with RLVa which could very well be affected by the arrival of SSB which requires code refactoring but which does not result in outright / obvious breakages.
If you’d like to have a play with SSB for yourself, use the links below.
Related Links
- Singularity viewer Alpha versions (SSB present in version 3856+ unless otherwise stated)
- Cool VL Viewer (SSB present in the Experimental branch of the viewer)
- Radegast 2.8
- Lumiya 2.4.0+
- Sunshine test region with SSB enabled (Aditi)
- Notes on accessing Aditi
- Avatar Baking: “and the clock has started” – overview of SSB (December 2012)
Inara Pey: Living in a Modemworld 
There is nothing really broken about RLVa with server side appearance. It takes some post merge adjustments in the code, but nothing major. I have a feeling that some devs are trying to explain away their difficulty in adopting SSB code with some issues that are not necessarily real.
What is going to break are hacks that used the fact that appearance was generated client side. For instance setting “z-offset” that is common amongst TPV viewers will no longer work. Another “feature”, temporary textures, will also be non functional after server side appearance is released.
LikeLike
Yep. Covered the loss of temp textures in my main “and the clock has started” article linked-to above :). Ta for the SSB pile-on test image I used in my report on the test itself – was so busy faffing with outfit changes, I forgot to take my own shots!
LikeLike
Actually, SSB is present in any alpha build after(but not including) Singularity’s last release (3624).. though I’d suggest using the more recent alpha builds to avoid early bugs.
As for RLVa, Shyotl seemed to do a good job of adjusting it to serverside baking… so yes, no longer identical to Kitty’s original patches, so far nothing new has come in to Singularity from RLVa for SSB. (Looks like the last time Kitty’s RLVa repository received a commit was the end of October.)
And it looks as though Cool VL Viewer does not use Kitty’s RLVa, but rather Marine Kelley’s RestrainedLove, however, I cannot speak for Henri. I do remember seeing a few RestrainedLove bits moving around in the updates to SSB there.
As I said at the last TPV meeting, the TPVs avoiding the merge should just dive right in, anything they can’t figure out or accidentally break can be sorted out later once Kitty Barnett has less on her plate.. it might even help her to have other attempts at the merge to go by.
LikeLike
Yep. Henri uses RLV as noted in the article. I quoted Singu 3856 for the reason you mentioned – better later than earlier :).
LikeLike
It’s almost impossible to log in to SL or stay logged in, so I wonder how I can offer help.
LikeLike
We didn’t make any adjustment to RLVa at all. The code merely needed to be moved, in accordance with refactoring which LL have made together with SSB project. I.e. if you were to try to merge RLVa and SSB directly, you would get a massive textual merge conflict – the code needs to be readded by hand, and apparently a game of Mikado seemed much better to the involved than simply doing what needs to be done.
There could still be bugs from refactor at our end though – it could affect us more than it would affect V3s.
LikeLike
I’ll take the example you mentioned: many shoes made “z-offset” almost mandatory (especially 20cm-high platforms, not even putting the instep’s height into the equation). What’s going to happen then with them?
LikeLike
I’ve spoken with Nyx about this, I’m to prepare an example use case.. if you have one I can present already (shapes and shoes or chairs), I’d be grateful for the help.
Z-offset may even end up in the LL viewer.
LikeLike
In order for z-offset to survive it would require a new network message, and a modification of server side appearance server. Considering how LL is reluctant to add new network messages (for instance “rebake” was needed for SSB, they didn’t add it, but implemented ugly hack instead) and modify servers, I consider likelihood of that functionality appearing in Linden Viewers and Servers to be very close to zero.
LikeLike
Nyx and I had a discussion about this today. I left with the impression he is contemplating adding a function into the wearables instead of a viewer saved parameter like it is now. If this actually does take place, this means not only will LL have server side support for it’l, but it will be a LL feature as well. (obviously no promises at this point)
LikeLike
I’m willing to act in a test pilot capacity. I have some shoes that act weirdly.
LikeLike
Hmph, my previous comment was a reply/question to Latif Khalifa. Now it seems as if it’s out of context.
LikeLike
YAY for science! Inara you soo rock!
i didn’t even realize there were several viewers with SSB in and working already, so thanks for the handy one stop shopping links too 🙂
LikeLike
You’re welcome :).
I only scratched the surface of things, but hopefully it’ll help allay some worries in the community & encourage others to try hopping over to Aditi and reassuring themselves that SSB won’t be the end of the world, even if it is presenting some bumps and changes :).
LikeLike
I’m going to be really harsh today.
What really surprises me – and is indicative of a certain software and product development culture – is that LL said “we’re implementing SSB” without first performing any real testing – and it shows that no real testing was performed. We’re only, what, less than a month away from the date that SSB is going live and only now did LL bother to perform a load test. TPV devs were talking about problems with RLV/RLVa, yet, despite the well-known fact that RLV is all about scripting, the test regions had scripts disabled?
Finally, without providing the developers (i.e. the “community programmers” as they are called in other open source software projects) with proper testing capabilities, and without listening to them when they raise concerns and try to provide solutions, how can LL expect to (a) detect bugs and (b) solve them? The way I see it, the only things that currently help LL maintain its ecosystem of users, content creators and TPV devs is the locked-down nature of the main system itself. If SL itself was open source, LL would have an OpenOffice.org-style fiasco on their hands.
LikeLike
Harsh, and not altogether balanced.
Currently, we have no idea as to when SSB will be deployed – and nor does LL; so it’s not realy valid to state “we’re less than a month” from seeing it go live on the main grid.
As to testing, it’s fair to say that LL have likely done internal testing – indeed, Nyx has stated as much as Simulator / server meetings. However, there is only so much LL can do in this regards, and as such, getting help and support from users isn’t that unsual. Furthermore, it’s likely that more widespread testing hasn’t really been feasible because the software (either server-side or in the prject viewer, or both) hasn’t been at a point where broader tests would achieve anything. As it stands, Nyx has underlined several times that the pile-on / load test on the 21st February was only the first such test.
There are still concerns around SSB (Z-offset being one, as mentioned in comments here), and there is still much more to be done – but let’s not over-egg things just yet. So far, LL’s approach has, in terms of looking towards deployment, been reasonably sensible and erring more towards caution than any attempt to steamrolling things. It is true that various problems have arisen through some lack of transparency (the close JIRA really doesn’t help people when it comes to collaborative work), but there are channels of communication which are open between external devs and LL through mailing lists and user group meetings. So it is not as if the Lab is being completely deaf. Selective in what they may want to hear and act upon, yes. But not utterly deaf to all things.
LikeLike
As far as I remember, LL’s initial planning for SSB’s rollout was somewhere near the end of February, then it was said that mid-March became a more realistic date. Now, I’m not unfamiliar with internal testing. In the software company where I work, the developers do internal testing all the time; they have set up their (cloud-based) application on a local server and do as much testing as they can think of doing there. Then, they have a beta subdomain, on which they put the newer updates/upgrades online and they test them there, in collaboration with some of our clients who have agreed to help us in testing new features and in certifying that our own customisations work well with the upstream code (as we’re in the open source business). As a matter of fact, we’ve gone the extra mile and reproduced on our beta subdomain the exact user interfaces and custom forms and features our “test pilot” clients use, so that they can perform their tests in a 100% realistic environment.
And we also have the demo version, which gets updated only when we feel confident that our customisations work without problems with the upstream code, and then, after at least one month’s worth of rigorous testing on both the beta and the demo subdomains do we change things on the “commercial” side of things, which needs to be 150% stable and trouble-free.
Also, being selective in what a company wants to hear and act upon is more often than not a policy that can cause major problems, as it can lead to ignoring something that can cause a domino effect later on. For instance, when a certain part of an application is poorly written and then years pass without a code cleanup and, instead, more and more code is piled upon that exact part, with no planning, no coding style decided upon, no structure… The developers will eventually find themselves, perhaps three, five, ten years later, with an unworkable and unfixable mess, where it’s nigh on impossible to (a) locate problems, (b) fix them, (c) add or disable features, (d) rework certain features.
I can understand a “right now we don’t have the resources or the know-how for this, but we’ll get on it first chance we get” policy; it’s honest, sincere and shows determination to handle and fix things.
There are many things that should have been fixed years ago; while I was initially enthusiastic about server-side baking, I’m now wondering if other things should have taken priority first, such as the human skeleton used in Second Life (in many poses its appearance is utterly atrocious) – it’s had issues since 2003. Ten years have passed and it’s still… Ugh. Not to mention the shoe bases, which never really took into account the fact that, in a virtual world, someone just might want to create sky-high shoes (from stripperific and fetish platforms to Venetian-style chopines); not to mention the multiple issues with animations and poses that simply can’t always accommodate avatars of different heights (or, what’s worse, couples animations – hugs, cuddles etc – where the two avatars have different heights and proportions). Like I said, I once was highly enthusiastic about SSB; it looked like the answer to my (and others’) prayers w.r.t. the often unbearable and persistent problem of blurry textures (skin, clothing etc): there were times when no amount of texture rebaking or refreshing would get the textures to get crisp for more than two seconds. So, I was looking forward to SSB. Now, though… I’m having second thoughts.
LikeLike
“As far as I remember, LL’s initial planning for SSB’s rollout was somewhere near the end of February, then it was said that mid-March became a more realistic date.”
Well, no.
LL have only confirmed they would give at least eight weeks notice for TPVs to integrate the SSB code. That’s hardly a set-in-stone deadline, and makes no direct reference to actual deployment of the service to the main grid. And there has alwasy been something of an acknowledgement that even that time frame would be extended – something which became inevitable when the first viewer-side updates didn’t appear until week seven of that time frame.
“Also, being selective in what a company wants to hear and act upon is more often than not a policy that can cause major problems”
– Is pretty much haw most companies operate. LL is, whether we like it or not, hardly unique. I’m not defneding their policy – just stating that sadly, that is all too often how the world turns.
As to skeletons, bounding boxes, et al – yes, there are lots of things on the “could’ve / should’ve” list – and doubtless the user community can be divided a dozen different ways as to which of them could’ve been done or should’ve been done. As such, LL are always caught between a rock and hard place no matter what they do. However, when it comes to avatar baking, it has to be said that it is one of the items most frequently complained about (alongside of “lag”, etc.), and one of the most visible annoynaces within SL and a cause od considerable source of frustration, upset and confusion right across the user community. Ergo, one can hardly blame LL for attempting to do something about it.
“So, I was looking forward to SSB. Now, though… I’m having second thoughts.”
That’s a shame. It’s only bee one pile-on test so far, from which we have yet to get full technical feedback – even my own report on the test is really little more than anecdotal, over all. As it is, the Big Worry over RLVa now appears to be pretty much a non-issue, and while we have yet to see any feedback on the Z-offset issue, it is the weekend, and has only just been formally reported (either today or in the last few days), and a detailed response is yet to be had from LL.
LikeLike
*Sigh* All we can do now is wait and see, I guess…
LikeLike
Nyx will be having an open UG today (Monday) at noon SL time at http://maps.secondlife.com/secondlife/Borrowdale/81/218/33 . He will most likely talk about some of the outcome of that test last week.
LikeLike
So, it’s going to be around 12pm SLT? I’d like to have an opportunity to hear about the way things are moving and perhaps get a chance to say one or two things (unless someone else voices the same concerns in a better, and perhaps more eloquent and constructive, way). Thank you.
LikeLike
No surpises: Firestorm is falling behind as its programmers, having forsaken Phoenix Viewer, are falling behind trying to get their hyper-buggy viewer of preference to work with Linden lab’s code. Meanwhile, competent programmers like Henri Beauchamp and Siana Gearz are making their viewers, which utilize the V1 user interface, stable and working with few or no noticable problems.
Looks like jessica Lyin’ and her merry band of suckups are finding out just how tough it is to keep their cruddy V3 clone working well. Their fault and their problem. For those of us who actually prefer stable viewers with user interfaces that are easy to use and learn, we’ll keep enjoying SL just fine.
LikeLike
Guess Henri and Siana will be glad to have grateful users like you!
LikeLike
Everyone has their preferred viewer – that’s fine. The Firestorm team made a decision on their future – and were perfectly entitled to do so. They are not alone in pointing to potential issues with SSB / RLVa (NiranV Dean actually held a hand up publicly and pointed to problems ahead of anyone else.
Certainly, neither problems with code or decisions made on which viewer a team has opted to support is any excuse for attacking individuals or claiming anyone is lying.
LikeLike
Kitty and I have been working together to get SSB and RLVa updated in FS, which now that she got it working in her repository (as noted here a few days ago) I was able to get the last of it merged into Firestorm late last night. This was all done in a private repository on BitBucket for the past several months because most of the time it wasn’t complete enough for public use. Kitty has also been really busy with work on the materials project which Oz Linden had asked her to do work. This severely divided her time she could have spent on merging SSB to RLVa and thus slowed down the progress for both her and myself. Having said all this, I am pleased to say that our work is now live on our main LGPL repository, and therefor FS now supports SSB and the latest RLVa (to be called 1.4.8 after a bit more work). There is still some work to be done to find and fix bugs, but we are well on track to do just that.
Also, I just got to say to latif how wrong you are about RLVa not being an issue: http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/430772353d3a
LikeLike
We have now merged SSB into our lgpl tip…
As for RLVa not having any problems with SSB as suggested by other open source developers who run viewers on OLD versions of RLVa, perhaps all of this is just fluff http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/430772353d3a . Mind you, that’s just one commit. There’s also http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/1cc56b49d77c .
Or just have a peer through http://hg.phoenixviewer.com/phoenix-firestorm-lgpl .
But it seems very important to many folks to accuse us of lying and trying to discredit us and that’s fine. We rarely actually bother defending against it anymore, we would rather stay focused on our users than shooting down other viewer projects. Being the #1 viewer and viewer project by such a large degree makes us a target. We’re used to it.
LikeLike