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.
Inara Pey: Living in a Modemworld 