SL project news: week 48/3: Interest List update

Andrew Linden continues to forge ahead with his initial work on Interest Lists, which forms a part of the Shining Project. As reported last time around, the issue of people’s HUDs appearing on other people’s screen has been fixed, and the code is currently with LL’s QA for testing.

Given the progress made, Andrew re-capped on the project / gave further insight into this initial phase of the work Server Beta User Group meeting on Thursday November 29th.

Object Updates

The first phase of the new interest list code is aimed at reducing the amount of information being sent to the viewer by the server. This done through the code only sending required updates to the viewer for objects which are within the camera’s line-of-sight. Essentially, updates on objects take three forms regardless of which Interest List code is being used:

• A “full” update – required when an object is “seen” for the first time or which is constantly updating position / appearance
• A “terse” update – required only when an object is changing appearance / position relative to the viewer’s in-world view
• A “please delete” update when the object has been removed from the viewer’s in-world view (e.g. it has been deleted or taken back to inventory).

The new updates are aimed specifically at the number of “terse” updates being sent to the viewer. Under the current Interest List code, these updates are continuously sent out by the server to all viewers in range of an object in motion or undergoing change, regardless as to whether what is being updated (in terms of movement or appearance) is actually visible in the window of the viewer. With the new Interest List code, updates are only sent to your viewer based upon what is actually in your world view.

This means, for example, that if you can see a bouncing ball on your screen and then turn your avatar or camera so it is no longer visible to you, under the old system, data packets relative to the ball’s motion continue to be sent to your viewer, even though they are no longer required. With the new system, the updates cease shortly after the ball moves off your screen, and only resume as the ball moves back on to your screen once more (no actual content is broken by this change, it is simply a change in the amount of updates being sent from server to viewer).

The net result of this is to reduce the amount of data the server is sending to the viewer, thus helping improve performance. As the new code applies to both objects and avatars, this can amount to a substantial improvement, as Andrew commented during the meeting, “I think we’re currently seeing a 30% improvement (in the time spent in “Agents” in the stats) for the case of about 30 avatars running around in a region with 12k prims”.

However, there is a side issue with these changes, which Andrew and the devs are currently looking into. If you turn away from a moving object for a length of time such that the terse updates from the server are no longer sent, then suddenly pan the camera / turn so the object is once again in view, there might be a brief delay (one second, currently) before the object correctly updates. This is because the viewer is rendering the object based on its “old” data received from the server before getting the latest updates from the simulator. The time delay can potentially be reduced, but doing so can negatively impact the overall performance gains made. Because of this, Andrew is holding it at one second in order to ascertain how much of an impact the delay actually has as the code is tested.

Camera Follow

Currently, everything you see in-world is almost exclusively based on its position relative to your avatar, regardless as to where you move the camera. This is why, as you cam further away from your avatar, objects may appear with less and less detail, or may not render at all (particularly smaller objects) – their respective level of detail is being calculated based of their distance from your avatar, not from their distance from your camera.

With the new Interest List code, what you see in-world is now based upon the position of your camera. The benefit of this being that as you cam around, objects should render at the correct level of detail relative to your camera (so no more sculpts which appear to be stuck at a lower LOD despite your camera hovering a few metres away from them, for example). The difference between the two approaches can be seen in the image below.

A further benefit with the new code is that it has been adjusted to better handle linksets which are made of small prims or which include small child prims within them. Under the current code, camming-in to such linksets can create rendering issues; either the linkset is slow to appear, or appearing with gaps in it. With the new code, this should no longer be the case.

Server-side Camera Clamp

An important point to note and understand with the new Interest List code is the concept of server-side level-of-detail camera “clamping”. This has caused some concern and possible confusion at user group meetings when it has been mentioned, so the following points are intended to help explain what it means:

• Currently, the camera position is “clamped” on the server-side at a distance of ZERO metres from your avatar, simply because everything is calculated on the basis of your avatar’s position and not your camera’s position, as explained in the section above
• The new Interest List code “clamps” the camera server-side to a sphere 128 metres in radius from your avatar. This “clamp” does not affect how far you can move the camera viewer-side (you can still, for example move the viewer-side camera position out to 200 metres from your avatar). However:
  • This new “clamp” distance means that within 128 metres from your avatar, everything is calculated for level-of-detail based on your camera’s actual position, with the result that objects should be correctly rendered in detail (as with the little black cube in the example image above)
  • If you move the camera beyond 128 metres viewer-side, updates from the server will continue to be sent as if the camera were still positioned128 metres from your avatar. This means that if you move the camera 200 metres from your avatar in the viewer, the server will continue to calculate level-of-detail updates based on the camera being no more than 128 metres from your avatar, with the result that objects already cached by your viewer at a low level of detail may not render properly / at all (as is currently the case) until you move your avatar to bring them within the 128 metre server-side threshold

It is also important to note that this “clamping” does not in any way limit Draw Distance or the data initially sent to your viewer when you first log-in to Second Life or when you teleport to a new region. That data is still sent to the viewer as is currently the case – so if you have DD set to 256 metres, everything within 256 metres of your initial camera position should render, with the viewer determining what can actually be “seen” in your world view. It is purely the additional level of detail updates to that data sent from the server which are affected by the Interest List changes.

Mini-map Changes and Z-culling

The new code brings some changes to the Mini-map. The first, most obvious change is that the Mini-map will render the terrain for an entire region, and not just the terrain within draw distance. This has been done so the code is not constantly scanning for newly visible areas of land, and is focused instead on objects which are within / entering visible range.

The second is with “Z-culling” –  adjusting the amount of information sent to the Mini-map as to what is overhead. Currently, the Mini-map will show anything overhead. With the new code, any overhead objects that are within two times your Draw Distance will show on the Mini-map, but anything beyond that will not, at least until you move closer to it. Once rendered on the Mini-map, however, they will remain visible on it no matter how far you move away.

Bug Fixes

As a part of his Interest List work, Andrew Linden has been investigating a number of server-side bugs. One of these is PATHBUG-183, which relates to offscreen physical objects flying across your in-world view. He had hoped to have fixed this issue – or at least reduced the frequency with which it happens, but as noted in Part 2 of this report, there have been reports that the problem is still occurring with more-or-less the same frequency in regions (Ahern on Aditi) were the code has been deployed.

Another issue the initial release of the Interest List code should resolve is with the region you have just left appearing to “reset” itself (re-render) in your viewer.

Current Status

As mentioned at the top of this article, this initial work on Interest Lists is currently with QA. Andrew had the code will be in a position to be added to an RC channel code release queue in week 49 (week commencing Monday 3rd December). However, a potential bug relating to the update of work attachments may have been identified during the Beta Server meeting on the 29th November which Andrew will be investigating further. In it, people reported an issue with attachments failing to render correctly as avatars entered their field of view until they turned their camera away from the avatar and back again, which would force the attachments to render correctly.

In the meantime, the new Interest List code can be tried-out at Ahern and Morris on Aditi, no special viewer is required.