Server Deployments, Week 22
Update, May 28th: a back-end issue with the RC deployment has meant that all three RC channels have been rolled-back to the their previous release, leaving the grid as a whole on the same server release.
As always, please refer to the server deployment thread for the latest updates / news.
There was no deployment to the Main (SLS) channel on Tuesday, May 26th, due to there having been no RC deployment in week #21.
On Wednesday, May 27th, all thee RCs should receive a new server maintenance package, comprising:
- A change logic on accessing group member lists for large groups
- Internal server logging changes.
SL Viewer
Due to Monday being Memorial Day in the United States, the Lab was closed for normal office business, and there was no meeting to discuss potential RC viewer promotions. However, the most recent update to the Attachment Fixes RC viewer (Project Big Bird, currently version 3.7.29.301943) is showing a must reduced crash rate compared to the previous release (and which prevented it from being promoted to the de facto release viewer).
The crash rate is still slightly high than for the current release viewer, but speaking at the Simulator User Group meeting on Tuesday, May 26th, Oz Linden described it as “probably not a statistically significant difference”. Whether this means the viewer will be promoted to release status later in the week or not, remains to be seen.
Increasing the Number of Avatars Per Region
“There’s one change that I will follow up on … I added a way so I can adjust the ‘max avatars in a region’ setting. I’d like to do an experiment soon and see what falls apart if we can get over 100 people into a region,” Simon Linden said at the simulator UG when discussing the upcoming RC deployment.
“This is purely experimental and there are no plans for changing the SL limits,” he went on. “But sometimes regions hit 100 [and] it would be nice if the viewer and simulator handled that better.”
There is already an additional means en route to the viewer by which users can have greater control over how avatars around them in a region are rendered by the viewer, Avatar Complexity, when will draw avatars above a rendering limit set by the user as a solid colour (the so-called “Jelly Baby” avatars). The will work alongside the existing Avatar Imposters capability already in the viewer.
However, in terms of his experiment, Simon suggested that one way to improve things might be for the viewer to simply not draw everyone within a region; although how this would work, and the criteria used to determine what avatars are drawn and which aren’t, does require careful consideration. Simon suggested the viewer might simply skip drawing those avatars that are furthest away once a threshold number of avatars in the region has been reached. Another (suggest by a meeting attendee) would be for the control to be via the Max Number of Avatars settings within the viewer – so that once exceeded, avatars are again simply not rendered.
As noted, Simon’s work is purely experimental, and primarily aimed at helping the Lab understand what might be done to improve things where there are large gatherings of avatars, and to perhaps try out one or two ideas based on what they learn.
Simon’s Rendering Tricks
As a part of the discussion on avatar rendering, Simon handed out a note card of tips and trick for improving your performance when dealing with complex avatars. While this includes the debugs which will form a part of the new Avatar Complexity functionality, which will be appearing in a a Snowstorm RC viewer soon, as well as suggestions which may already be known, I’m including his suggestions in full here for reference:
From Advanced > Show Debug Settings, set:
- RenderAutoHideSurfaceAreaLimit 0
- RenderAutoMuteByteLimit 0
- RenderAutoMuteFunctions 7
- RenderAutoMuteLogging False
- RenderAutoMuteRenderWeightLimit 350000
- RenderAutoMuteSurfaceAreaLimit 150
In preferences / graphics, change “Max # of non-imposter avatars” to something like 8. Also try ctrl-alt-shift-4 to hide avatars, or ctrl-alt-shift-2 for alphas.
Note the two debugs shown in green are those related directly to Avatar Complexity and drawing avatars as “Jelly Babies”. Note that RenderAutoMuteFunctions must be set to 7 in order for this to work. Also note that the RenderAutoMuteRenderWeightLimit of 350,000 is purely an advisory starting point. The Lab estimate that this will reduce the very top 3% of very rendering-intensive avatars as solid colours. You may find you have to set the value somewhat lower in certain environments – such as night clubs and dance venues – in order for it to be effective. I’ve personally found that 150-200K tends to be required in very busy ballrooms, etc.
Inara Pey: Living in a Modemworld 
When they introduced SSA, going to clubs was much better. Now that people use mesh bodies and mesh clothes, often with a number of unnecessary high-res textures, complexity is increased, as well as the the amount of stuff to download and the memory required for all the textures. Multiplied for some dozen of avatars, it reduces the frame rate and increases the crashes. So a mean to give awareness to the user and to overcome this issue is welcome. I’m not sure if not rendering the avatars at all is a good idea though, as it may cause issues. For example: people will say “I can’t see you” more and club hostesses will have an harder time in figure out if the guests are following the dressing code of their club, unless he means furthest away from the viewing point and not from your avatar position.
LikeLike
As ,long as it optional, as i always have the render avatar impostors option unchecked. to be allowed to see all them.
LikeLike
I did some experiments a week or two back, and a lot of humans seem to have render weights over 100k, and there’s a huge variation in the amount due to mesh items. I’ve reason to think it it on similar grounds to the differences on LI: the polygon count and sometimes their shape.
I sort of expect that for my routine furry AV, and it is a bit annoying. Some of the old pre-sculpt furry AVs can have render weights down below 15k. After an experience with an aircraft model, I’m beginning to think creators generally aren’t thinking. Some common features in furry AVs could be made optional. In a heavily loaded location, I feel a little guilty about having ears that twitch. And, generally, it looks good to cut back on flexi-prims in crowded locations.
I sometimes feel like a dangerous socialist, advocating that players have some consideration of others, but after the recent politics overdose, I think I am more of an anarchist.
LikeLike
Whether people are happy hearing about it or not, there is a lot of mesh content in Second Life that is poorly optimised, and can impact performance. There is also a lot of performance-degrading advice that’s been handed out (since well before mesh) which has become almost written as things that “must” be done to “improve” viewer performance (when the reverse is actually likely to be the case.
It’s hard to overcome things like this within the platform itself, given Second Life’s overall nature. However, Avatar Complexity may well encourage people to thing more closely about their creations and about the amount of items they “pile on” to their avatar and what could be reasonably trimmed without spoiling their overall look, as a part of the Avatar Complexity capability will send a report to people as to how many others around them are rendering their avatar as a solid colour. Whether this leads to upset of its own, remains to be seen – but the core aspect of Avatar Complexity, is that it gives each of us greater control over the performance of our viewers, and we get to determine how and what we see.
LikeLike
Reblogged this on Tamara and commented:
Very useful informations with tips and trick for improving your viewer performance!
LikeLike