SL project updates week 17/1: server, viewer, Avatar Complexity

221B Baker Street; Inara Pey, April 2015, on Flickr 221B Baker Street, circa 2012-2015, as seen in the BBC’s series Sherlock – and in Second Lifeblog post

Server Deployments, Week 17

As always, please refer to the server deployment thread for the latest updates.

  • On Tuesday, April 20th, the Main (SLS) channel received the server maintenance package deployed to all three RC channel in week #16, which comprises internal server logging changes and new flags for llGetObjectDetails()
    • OBJECT_BODY_SHAPE_TYPE – returned list entry is a float between 0.0 and 1.0. Anything > 0.5 is male, otherwise female; -1.0 if the avatar is not found
    • OBJECT_HOVER_HEIGHT – returned list entry is a float, -1.0 if the avatar is not found.
  • There will be no deployment or restart on the three RC channels on Wednesday, April 22nd.

This means there will be no Main channel roll in week #18, but there should be a new RC update, although this is still being worked on.

SL Viewer

The Avatar Layer Limits RC viewer updated to version 3.7.28.301019 on April 20th. This viewer allows users to wear up to 60 wearable layers (jackets, shirts, tattoo, alpha, etc.) in any combination and any number per layer up to the overall maximum of 60, rather than each individual layer being limited to a maximum of 5 items.

The Tools Update RC viewer has been performing very well since the last update (April 15th), and there has been something of a debate in the Lab as to whether or not to promote it to the de facto release viewer. While there is no hard-and-fast rule about when an RC is promoted to release status, very often the Lab prefers to leave two weeks between releases unless something is urgently required. Sticking to this would mean the viewer won’t be promoted until week #18 (week commencing Monday, 27th April); however we’re still early in the week, and things might change.

Viewer Managed Marketplace Beta

The Viewer-Managed Marketplace (VMM) officially started an open beta test on the main grid, which is scheduled to last for about a month for details see:

Avatar Complexity

Avatar Complexity is the term the Lab has settled upon for the upcoming functionality which provides greater control to user to define how other avatars are rendered in their world-view.

The idea is that as avatars can often be the single biggest impact on the viewer in terms of rendering, particularly in crowded places, so  Avatar Complexity will present a means by which avatars which require a load of render processing by your GPU can be rendered as a solid colour instead, which should help with performance on lower specification systems. Due to their solid colours, avatars rendered in this way have already been dubbed Jelly Babies or Rainbow People.

At the Open-source Developer’s meeting on Monday, April 20th, Oz Linden explained that “Avatar Complexity” has been chosen for the name of the capability to distinguish it from avatar imposter rendering, which will remain in the viewer alongside Avatar Complexity when it arrives. The difference between the two can be summarised as:

  • Avatar impostor rendering is a simplified and less frequent rendering of avatars further away from you, while those close to you remain fully rendered
  • Avatar Complexity renders any avatar exceeding the value set within your viewer as a single, solid colour, regardless of the avatar’s distance from you.
Avatar complexity is intended to help those who may hit performance issues as a result of their GPU struggling to render complex (hight render cost) avatars, by rendering such avatars as solid colours.
Avatar complexity is intended to help those who may hit performance issues as a result of their GPU struggling to render complex (hight render cost) avatars, by rendering such avatars as solid colours.

Oz further indicated that Avatar Complexity will be managed via the Advanced panel in Preferences > Graphics, and will initially be enabled / disabled in the official viewer based on your GPU’s benchmark (the value use to determine the viewer’s default graphics settings when first installed). Some TPVs may opt to leave the capability disabled by default (once the code is available for inclusion in TPVs), and allow users determine whether they wish to use it or not.

Currently, work at the Lab is focusing on a couple of aspects of the functionality:

  • Toning down the colours used by the viewer when rendering avatars in this way – as the functionality can currently be tested via two debug settings within the viewer, there have already been strong criticisms of that “Jelly Baby” rendering on account of the brightness of the colours
  • Server support is being added to pass on the counts of avatars that are and are not rendering to those using Avatar Complexity.

It is also probable that before the capability appears in a project viewer, it will also be set to  display notifications when you change your own complexity, and when the number of avatars not rendering you changes.

If you wish to experiment with the settings are they are at the moment, go to Advanced > Debug Settings and type-in RenderAutoMute. Select RENDERAUTOMUTEFUNCTIONS and set it to 7, then experiment with values under RENDERAUTOMUTERENDERWEIGHTLIMIT (start with 100,000, and increase or decrease it to alter the number of avatars around you rendered as solid colours (lower values = more avatars rendered as colours).

3 thoughts on “SL project updates week 17/1: server, viewer, Avatar Complexity

  1. Pretty rare that LL provides something truly useful. This will save a lot of time vs right click derendering people at a crowded, laggy concert for example. Now if they’d just get smart and either do away with mainland (doesn’t everyone just want an island surrounded by ocean?) or, at the least, expand the idea of avatar privacy (that was HUGE) to “parcel privacy” wherein every BUILDING (eyesore or not) within some number of meters from your position would not be rendered they could conceivably make SL thrive again! 🙂

    Like

  2. I fear you are forgetting the so many that still use mainland and travel around it, the worst thing ll could do was to end mainland.
    Just join a sailing cruise and you will understand why:
    Mainland is the best asset Second Life has compared to other virtual worlds.
    The worst it happens in mainland is the abuse of sec orbs and ban lines.
    If one needs privacy there, is so easy to build up a sky box over 1000m, but never try to close it on ground level up to 1000m.

    Like

  3. And just to add, nor rendering an avatar or a building shall always be an option on viewer side and a choice of the user, not the other way around.

    Like

Comments are closed.