The following notes are taken from the Server Beta User Group (SBUG) meeting held on Thursday, December 18th, 2014, and the TPV Developer meeting held on Friday, December 19th. A video of the latter is included at the end of the article, my thanks as always to North for recording it and providing it for embedding.
With reference to the meeting video, summary notes are provided below with time stamps to assist is spotting and listening to the associated conversations.
Server Deployments Week 51 – Recap
On Tuesday, December 16th, the Main (SLS) channel was updated with the server maintenance package deployed to the three RC channels in week #50
There were no deployments to the RC channels.
The end-of-year code freeze / no change window comes into effect from the end of the week, this means there will be no further server updates until January 2015.
SL Viewer
Release Viewer
The Maintenance RC viewer, version 3.7.23.297296, was promoted to the de factorelease viewer on Thursday, December 18th. This viewer comprises a solid collection of bug fixes and improvements to many areas of SL, and also includes a range of fixes to previously released changes in the way joint offsets in rigged meshes are handled. Please refer to the release notes for further information.
Experience Keys RC Viewer
On Wednesday, December 17th, the Experience Keys / Tools viewer was updated to release candidate status with the release for version 3.7.23.297364. Please refer to my overview of the viewer (written while it was at project viewer status) for information on the viewer.
Further RC Updates
[00:50] As a result of the promotion of the Maintenance RC, both the new Experience Keys RC viewer and the HTTP Pipelining RC viewer are currently being rebuilt to include the Maintenance release code. These updates may appear in the release viewer pipeline on Monday, December 22nd, or they may be held over from release until after the end of the no change window.
Viewer Build Tools Project
[01:41] The new year should also see the first release of a project viewer for Mac and Windows built using the new build tools chain and autobuild process.
Group Chat
The last of the 2014 updates are being deployed to the back-end servers. At the time of the Server Beta User Group meeting, there were just a “few more” hosts that had yet to receive the updates, so things should be completed in short order. These improvement are focused on improving the overall robustness of the service and dealing with overload conditions.
CDN Work
What is being referred to as a “mini CDN” test was carried out on the BlueSteel region on the morning (PDT) of Thursday, December 18th. The test was designed to check a more flexible CDN configuration that is going to make it easier for the Lab to deal with fall overs. “It should be invisible normally but lets us have better control of where the viewer gets those mesh and texture assets,” Simon Linden said of the work, which will likely see a formal deployment in the New Year.
Viewer-managed Marketplace (VMM)
[03:53] There was an in-world meeting held on Friday, December 12th to discuss the Viewer-managed Marketplace (notes and transcript).
There should be a summary post from the Lab, covering JIRAs raised on VMM and comments made on the forums, which should be appearing on the current forum thread around the time this update is published. A further feedback meeting is being planned for the New Year.
My apologies for the lateness of this update; have been busy with a variety of things, both SL and non-SL.
Server News – Week 47
There are no server deployments during the week, due to the hardware inspections taking place, which involved restarts taking place from Monday, November 17th through Friday November 21st, as detailed in the Grid Status updates (as a reminder, there is an additional period of maintenance due on Wednesday, November 18th, commencing at 13:00 SLT).
According to Simon Linden, speaking at the Simulator User Group on Tuesday, November 18th, the work on the servers requires each box being taken down, opened-up and physically inspected, and parts (unspecified) possibly being swapped-out.
Exactly what amount of work (if anything) is required on each server may vary, making the process something of a piece of string when it comes to how long it will take per box.
What prompted the work isn’t clear, but there was muted speculation that some servers may need a physical update of some description to avoid the potential of failing due to a defect. Whether this means one of the Lab’s suppliers altered them to a problem or not or something else has come up, isn’t clear.
However, none of this work should, outside of the rolling restarts, affect the performance of any regions.
SL Viewer
HTTP Pipelining Viewer
A new HTTP Pipelining RC viewer appeared on Monday, November 17th. Version 3.7.21.296736, see a “reduced pipelined texture and mesh fetching time-out so that stalled connections fail quickly allowing earlier retry. Time-out value changed from 150 seconds to 60 seconds.”
It is hoped that this viewer fixes the following issues:
BUG-7687 – “Nothing is rezzing in SL,, av’s are all gray and textures will not rez”
BUG-7688 – “Since the last restarts I cant seen to see things I rez from my inventory or wear mesh in my inventory. I have done numerous clean installs of the latest LL viewer. I have also made sure I am not running the beta version of the AMD CCC”
BUG-7690 – “Textures and Meshes abruptly stopped rendering”
There are reports that the Maintenance RC viewer currently in the viewer release pipeline (version 3.7.21.296734) contains a number of regressions for joint position bugs. These issues are apparently known by the Lab, which hopes to have them corrected before the code merges with anything else.
Group Chat
There have been various reports of further group chat issues doing the rounds. On Monday, November 17th, for example, it was noted through Firestorm Support chat that at least two group chat server were down. Asked about this during the Simulator User Group meeting, Simon Linden replied:
Yes some of the chat servers have been having troubles in the last few days. I’ve been looking into that … the code running there isn’t super new, and the outages might be timed with some of those restarts. In any case, there is an update soon for the chat servers, and already another in the pipeline.
Experience Keys
No major news here, other than those trying the Experience Keys in the current beta are being urged to file any additional issues they may have found as BUG reports as soon as they can. Simon Linden added to the request, “we’re trying to finish off the last few issues and have that Real Soon Now (sometime in the future, no promises).”
As previously indicated in my coverage of Experience Keys, the first release of the capabilities will not allow for grid-wide experiences, although this is something that is on the Lab’s list. Commenting on the plans, Oz Linden said:
The first general release of experiences won’t include being able to get a grid-wide key. It’s not so much that as there are more issues for us to deal with for grid-wide experiences, and we don’t want to make people wait for the ones …. Being able to do grid-wide experiences isn’t going to fall of the to-do list or anything.
As Oz was speaking, Simon Linden added:
We’ve talked about it before, and having a widely available data system like the key-value store would be really great, but there are a ton of issues with that being available, scaling it to cover the full SL population and all that. So we’re going ahead with a more feasible sized feature set.
RenderAutoMute Functions (Avatar Complexity)
One of the heaviest impacts on viewer performance comes not from issues with the SL servers or in rendering the contents of the the region you’re in, but from avatars themselves, particularly in crowded or busy regions. The Avatar Imposters option within the view can help with this, however, the Lab is looking to bring a debug setting to the fore within the viewer’s UI to further help users control their viewer’s performance.
The setting in question is RENDERAUTOMUTERENDERWEIGHTLIMIT, which is somewhat tied to the Avatar Render Weight (once aka Avatar Render Cost), the colour-coded render value assigned to avatars which can be displayed over their heads via the Advanced menu (CTRL-ALT-D to enable if not visible): Advanced > Performance Tools > Show Draw Weight for Avatars.
Essentially, the idea is that by entering a value against this setting, you can define a limit above which the viewer will cease rendering avatars fully, and instead will render them as a sold colour imposter, regardless as to how near / far they are from your point-of-view, reducing the rendering load on the viewer / your computer.
Currently, you can use the RENDERAUUTOMUTERENDERWEIGHTLIMIT option within the viewer to set a limit on rendering high-ARW avatars as solid colours in your viewer. Note how the debug setting doesn’t correlate with the ARW for the avatar – something that will be fixed when the setting becomes a UI option (which will also see the dependency on setting RENDERAUTOMUTEFUNCTIONS removed – see the notes below)
I used the term “somewhat tied” above, because there is currently no obvious correlation between a number set within the debug setting and Avatar Render Weight, which is a figure that is in turn impacted. A further problem with the setting as it currently stands is that it is actually calculated by multiplying the number you enter against RENDERAUTOMUTERENDERWEIGHTLIMIT by a certain LOD (level of detail) factor (so if you set RENDERAUTOMUTERENDERWEIGHTLIMIT to 60,000, the actual figure being used might be 92,000 – 60K x the LOD factor).
Both of these points of confusion will be addressed by the Lab in making the option directly available through the viewer UI, so that there is a much clearer and obvious correlation between the setting and ARW. Oz Linden is also working on colour-coding the resultant solid avatars so that it is possible to determine those avatars which are just over any limit set in the viewer and those which are well over the limit, allowing users to further fine-tune their settings according to needs / circumstance.
The two debug settings: you’ll need to set RENDERAUTOMUTEFUNCTIONS to 7 in order to experiment with RENDERAUTOMUTERENDERWEIGHTLIMIT
The option can actually be experimented with at the moment, although it currently has a dependency on another debug setting – RENDERAUTOMUTEFUNCTIONS - which must be set to 7 in order for any of the RenderAutoMute functions (5 in all) to work. Again, the Lab indicate that this dependency will be removed when RENDERAUTOMUTERENDERWEIGHTLIMIT becomes a UI option.
Again, the emphasis is on “experiment”, simply because of the lack of a direct correlation between values entered into the debug setting and the ARW values of surrounding avatars. However, if you do want to have a play with the setting as it is at the moment, Oz Linden suggests starting with a value of around 60,000 and working up or down from there, depending on your needs / circumstances.
There’s no time frame as to when this work may find its way into a viewer, but Oz is actively working on it, following a prompt from third-party contributor, Jonathan Yap.