Update Match 18th: The “mesh only” HTTP test regions, referred to as “coming soon” in the HTTP section of this report are now online on Aditi, and are called MeshTest2 (DRTSIM-203), MeshTest2A (DRTSIM-203A) and MeshTest2H (DRTSIM-203H), respectively. In addition, the sandbox areas (unrestricted access) are also now available as Sandbox HTTP (DRTSIM-203), Sandbox HTTP A (DRTSIM-203A) and Sandbox HTTP H (DRTSIM-203H).
The planned deployments for the week went ahead as scheduled. Namely:
- On Tuesday March 12th, the Second Life Server (SLS) Main channel received Baker Linden’s large (as in complex) object rezzing project, designed to improve region performance when rezzing large objects – release notes
- On Wednesday March 13th, the BlueSteel and LeTigre Release Candidate (RC) channels received a server maintenance package, intended to fix a common crash mode – release notes
- Also on Wednesday March 13th, the Magnum RC channel received an update to the server maintenance package deployed in week 10, with further improvements / fixes. These included the removal of the fix for VWR-786, which rather than correctly fixing the known issue (IMs to friends not respecting their privacy settings) resulted in all IMs to non friends returning the “User is not online” message, regardless as to whether the recipient was online or not. Release notes for the package are on the SL wiki. The Lab, according to Maestro Linden, is going to have to, “Go back to the drawing board,” to resolve this problem.
As I’ve mentioned in past reports, the aim of this “large object” rezzing project from Baker Linden is to improve how complex objects (those which have a lot of scripts and / or a large file size), with the focus of the work moving the parsing of object files onto a background thread in order to prevent the simulator being choked and performance spiking when such objects are rezzed. As such, the work applies to both in-world objects and attachments, with mesh potentially being a primary beneficiary of the changes. The thought is that the new code may also help frustrate griefers, as the simulator FPS should be better when multiple scripted objects are being rezzed.
The SL beta and development viewer were both updated on March 14th. The beta viewer moved to release 220.127.116.111843, with updates primarily aimed at CHUI, as anticipated. The development viewer moved to release 18.104.22.1681846, and remains broadly in sync with the beta version of the viewer.
Alongside the FMODex (sound system) updates which will be forthcoming after the formal release of CHUI as mentioned in part 1 of this report, Vivox (the SL Voice service) is also due to be updated to version 4.5. Like FMODex, this is unlikely to happen until after CHUI has reached a formal release., but once implemented, this should result in an improvement in Voice quality.
There is still no news on this. Both the issues relating to avatar shapes and weighting are still awaiting internal resources at LL. As such, there is no timeline as to when any movement might be seen on this project.
Interest List – Issues and Further Updates
The following fixes, related to the interest list code, should be in an RC deployment in week 12 (week commencing Monday March 18th):
- A fix issue where you ‘lose track’ of a vehicle after a region crossing
- A fix for BUG-1795 (“Agent appears in incorrect position to other agents after being moved by a sim teleporter”), which should see an end to avatars still appearing in view after they have used a teleport system
- A fix for the issue where object moving off-camera would suddenly ‘snap’ into place when you turned your camera so they were in your field-of-view. Whereas up until now, the new interest list code has not sent any updates for such objects, the fix to be deployed in week 12 will once again allow updates to be sent to the viewer, but at a much lower rate than before the interest list code was originally deployed.
The code with these updates is currently available for testing on two regions on Aditi: Solariam (rated: Adult) and Tischeriidae (rated: Moderate). This code also includes updates to improve object rendering (particularly with the viewer set to low bandwidths) and to object cacheing as well, as noted in the first part of this report, and those wishing to do so are encouraged to do so, although testing any improvements to vehicle regions crossings might be contingent upon being Adult verified.
Server-side Baking (SSB) Pile-on / Load Test
The second SSB pile-on load test took place on Aditi on Thursday March 14th, immediately following the Server Beta User Group meeting. The test was undertaken using the latest version of the Sunshine project viewer and appeared to be broadly satisfactory, involving both users and a fair few LL personnel – Nyx (x2, as he had his alt there), Simon, Maestro, Monty, Dan, Don, Log, and others. As with the original test, this took place on two regions – one running the current baking system, the other running the new service. Participants were asked to change outfits using the current service, so that the project team could get some baseline / comparison stats, before everyone moved over to the “new” service on the adjoining region.
From a personal perspective, all outfit changes proceeded better than had been the case with the first test – inventory issues at that time notwithstanding at that time. I found that on the new service, my outfits changed smoothly, I had fewer instances of avatars not rezzing after crossing between the two regions (only one – Log Linden – remained a cloud in my view throughout the second half of the test – and apparently did so for several others), and there appeared to be fewer concerns voiced in chat about the baking service itself.
Where problems did occur, they were more related to the Aditi asset service (inventory) coughing under the load, with people experiencing problems with outfit attachments failing to wear and / or render. Other than these issues – which were being monitored by a Linden as the test progressed – there appeared to be few major issues with the baking service itself.
One potential issue still to be resolved is in the creation of asset links in the Current Outfit Folder (which is used to “drive” the baking update process). When the asset server is overloaded, it can result in errors in creating inventory items, which can include asset links in the Current Outfit Folder – and without these links, the baking service will not know what it should be baking. Don Linden, who is working on the project with Nyx Linden, is aware of this possible issue, commenting during the test, “Yeah, link creation is a thorn in my side. I’m hoping to add a different service for that.” Quite what this means going forward, remains to be seen.
There will doubtless be further discussion of the test during the various user group meetings in week 12.
HTTP 1.1 Update
Further to the last update on Monty Linden’s HTTP work, there are now several regions available on Aditi for testing the new capabilities, spread across (currently) three channels, as follows:
- DRTSIM-203 – this is the normal release channel intended to go to Agni supporting keepalive connections and other changes. This will comprise the following regions:
- TextureTest2: high texture count, no meshes, no scripts, low residency limit to prevent interference when doing benchmark testing (only three avatars at a time) and, according to Monty, “a nice landing point”
- MeshTest2. (
“coming soon”now available – see update at the head of this report) high mesh count (many distinct mesh assets which all look the same), few textures. Low residency limit to prevent interference when doing benchmark testing (again, only three avatars at a time)
- DRTSIM-203H – the “Happy” channel, with more generous limits and optimistic service controls. This comprises two regions, TextureTest2H and MeshTest2H which are / will be identical to TextureTest2 and MeshTest2 respectively
- DRTSIM-203A – the “Angry” channel, with stricter and pre-emptive enforcement of limits (generates many 503 errors). This comprises two regions, TextureTest2A and MeshTest2A which are / will be identical to TextureTest2 and MeshTest2 respectively
Further regions are liable to be added to these channels in the future. Some of these will present a mixture of texture and mesh content, and others will be sandbox environments which will not be subject to such strict avatar limits. (The sandbox regins are now available – see update at the head of this report.)
Monty is particularly interested in having TPV developers and scripters test these new services (particularly if the latter use external services communicating with in-world objects via HTTP), and he provides breakdown of what LL are seeking during testing on these three Aditi channels.
Overall, the benefits expected from this work is that connectivity between people’s routers and the SL services should become more robust, and those on older router hardware should see something of an improvement in their experience when connected to SL.
The new HTTP protocols should also see overall improvements in downloading data from the SL server to the viewer (some of which we’ve already seen through the initial release of Monty’s texture fetch code deployed last year). Non-texture and non-mesh data (such as prims and sculpties) passing through the new HTTP services should see a significant boost in this regard.
Mesh uploads / downloads already utilise HTTP, so Monty’s work is focused more on rationalizing how mesh uses connections between the viewer and the server, inasmuch as it currently tends to – in his words – “Shotgun the network badly” connections-wise, and he acknowledges that more work will be required to improve this going forward.
New Havok Release
At the start of the week, Havok, the makers of the physics engine used by Second Life issued a major new update, billed as the “next generation” physics engine. This has fuelled questions as to whether Linden Lab will be considering an update to their Havok engine in the near future. So far, the only response has been a mild observation from Oz Linden, who answered a question at the Open-source Dev meeting on Wednesday 13th March by saying, “I have not heard. Most likely depends on whether or not it claims to solve a problem we’re worried about.” Quite what that worry is remains unclear at this time, although I hope to find out more in week 12!