SL projects update week 39 (3): viewer, interest list, HTTP, SSA and more

The following notes are taken from the TPV Developer meeting held on Friday September 27th. A video, courtesy of North, can be found at the end of this report. The numbers in braces after each head denote the time stamp at which the topic can be listened-to in the video.

SL Release Candidate Viewers

SLShare

[03:00]

Following my coverage of the release of SLShare, the opt-in capability for those wishing to link their Second Life accounts with their Facebook accounts, A question was asked as to whether the feature would be available to TPVs. Speaking at the TPV Development Meeting, Oz Linden provided comments which answered this question more fully, and and Merov Linden gave further information on the functionality in general.

“One of the design considerations is that this is a feature you [TPV developers] can all integrate without any problem,” Oz said. “All of the actual connections to Facebook, all of the handling of the requisite authentication tokens and permissions and [the] relationship with Facebook itself, is all handled server-side. So the code that’s in the release candidate viewer is something that you can integrate so that you can also make this feature available on whatever schedule you would like to.”

He went on to confirm that given this, no Facebook information for users of the service is exposed to TPVs.

As to how soon it might be before the SLShare RC is promoted to the release viewer, Oz again reiterated that it depends on how well the various candidates currently in the release channel perform. Currently, the metrics for the viewer look good, according to Merov, so it may still leapfrog its way to becoming the release viewer. However it is more likely that it will not become the de facto viewer for at least another two weeks.

Despite the negative reactions to the feature which have appeared in the comments following blog posts, etc., reporting on the functionality, the Lab believes SLShare is already “getting a lot of use”. This view is based on the numbers of people who have pro-actively gone and downloaded and installed the RC viewer manually.

While this may be a case of the Lab greasing the wheels a little bit (downloading and installing the viewer isn’t necessarily the same as running the feature),  Firestorm are reporting that they’ve had at least one request for the feature to be added to their next release.

During the meeting, a series of questions were raised on the feature:

• Will the feature become opt-out in the future, rather than opt-in? Merov Linden:  “It’s opt-in. We’re not doing anything [behind] the back of the residents.”
• Will the feature create a Facebook account on behalf of anyone using it? Merov Linden:  “There is no API to create an account on Facebook on behalf of someone.”
• Will it lead to a merging of the current SL feeds with the Facebook feed?  Oz Linden: ” No, there is no connection between the Second Life profile feeds and the Facebook feed. They have no relationship at all … In theory one could probably build a viewer that did that, but we’re not planning on it.”

(Further questions passed unanswered due to the region in which the meeting was being held being subjected to a griefing attack which left it in a poor state and prompted a change of meeting venue.)

Viewer Statistics

[33:26]

The Lab has been putting together a new statistics reporting system, which is now starting to be used to generate a range of reports. Commenting on some of the information which is coming out of the system, primarily in response to questions asked at both Open-source dev and TPV dev meetings, Oz indicated that:

• Almost one-third of regions within SL have at least one materials-enhanced object in them, which is described as “dramatically faster” than the adoption of mesh
• The number of avatars wearing materials-enhanced mesh / prim clothing is “steadily climbing”
• The number of people who have Advanced Lighting Model (ALM) enabled on a “class 3” (mid-range Graphics cards) or above is just under 20%

One of the problems here – from the Lab’s point of view at least – is that both Singularity and Firestorm have ALM turned off by default for almost all graphics settings, except perhaps High-Ultra, and Ultra. The flip side to this is the view that the Lab enables ALM by default on cards which are barely able to support it, with the result that people’s SL experience suffers through poor frame rates.

In the past the Lab has pointed to data which tends to show that viewers running on low-end graphics cards card do indeed suffer performance issues with ALM active; mid-range GPU show little difference in performance between running with ALM active or not and have “reasonable” fps rates; high-end (“class 5”, as they call them) cards  – e.g. ATI Radeon HD 7800, 7900, 8900, 8950 + similar, nVidia GTX 460/460SE, 465, 550TI, 580, 660/660TI + similar – perform significantly better with ALM active.

The problems here are how one defines “reasonable” frame rates and how one interprets ALM. For the Lab, it would appear that “reasonable” frame rates is anything in double figures – e.g. above 10; many users would disagree with this. At the same time, many users still appear to equate having ALM active with having Shadows enabled (which actually leads to a far larger performance hit), but the two are actually quite separate. As had been pointed out a number of times in these pages, ALM can be active without having to enable shadows.

Nevertheless, part of the new viewer statistics system should enable to Lab to gather and present performance numbers for cards with and with ALM enabled, filtered by viewer, so that TPVs can better judge matters for themselves.  In addition, Oz is going to be looking at ways and means of doing systematic testing with cards in order to generate more meaningful statistics, and which may allow for other factors which influcence performance (other avatars in the same region, the amount of movement going on, viewer settings, etc.).

Understanding Viewer Performance

[45:41]

A further problem with the viewer is that it is complicated, and while there are many tools to help monitor performance, people either focus on the wrong tools or cannot find those that would be helpful to them in diagnosing an issue when they do encounter unexpected performance drops.

To this end, Oz floated the idea at the TPV Developer meeting for TPV devs to give thought as to which tools and information feeds within the viewer would be useful to users to help them understand what is going on, and how best to present said tools, etc., in a way which would make sense to users and enable them to make use of the information they are seeing.

Interest List Viewer Status

[23:06]

As noted in part 2 of this week’s report, the Interest List project / RC viewer has yet to appear. Reporting on this, Oz indicated that it is still failing to get past LL’s QA, and work is still ongoing with it to get it to a point where it can pass QA. When this may happen remains unclear.

Viewer-side LSL AO Support

[20:44]

There hasn’t been much progress on getting this discussed in more detail within the Lab, primarily because those who would be needed in such a discussion have been involved in other projects  – interest list work, etc.

One suggestion Oz put forward as a potential means of getting things moving might be to provide the means by which viewers  can use current animation capabilities without the need for a script bridge. He also went on to say:

What I’m discovering, which probably won’t surprise very many of you [TPV developers] is that every time I bring up the subject of animations anywhere, and that gets reported, I get inundated with e-mails from people telling me about how I should change the fundamental animation system. So just to let people know, fundamental changes are unlikely at this point. That’s just not really on the agenda.

So if you’re reading this, and do have ideas on how the core animation system within SL can be changed, please don’t e-mail Oz about it! In the meantime, he will keep looking into what it would take to develop, as he called it, “an animations influencing interface for viewers to use”, but it will be a slow activity.

Group Ban List

[23:51]

Baker Linden has been absent the past few in-world meetings. However, he is apparently continuing to work on the new group ban list functionality (see JIRA VWR-29337), and he believes that he is “real close” to having all the elements (server and viewer) in place. He’ll apparently be making himself available once more when he has a project / RC viewer to talk about.

Server-side Appearance / AIS v3

[24:47]

Work is continuing on clean-up work within the project, with work being done server-side and viewer-side. One of the biggest elements of this work is a new set of APIs for the inventory service. In Oz’s words, this work, “Essentially aggregates some operations that are currently multiple things into a smaller set of more powerful APIs so that you can doing things in a single API that currently take more than one”.  There should be more news available on this work at the next TPV Developer meeting, if it doesn’t emerge via other meetings first.

Although this work is under the Server-side Appearance umbrella, it has far wider implications that just the new SSA service, and as such, they’ll be introduced alongside the existing inventory service. This work is being referred to as the Advanced Inventory Service version 3, or AIS v3 within the Lab, and the reason the work is currently under the SSA umbrella is because most of the issues the Lab are seeing with regards to SSA are in fact inventory related (e.g. CoF issues).

HTTP Updates

[29:55]

Monty Linden has confirmed that the viewer-side HTTP updates which will leverage the changes recently deployed server-side (new caps, etc.), is now almost ready for QA at the Lab, and that he’s being going over the test plans with the QA team.

While working on the project, Monty has been able to refine the code to remove race conditions, and he also reports that the viewer and server can now handle a lot more with fewer connections between the two, which should led to greater stability with connectivity between the two.

A further element of the updates are changes to libcurl which will stop using c-ares and start using a threaded resolver library. Monty regards this as the “experimental” aspect of the viewer changes (and which, for what was said, may appear in a project viewer, rather than a release candidate viewer with the other forthcoming changes). The reason for the change is that it may get rid of the DNS problems SL suffers from.

Tethered Cellular Connections

[31:56]

Related to both HTTP and SSA are reports that some people using tethered cellular devices to connect their laptops to Second Life have been experiencing baking issues, which has led to a “lively” (as Monty  put it) discussion on the forums. He went on to say:

So the usual disclaimer from Linden is that we don’t support wireless (it’s still 1995) … but we are interested in these problems. This is seen as a new behaviour, and the behaviour seems to have something to do with the various carriers messing with HTTP, and nobody has a solution for this other than beat all of the carriers into a bloody pulp…

He then invited anyone who has experience in tethered connections to feel free to carry out tests, etc, and to participate in the forum thread.

With thanks to North for the video.