SL projects update week 42 (3): viewer, AIS v3, HTTP

The following notes are taken from the TPV Developer meeting held on Friday October 18th. A video, courtesy of Northspring, can be found at the end of this report. The numbers in braces after each heading (where given) denote the time stamp at which the topic can be listened-to in the video.

A typical TPV dev meeting gathers (stock)
A typical TPV dev meeting gathers (stock)

SL Viewer Release Pipeline Updates

The Catalyst RC viewer (version was promoted to the de facto release viewer on Wednesday October 16th. This viewer was essentially a “hot fix” to address a start-up crash on viewers using the latest AMD Catalyst drivers (13.9, 13.10, 13.11).

At around the same time, the Maintenance RC viewer RC noted in part 1 of this report as being released on October 14th was withdrawn. It was subsequently superseded on Friday October 18th by a new build,  RC, comprising the same updates: finer access control for estate/parcel owners; CHUI: toggle expanding Conversations by clicking on icon; GPU table update + more.

“ShareStorm” Viewer

Also on Friday October 18th, the SLShare RC ( and the Snowstorm contributions RC ( were withdrawn and superseded by a new “ShareStorm” RC viewer, version, containing the updates from both.

Viewer Promotions – Time Frame

Due to the volume of work backed-up prior to the implementation of the new viewer release process by the Lab, RC viewers were initially being promoted  to a release status on almost a weekly basis. This has slowed a little more recently, with a promotion to release occurring around once every two weeks (with the exception of the Catalyst RC “hot fix” viewer mentioned above). Barring further situations like the Catalyst RC, the plan is to try to promote an RC to release status around every two weeks.

Interest List Viewer

[01:20 – 22:18]

Richard Linden attended the TPV Developer meeting on Friday October 18th to discuss the upcoming viewer-side changes for the interest list project. He started by giving a high-level overview of the work.

The primary focus of this work has been on scene loading – how things are presented to you when you log-in or teleport to a region. Historically, most of the work related to the interest list has been driven by the simulator. This is not the most optimal way of doing things, and could mean, among other things, that when arriving in a region, you’d start to see things far away from you rezzing first before those much closer to you – so if you arrived inside a house, you’d see the buildings and trees outside of the house appear before the walls of the house would pop into view.

Recent work on the interest list has been aimed towards improving scene loading in the viewer
Recent work on the interest list has been aimed towards improving scene loading in the viewer

So the first part of the work focused on the server end of things. Most of this has already been deployed to the grid, and the benefits can already be felt. There is more structure in how the server sorts and prioritizes data to be downloaded to the viewer, so that when you arrive in a region, the objects which are closer to you or are bigger than others should render first (e.g. when you arrive in the house mentioned above, the floor, walls and ceiling appear before those things outside of the house).

The upcoming viewer changes take this work a stage further, but in more subtle ways.  What is classified as a “cacheable” objects has been changed, for example, allowing the viewer to potentially store more information on objects locally, rather than perhaps depending on the simulator for information relating to them. Additionally, the viewer will be able to retain more overall information relating to a region than is currently the case – fewer “killobject” messages are sent by the simulator telling the viewer to remove objects from cache, allowing them to be re-used rather than the viewer necessarily having to request data on them from the simulator once more.

There are other improvements within the code to assist with better scene loading, such as when you arrive in a region you’ve never visited before (and so have nothing cached). Under the current system, the simulator will send queries to the viewer about every object in the region, because it has no way of knowing if the viewer has data for the region already cached. Under the new code, as the viewer connects to the simulator it will tell the simulator it has no data cached. The simulator can then get on with prioritising the data and getting it downloaded to the viewer, with the result that “several seconds” are shaved from scene loading times.

In other words, to borrow from Richard put it, the updates put the viewer far more in the driving seat with the interest list.

There are also some additional under-the-hood changes within the viewer as well, such as a new metrics system called LLTrace (documentation still in development). This was written to objectively measure scene loading as a result of the changes made to both the server and the viewer code, and unifies a number of metrics such a fast timers into a single fast and flexible system. It should allow things like performance to be measured in a more granular manner, which may help in the future with tracking down issues within the viewer.

A further “side benefit” with these changes is that they may allow TPVs to identify further improvements which can be made to the viewer side of the interest list and put them forward to the Lab for consideration / implementation.

Part of the delay in getting the viewer code out is that the changes have required considerable work to be carried out on how the viewer manages memory usage. While having the viewer take far more control of interest list operations should yield performance improvements, one of the side-effects is that it can lead to a much bigger memory overhead in trying to keep track of objects, their geometry, and so on. Therefore the Lab has spent a lot of time tuning this to ensure things are as balanced as possible between performance and memory use.

Currently, there is one regression related to performance the Lab is looking to resolve. This involves the viewer using a lot of memory in some cases where graphics settings are high and shadows are enabled. However, outside of this, Richard now believes that the vast majority of intrusive bugs have been dealt with, including the most recent issues of objects steadfastly refusing the render in the interest list viewer without a relog, and objects vanishing from view when moving the camera and refusing to re-render until after a relog. So the viewer should be appearing very soon as a release candidate.

Whirly Fizzle demonstrates one of the issues with the initial interest list viewer code, which meant her house would not render. Unlike the recent “missing prims” issue, no bounding box, etc., was loaded by the viewer, so right-clicking where the house should be would not resolve the issue – a relog was required

The plan is for the viewer to remain as a release candidate for a “good long soak time” in order to give TPVs the opportunity to look and the code, and for any additional bugs to surface. Precisely how long the viewer remains an RC is open to question and dependent upon what else is in the release pipe and how it is performing, but the thinking is that it will be for a few weeks.

The new code (server and viewer) won’t solve all scene issues currently being reported. There are still objects for which control is still maintained on the simulator and which require updates from the simulator to be received by the viewer in order for their state to visibly change.

For example, the issue of doors you’ve passed through (and which are outside of your field of view because they are behind you) appearing to still be open when you turn and face them after a minute or so, even though the simulator considers them to have closed behind you, won’t be fixed by these updates. However, work has been put into trying to resolve other issues of a similar nature, such as Andrew Linden’s work on fixing the “Meeroo issue”, which saw animations on Meeroos and other animals failing to update correctly when camming around. As Richard pointed out, there are still some complex interactions going on, and dealing with them isn’t necessarily easy.

HTTP 1.1


Monty Linden reports that due to a lack of resources within LL’s QA team (largely the result of the volume of work they are currently dealing with), the current HTTP work is “sitting on the side” awaiting its turn in the QA queue. The updates, which include a single libcurl library change, will most likely go to a project viewer once they have cleared QA, and then will progress from there.

In the meantime, he has started work on the next phase of the HTTP work. This is focused primarily at HTTP pipelining, and will involve a bigger round of library updates, which Monty has already started work on, together with fixing associated dependencies.  The hope is that this phase of the work will be shorter than the previous two phases of his HTTP work, although Monty does note that he has some server work to do as well.

AIS v3


AIS v3 should see further improvements to viewer / back-end communications and for SSA
AIS v3 should see further improvements to viewer / back-end communications and for SSA

The latest changes for the AIS v3 updates (inventory improvements & SSA code “polish”) have been made available in the Sunshine external repository, and within a set of pre-release autobuilds of the LL viewer.  The code is not 100% finished, and the viewer shouldn’t be used as a primary viewer, but is available for use with the updated test regions on Aditi (the server-side appearance Sunshine test regions).

The code is also available for TPVs to start merging into test branches of their viewers so that they can also test the code on Aditi.

Discussing the updates, Nyx Linden did issue a warning that any viewers built using earlier versions of the AIS v3 API should not be used on the Aditi test regions, as doing so may result in inventory corruptions.

This latest update also includes a clean-up  which sees the removal of the viewer-side code for avatar bake uploads. So TPVs providing OpenSim compatibility need to take care when merging the code in order to ensure avatar bakes on OpenSim grids do not get broken. Nyx states that the clean-up amounts to a “handful” of commits in the code which should be relatively easy to identify.

It’s not clear as to when the code is likely to appear in a project or release candidate viewer. As Nyx indicated, it is not 100% complete, and time scales may well be dependent upon the results of Aditi testing.

With thanks to North for the video.