Day: November 19, 2014

SL project updates week 47/1: server, viewer, RenderAutoMute functions

Posted on by Inara Pey

Nordan om Jorden; Inara Pey, November 2014, on FlickrNordan om Jorden (Flickr) – blog post

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-7686 – “Avatars are not coming on viewer”
  • 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”
  • BUG-7691 – “Won’t rez properly”
  • BUG-7694 – “Textures and meshes loading slow or refusing to load”
  • BUG-7698 – “Textures much slower to load on a CDN region then on a clone of the same region not running CDN”

See the release notes for further details.

Maintenance RC Viewer

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. You'll need to have RENDERAUTOMUTEFUNCTIONS set to 7 for it to work smoothly, and should note
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, and then experiment with RENDERAUTOMUTERENDERWEIGHTLIMIT
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.