Day: February 23, 2013

Playing with SSB and viewers (quick test)

Posted on by Inara Pey

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.

The three faces of SSB:
The three faces of SSB:On the left, what is seen when running a viewer which does not support SSB: the viewer user looks fine, but everyone else is a grey ghost. In the centre, what is seen when looking at someone who is using a viewer which does not support SSB: they are a cloud. Right: what is seen when both parties are using a viewer with SSB support: properly rendered and dressed avatars (remember: SSB does not affect prims / sculpts / mesh, hence why these render OK in the non-SSB viewer)

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.

SSB on Singularity:
SSB on Singularity: Top: as I render in Singularity with SSB, as seen by myself (l) and with the official SSB viewer (r). Bottom: as I appear after an outfit change to both myself in Singularity (l) and the official SSB viewer (r).

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.

baking-rad
Baking on Radegast: (top) outfit changes on an SSB-enabled region render correctly in Radegast and (bottom) are also correctly rendered in other SSB-enabled viewers

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

SL projects week 8 (3): Viewer, materials and SSB load test

Posted on by Inara Pey

SL Viewer Updates

Release and Beta Viewers

The release and beta version of the viewer are effectively on a par with one another at this point in time, following the roll-out of SL viewer 3.4.5.270263 on February 14th. There is currently nothing “in” beta at the moment in terms of specific SL projects.

Development Viewer and CHUI

The development viewer and the development version of the CHUI (Communications Hub User Interface) project viewer are also pretty much on a par, and it is anticipated that the CHUI code will be merged-up to viewer development “any minute now”, to use LL’s parlance, although a date has not been indicated. The viewer development code branch is pretty much waiting for this to happen, and CHUI remains in pole position as far as LL’s code merge plans are concerned, so potentially there could be more news on this in week 9.

Project Cocoa

Work is progressing on Project Cocoa within LL. This is a rarely talked-about project to update LL’s Mac support to the Mac OSX Cocoa API specifically for OSX 10.8 support, and remove dependencies on old Mac APIs which are not well-supported any more. The overall goal of this project, as commented on by Widely Linden is to, “Get people building cleanly with 10.8,” although OSX 10.6 will continue to be supported, although it will no longer be possible to build a Mac viewer using 10.6 once this project has been deployed. Widely also commented that there is a project viewer and source code for this work, which interested parties “should snag.”.

Vivox Update

Work is underway to update the SLvoice plugin to use the latest release of Vivox. This should bring with it a number of benefits including: security updates, stability improvements (although perhaps not improved connection reliability), better echo cancellation and – anecdotally, at least – better voice quality. There is no ETA on when this project will be deployed.

FMODex

Linden Lab continue to work on utilising FMODex as a replacement for FMOD.

Materials Project

There has been significant progress in fixing the known outstanding issues on the project which are standing in the way of a public project viewer and viewer code appearing. Speaking at the TPV Developer meeting on Friday 22nd February, Oz Linden said, “Our list of things which must be fixed before we can hand it out to people is now down to one.” However, there is still no estimated date as to when a project viewer and source code will actually appear Real Soon NowTM, which appears to put them both closer than Pretty SoonTM and Real SoonTM on the LL scale of things :).

Materials processing: with one remaining issue to fix, a project viewer now really should not be that far away. In the meantime the server code is fully deployed to the main grid
Materials processing: with one remaining issue to fix, a project viewer now really should not be that far away. In the meantime the server code is fully deployed to the main grid

As has been reported in my server-side news for the week, the server code for materials is deployed to the whole of the main grid, and so the system will be usable as soon as project viewer surfaces.

Server-side Baking

What is likely to be the first in a number of Server-side Baking load / pile-on tests took place on Thursday February 21st. Results were, at best, mixed, for a variety of reasons.

The test was held in the Sunshine project test regions on Aditi, immediately following the Server Beta User Group meeting. Those participating were asked to use the latest iteration of the official project viewer, which had been set-up for LL to do a certain amount of data logging. Anyone encountering issues was asked to raise a JIRA under the SUN project, listing issues encountered, with the viewer session log attached.

the test was in two parts:

  • Part one: performed on a region still running on a region using the current baking system, this saw people change between three of four outfits so that some baseline data could be obtained at the LL end of things. As this was using the current baking system, the usual baking issues were apparent
  • Part two: performed on a region running the new baking service, this again saw people changing between a number of outfits, this time monitoring and reporting on their own experiences.

Results were, it is fair to say, mixed. They were also not helped by the fact that Aditi itself has significant issues with inventory, etc., which made the test considerably more complicated than perhaps needed to be the case (for example, people were getting “object failed to rez”-style messages and other errors as items could not be fetched from inventory, etc.).

SSB load test: mixed results (image courtesy of Latif K
SSB load test: mixed results (image courtesy of Latif Khalifa

As an overall load test on the service itself, this should have generated some interesting numbers for LL with at least 40 people participating in the test at its peak. Commenting on the test on Friday 22nd February, Nyx Linden said, “A big thank you to everyone who participated in the pile-on yesterday. We got a lot of data out of it, [and] it looks like the majority of the issues were inventory-related, and we’re going to be digging into those. Anecdotal evidence suggests that when the system worked, it worked pretty darn well; but there were some people who had more trouble than others … We are looking into the remaining issues; we’re going to be fixing them as quickly as possible.”

While Nyx indicated that the majority of problems were inventory-related, he also stated that he and his team were still digging into the data to see if the problems were purely related to the known issues with Aditi’s inventory handling, or whether some of the issues are apparent in the inventory system itself, either on the server-side of things or within the viewer itself.

Continue reading “SL projects week 8 (3): Viewer, materials and SSB load test” →