Server Deployments – week 8
The deployments scheduled for the week commencing Monday 18th February are detailed below. Please note that due to Monday 18th being a holiday in the United States (Presidents Day), the deployments will be taking place one day later than usual.
Main (Second Life Server / SLS) Channel
The Main channel should receive the following two projects:
- The Interest List Improvement project, which has been on the Magnum RC channel for the past few weeks
- Server-side support for materials processing.
Note that there is still no publicly available project viewer to take advantage of the materials project code, although there may be news on this later in the week.
This deployment should take place on Wednesday 20th February – release notes.
Bluesteel and LeTigre Release Candidate (RC) Channels
Bluesteel should receive Baker Linden’s object rezzing code changes, which were reported here in week 1. These updates have nothing to do with the interest list code changes. Baker describes the aim of the work as, “Hopefully significantly decreasing lag spikes when rezzing large, complex objects. Large does not necessarily imply size, but size of the files being read. When an object is rezzing, we have to parse the object / mesh files and create our in-world objects with that data.”
Until now, reading and parsing of any files related to objects which require rezzing has been on the main thread. When several such objects requiring rezzing at the same time, the simulator stalls. Baker has been moving the reading / parsing operation to a background thread in the expectation that rezzing multiple “large” (again, in terms of file size, not the size of the object itself) objects will not choke the simulator, causing performance issues.
These deployments should take place on Thursday 21st February – release notes (Bluesteel).
Magnum Release Candidate (RC) Channel
Magnum should receive the same maintenance server update deployed in week 7 to LeTigre, intended to fix miscellaneous crash modes.This deployment also includes the following:
- An improvement to the rolling restart notifications so that they appear in an alert format (as with manual region restarts) rather than an easily missed notification. This change will only be apparent in restarts following the code deployment restart (as per JIRA SVC-7759)
- A fix to an encroachment / return problem: if you’re banned from the neighbour’s parcel, you couldn’t select / return items that encroached on your parcel (see JIRA SVC-496)
- Instant messages are now truncated to 1024 bytes to prevent certain types of delivery failure. Currently, the IM database supports larger messages than the delivery system can handle. This change will enforce a limit of 1024 bytes when processing messages coming into the database as well as those being sent out.
This deployment should take place on Thursday 21st February – release notes.
SL Viewer News
The release version of the SL viewer moved to the 3.4.5 code base on the 14th February, with the release of viewer 220.127.116.110263 (release notes). At the same time, the Server-side Baking project viewer received its second update with the release of version 18.104.22.1680409, od which more below.
The CHUI viewer received a further update to the development version, reaching 22.214.171.1240520 on February 18th. This project is currently the next in line to merged into the viewer-dev code base (development viewer) and then into the beta code base.
Server-side Baking Load Test
A reminder that if all goes according to plan, there should be a special load test for Server-side Baking on Thursday February 21st, and volunteers are being sought to assist.
This will take place on the SSB test regions on the beta grid (Aditi), immediately following the Server Beta User Group meeting which take place at 15:00 SLT on Thursdays in Morris, also on Aditi with the aim of placing the SSB code under a stress test representative of the loads it will face when deployed to the main grid, with people routinely changing outfits, updating their appearance, enter / leave regions running the SSB code (given that the grid will, for a time, be running both the current avatar baking service and SSB as the latter is initially deployed), and so on.
While final details of the test have yet to be confirmed, key requirements for those wishing to participate in the test are as follows:
- Participants must be able to log-in to Aditi and attend the Sunshine test regions from 16:00 SLT onwards (participants can attend the Server Beta UG meeting ahead of the test if they wish)
- Participants must be running the latest version Server-side Baking project viewer (version 126.96.36.1990409 or later) – this viewer has been specifically configured to report statistics required by LL for the test
- Participants should have a number of outfits of system clothing, preferably with multiple layers, which they can swap between during the course of the test. Library outfits are acceptable, but LL are keen for people to use their own outfits to add greater weight to the tests
- Clearing the viewer cache prior to the test is suggested, but not an absolute requirement.
“if you have specific failures we’ll ask for your viewer logs, otherwise just running through the test will help us gather data,” Nyx added when explaining what is required by way of feedback from those opting to take part.
Further details can be found in my SSB Load Test announcement.
Interest List Overview
As noted above, the interest list code will be deployed across all regions on Wednesday 20th February. The majority of these changes elate to how object updates are sent to the viewer, and are designed to reduce the amount of data the server is sending to the viewer, thus helping improve performance. As such, most of them should be fairly transparent to most users, although some improvement in object and texture rendering when logging-in / teleporting between regions may well be noticed, together some changes in behaviour when camming / moving around after teleporting. However, two very visible changes which will result from this deployment are camera follow / camera clamping and mini-map changes.
Camera Follow / Camera Clamping
Up until the arrival of this interest list code, everything seen in-world is almost exclusively based on its position relative to the avatar, regardless as to where you move the camera. This has been why, the further you cam away from your avatar, the less reliable object rezzing becomes, with sculpts failing to load at the correct LOD, and small objects – even avatars – failing to render, etc., until you physically move your avatar closer. In technical terms, this is because the camera is effectively “clamped” by the server code at 0 metres from your avatar.
The new interest list code changes this. Firstly, everything seen in-world is based on its position relative to your camera – in other words viewer rendering “follows” the camera, rather than being based on the position of the avatar. This means that as you cam out from your avatar, objects of any size should continue to rez correctly as they enter your camera’s field of view (so sculpts should not longer appear to be stuck at a lower LOD despite having your camera hovering just a few metres away from them, for example).
However, under the new code, the effectiveness of the “camera follow” is “clamped” by the server to a sphere with a radius of 128m centred on the avatar.
This does not mean you are unable to cam-out more than 128m metres – you can continue to cam-out as far as you like. Nor does it in any way inhibit your draw distance.
What it does mean is that when the camera is up to 128m metres from your avatar, the level of detail for all objects “seen” by the camera will be calculated correctly, and the objects rendered at the correct level of detail, as explained above. But if you move the camera beyond 128m from your avatar, level of detail calculations continue to be made as if the camera were only 128m from the avatar, so the further out you cam, the more detail is lost, and small objects will increasingly fail to rez, sculpts will fail to load at the correct LOD, avatars will fail to appear in your camera’s view, and so on.
How this works is perhaps best shown in the two images, above and below, which illustrate “camera clamping” in action. In the picture above, I am standing 100m from the fireplace (well inside the “camera clamp” sphere), and have cammed into it. Note the little “Facebook cube” rendered on the mantlepiece.
In the image below, I am standing 180m from the mantelshelf and have again cammed-in. However, because the server considers my camera to only be 128m from my avatar (and thus some 52 metres away from the fireplace), the “Facebook cube” is no longer rendered, as it level of detail is too low to be accurately calculated by my viewer.
Overall, this change on its own should bring significant benefits to users, allowing them to cam locally and see everything there is to see around them, while the 128m server-side camera clamp should help safeguard people’s privacy from other camming-in on them from two or more regions away.
A further visible change with the interest list code is with the Mini-map, which will now displays the entire region and – in the case of Mainland / contiguous estates – any neighbouring regions, regardless of the draw distance set within the viewer.
A more subtle change to the Mini-map is that of “Z culling”. Up until now, 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 until you move closer. However, once an overhead object has been rendered on the Mini-map, it will remain visible on it no matter how far you move away.