Interest list and object caching update

In June 2012, Linden Lab announced the Shining Project, aimed at implementing a range of improvements over time designed to improve Second Life’s overall improvements. Part of this work was defined as “Object Caching and Interest Lists”, which the blog post described as “Intending to provide faster drawing of objects that are most likely to be redrawn later in a resident’s session or in the next session.”

Andrew Linden has been developing this project over the last several months, as reported in an ongoing basis in this blog. So far his work has primarily been focused on one side of the equation – the interest list code itself, which has been primarily server-side work.

However, with the most recent updates, Andrew has started looking at the “object caching” side of the equation, with changes made to how the server defines “cacheable objects” held by the viewer. With the next set of upcoming updates, this work is set to expand – and, for the first time within the project – see changes made to the viewer as well.

Current Issues

Before examining the forthcoming updates Andrew has been working on, a quick update on issues people have noticed in relation to interest lists changes.

“Missing” Prims: There has been a marked increase in prims in linksets failing to render, requiring a right-click (as one solution) to make them visible. As already reported in my week 15 project updates, this is not an interest list problem per se, although Andrew views the increase in occurrences of the problem as possibly being related to his changes in how the server defines “cacheable objects”. His investigations are continuing.

Objects out-of-view failing to produce sounds: If an object is initially out of your field-of-view, it is not sent to the viewer until such time as it does enter your field of view, and so sounds from it are not played. Andrew has not had time to look into this, but notes that it is “on his radar”

Finally, and while not a technical issue per se, Andrew reports that some users are still unhappy with the way the server sends updates from objects – particularly those close to your camera  – when they pass out of your field-of-view. While not entirely sure how this can be addressed, Andrew is considering what he calls a “keyhole idea”, wherein instead of just sending updates for objects in the camera’s current field of view  – the camera frustrum  – the server might send updates for all objects within a sphere of a set radius around the camera, as well is its frustrum. However, the problem with this idea is how big a radius should the sphere be? As Andrew notes, “Whatever it is set to probably wouldn’t work for everyone,” so he is still considering options.

Forthcoming Updates

Speaking at the Simulator User Group Meeting on Tuesday April 9th, Andrew revealed that the next Release Candidate submission of his interest list work is now ready. This comprises three elements:

• Optimisations to reduce CPU cost of sending interest list-related data
• Improved streaming through re-balancing the bandwidth used by the various UDP message categories
• New “hints” the server will accept from the viewer to help it build the interest list for the viewer.

This work is aimed in part at making more intelligent use of the information on a region the viewer may already have locally cached from a previous visit, and it relies on both the initial information the viewer sends to the server on connecting to it, and what Andrew Linden calls “cache probes” sent by the server to the viewer. The approach, as explained by Andrew, basically works like this:

• On connecting to a region for the first time (or after cache has been cleared), the viewer can “tell” the server it doesn’t have any information on the region, resulting in the server sending the viewer all the data it needs
• If the viewer already has data relating to the region, the server send out a series of “cache probes” (lists of object identifiers – known as their local_id – and their versions), which the viewer then checks against its list of cached identifiers (local_id) and their versions
  • If the cached version number of an object’s local_id matches that sent by the server, the viewer doesn’t send any reply to the server, and the object is rendered directly from cache
  • If the cached version number does not match that sent by the server for a given local_id, it indicates the object has changed since the last time it was cached by the viewer, and a “cache miss” message is sent to the server in reply, which prompts the server to send the updated data, which the viewer then uses when rendering.

In order for this to work, the viewer must be able to accept cacheable data on all objects in a region – including those which are not visible on initially entering a region. “The idea here is to allow the viewer to cache more data, in case it wanders into distant corners of the region,” Andrew said at the meeting.  However, this does not mean the viewer will be inundated with a flood of additional data, as Andrew went on to explain. “The data is sent on a delay, so the non-visible objects are not streamed as soon as you arrive so that if you’re just passing through the region (within about 60 seconds) then there is no need to get all the data.”

As such, it is possible that once implemented, this work could actually improve things for people like aviators – if they are passing through regions where the majority of items are non-visible, less overall data is sent to the viewer.

Viewer Changes

Up until now, the interest list work has been server-side only. However, this latest tranch of work also sees changes being made to the viewer as well (so it can receive the required cacheable data and can send the required messages to the server, for example). As such, it will involve the release of updated viewer-side code (currently being worked on by Bao Linden) in the near future. Quite when is unclear, although it would seem that the code is nearing a point where it could be made available in a public repository and – most likely – within a project viewer.

Time Scales

Currently there is no definitive time scale for when this work is likely to start appearing. As noted above, the viewer code is currently being worked on, and Andrew noted in the Simulator User Group meeting that he is “almost done” in preparing the server-side work for submission for an RC release (whether this means it has been through LL’s internal QA process is unclear). Whether the server-side code updates will appear ahead of or alongside any viewer-side release is also unclear, although given the way the two appear to be intertwined in terms of communications, one might assume both would be released around the same time.

Related Links

• LL’s Shining Project announcement (June 2012)
• Interest List updates and reports in this blog