Visual Auto-mute: a farewell to ARC/ADW upsets?

A new set of functions has been released by LL as a changeset, and is starting to find its way into SL Viewers.

Essentially, this functionality allows you to set thresholds above which avatars with a very heavy load (high-res textures, complex attachments (multiple prims, flexi prims, sculpts, and what have you), etc., – but not scripts, which are a completely different kettle of fish) will not be rendered by your Viewer. Instead, such avatars will appear as “grey ghosts”, similar to when they’ve been muted; however, IMs and chat can still be exchanged. This should theoretically reduce the load placed on the Viewer and a your system in terms of rendering, and lead to an improved SL experience.

It’s important to note that the functions only affect how such avatars are rendered in your world-view; they will still render normally in their own view, and for anyone who hasn’t set thresholds / has higher thresholds than you. Also, your avatar will remain visible in your view, no matter how you set the limits.

The thresholds are governed by two functions, initially released by LL as a set of debug settings:

  • RenderAutoMuteByteLimit – Maximum bytes of attachments before an avatar is automatically visually muted (0 for no limit)
  • RenderAutoMuteSurfaceAreaLimit – Maximum surface area of attachments before an avatar is automatically visually muted (0 for no limit)

These currently require numerical values to be entered. However, it is possible that they’ll find their way into at least some Viewers as Preferences options, possibly using sliders. Zena Juran has already opted for this approach with the latest release of the Zen Viewer (below).

Visual Auto-mute as presented in the Zen Viewer

The functions are supported by a new addition to the Develop menu: Render MetaData->Attachment Bytes. When active, This displays a set of figures over / near avatars, which can be used to help you to determine the byte and area thresholds you should set.

Rendering Metadata->Attachment Bytes display enabled

The approach has already come in for considerable discussion on the SLU forum, where opinion seems to be weighted towards the favourable.

Certainly, it can’t be denied that avatars can impact Viewer performance enormously, so any moves that enable the user to have a greater degree of control over what is hurting their SL experience is potentially a good thing. But lag is a very sensitive subject – as anyone who has encountered upsets in the past due to people using ARC as a Big Stick can testify.

This approach would appear to be a lot more beneficial than something like ARC and its successor, Avatar Draw Weight (or ADW) are concerned, as it should hopefully reduce the amount of finger-pointing and hostility that goes on when people have arbitrary figures in red floating over their heads like a glaring accusation of wrong-doing.

It’s also somewhat friendlier than the other alternative to “blocking” “overloaded” avatars: that of audio mute, which denies any communications capabilities where some might be preferred and which can, if done on a group basis, leave a poor soul ostracised in silence with no idea why.

There are, however, some drawbacks. On the minor side, it is possible that setting the options when entering a popular venue may well result in you finding one or more friends around you turn into grey ghosts  – or that you end-up greyed-out in their view. This might in turn result in strained relations, but shouldn’t really be anything reasonable people can get past – and even joke about privately.

This isn’t necessarily a “one size fits all” solution as well; it is possible that, depending on the type of venues a person visits (in terms of popularity popularity, nature of the activities carried out, etc.), the thresholds may need adjusting from time-to-time in order to gain the best benefits / compromise in terms of performance benefits and visual appeal. This may limit the scope to which the new functions are used, as people are not always willing to fiddle around with sliders as they teleport around SL.

It also needs to be remembered that avatars aren’t the only load placed on the Viewer, and using functions like these might not help tremendously when moving around an environment that has dozens upon dozens of high-resolution textures all over the place (such as a store or mall). In this regard, the effectiveness of the system needs to be balanced against alternative approaches (such as the use of avatar imposters, or by simply turning-down your draw distance and turning down / off various options within the Viewer Preferences) in order to improve one’s in-world experience.

The biggest question-mark over the new controls, however, is that of effectiveness. If the results of playing with the new options is an improvement of a couple of fps in overall performance and/or a very slight improvement in rendering time, then it is unlikely that they are going to gain a lot of traction. But if people see a demonstrable improvement in their overall experience, then it is liable that the functions are going to prove more popular.

That said, anything tha moves us further away from the finger-pointing extremism that has been the plague of ARC /ADW, has to be a step in the right direction, doesn’t it? One possible benefit from this approach is a greater awareness and consideration of just how one’s own avatar might be impacting other people’s experience within SL, simply by seeing that it exceeds the thresholds one is setting against other avatars.

Well, one can hope, can’t one?

9 thoughts on “Visual Auto-mute: a farewell to ARC/ADW upsets?

  1. Hey that is great. So people with crappy computers can still go forth in a world of gray avatars. This sort of shit is so much more important than fixing the horrible defects that have haunted SL for ages. And the avatars, attachments, scripts, or not, once over 25, will bring the poorly performing homestead code to it’s knees in regions with avi count and prim count raised to what used to be full region status. Hint: LL is not maintaining 8 sets of region code. All regions run the same code. Full regions just have the avi and LI count parms higher. Thios poor performance arrived with homesteads so put 2 and 2 together.

    Like

  2. Sighs, Anne, viewer performance is the only issue mentioned here not homestead/’empty’ performance.

    Like

  3. While Anne is talking about a different aspect of performance, I agree with her basic sentiment. LL shouldn’t be implementing new “features” that limit the SL experience, they should be concentrating on improving the performance of SL for everybody.

    Like

    1. Well, yes and no.

      Yes, they should be seeing to things for everyone – that’s where the server-side sorting-out comes in, and Ann is spot-on (which is not to say LL aren’t doing anything to address matters).

      No, I don’t entirely agree that this option limits the experience.

      It’s client-side, and optional. Yes, there are factors to consider (such as grey ghosts around you (I was so tempted to call this piece “The Sixth Life: I see dead avatars….”) But if people are prepared to accept that and are content to live with it, then who is to say their experience is limited?

      Are there better solutions? As it is, people have been crying out for LL to “improve” Viewer performance, with many still using older hardware, etc. So, as flawed as it might be, this strikes me (with the caveats as given) as possibly a reasonable compromise, given LL have little or no control over the Viewer end of the equation when it comes to hardware, net connection and whatever else people are running while also accessing SL…

      Like

  4. Dear drama dripping hope: The people with nothing but greyed out avis in view are still going to lag because the lag is caused by crappy LL region code. LL has a long history of blaming everyone else for their shoddy work. Now we have avi ghosting and corrupted inventory folders again. Explain that. LL is driving SL out of business so they can move on.

    Like

    1. You know, I tussled over introducing client side / server-side lag into this article, but then decided to push the server side of things out of the report on the the code, as it risked muddying the waters on what is essentially a client-side “fix” for that end of the equation. As it is a little more of my opinion shows through on what is essentially a “news” item than I usually like…

      That said, the server-side of the equation is there, and is an issue and does need to be looked at….which Rodvik has stated is and will be the case. One certainly hopes so.

      Like

  5. This seems like a good idea to handle issues with too much to render when in places with very intense avatars.

    Yes it does nothing to fix some issues. But nothing fixes everything. Each portion of everything fixes its own little piece of something.

    Giving people more ways to improve different aspects of performance is not a bad thing.

    Overall, on balance, the viewer has been performing better and better on ‘the same old machines.’ Now for those whose systems still get overwhelmed, there is one more tool to try to see if it can help.

    Like

Comments are closed.