Nordan 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.
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.
RENDERAUTOMUTEFUNCTIONS to 7 in order to experiment with RENDERAUTOMUTERENDERWEIGHTLIMITThe 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.
Inara Pey: Living in a Modemworld 
Interesting RenderAutoMute function. I wonder how this will impact with mesh. Consider a person who is wearing a full body alpha and an unclothed mesh avatar with the same number of vertices as the default avatar. Will they have a ‘0’ score, because its a 1 for 1 swap, or will they have some insanely high score – because it will decide they’re akin to two avatars?
Will this act to greatly discourage mesh clothing? Scultpy clothing? Both? Or complex system clothes (using 1024 textures for example)?
Will a person with mesh jeans that have 8 faces all using a 256 texture, and an alpha map… be more or less than a person with 1024 texture system jeans and a sculpty belt that has 1 face but at 1024 texture?
Or are my questions completely not relevant to how this is calculated?
LikeLike
I’m not sure what you’re getting at, so please excuse me if this reply misses the mark.
The RenderAutomuteRenderWeightlimit doesn’t alter the current ARW for any avatar, regardless of whether the avatar is full or partial mesh / sculpts or has no mesh at all. It is simply imposing a viewer-side limit on rendering avatars with very high ARWs, if the use so wishes to set such a limit.
LikeLike
Once people can choose to not render people with high ARWs, it suddenly becomes very very very important to make sure the ARW formula is being fairly determined – or a lot of people inworld are going to find themselves made invisible as suggested settings for that preference filter out to the community.
So I’m curious now to know how that setting treats the kinds of examples I gave.
LikeLiked by 1 person
I’ve no idea if ARW is going to be changed, but given that an avatar can have an ARW well into the red without necessarily going anywhere near mesh, I’m not sure that mesh enters into the discussion over possible ARW adjustments.
LikeLike
I think it would since wearing mesh makes your render weight higher. But it is very hard to have a render weight not in the red. I think what pussycat is getting at is that if everyone starts putting a cutoff limit and wearing say a mesh dress goes over it making your avatar appear solid colored is that going to be bad for everyone selling mesh. I think that the clothing layer stuff wont be affected greatly because there textures are always downsized to a smaller size when worn so they always have the same render weight I believe. IMO this could be really bad for mesh makers and by extension for the look of sl as a whole in the long run. Unless mesh makers learn to model more efficiently on the whole.
Then again maybe I’m not clearly understanding how the cut off limit is being calculated as it’s extremely confusing….which is going to be bad as well tbh if people start to use it without know what it does.
LikeLike
Oh, I’ve got the point Pussycat is making. My point is that 1024×1024 texture skins, 1024×1024 texture “fabrics” on layer clothing, 1024×1024 textures in eyes, on shoes, on accessories – they all already have a considerable impact, which can push ARW up into the 150K-200K mark (and well into the red, as you say) even without mesh, so there’s possibly a general discussion to be had, depending on how LL start tweaking things.
As to the current calculation, it is confusing, given there is no clear correlation between the current RenderAutoMuteRenderWeightLimit figure and ARW, a problem further exacerbated by the addition of some LOD factor added to the calculation. So, for example, not only does the 60,000 into the debug setting have no direct correlation to ARW as it is now (i.e. it is not equal to an ARW of 60,000), it is additionally weighted by an undefined LOD value such that the “actual” figure is around 90,000 – whatever that means.
However, the Lab has stressed they’re going to work to clean-up these ambiguity in the figures, and make whatever ends up being entered into whatever new UI element we get more directly related to ARW.
I think a part of the problem here is that things like the RenderAutoMute functions pre-date ARW (and indeed ARC), and are possibly hold-overs from something else entirely that was never completed in the viewer.
LikeLike
Yeah I seem to recall (been years…) that a big issue back in the day was people having tons of items that were linksets of sculpties. Say… an outfit of a belted jacket with buttons – and every button was a sculpt its own, each with a 1024 texture.
Mesh was supposed to be better for all of this than that or than say, a torus (which for reasons beyond my tech skill is supposed to be, from what I’ve read, horrible on the rendering engine).
The reality of Mesh is that some makers do a great job on keeping things optimized and efficient. And some can’t upload a flat plane without it being 100-land impact and a few thousand polygons (made up example).
I have a vague instinct that some items I own will ‘get me color zapped’ if I wear them after this… they’re the items that already slow down my FPS when I wear them… But my instinct might be off.
I think it would be a very good thing to introduce measures to get mesh content uploaders to be more conscious about optimization for ‘real time animated rendering’. But I predict a massive amount of drama and ‘LL is at it again’ accusations when that day arrives. Especially if this zaps some of the rapidly growing in popularity mesh bodies.
The easier it becomes to understand how it gets calculated – the easier it will be to avoid hitting whatever value the community starts recommending as a popular threshold to set. But it looks like thus far the answer is ‘not yet determined or even determinable’?
LikeLiked by 1 person
Is the formula by which it is currently calculated publicly available – so people can make preparations over which inventory items will have to get tossed, if any?
LikeLike
Not sure that will help. The formula that’s there today (which I’ve again tried to explain in my reply to Emily) is being re-worked by the Lab to make a clearer correlation with ARW and remove the current ambiguity. We probably actually need to see what has been done once there is a viewer available with the updated code. Hopefully, that will be a project viewer such that people can have a real go at kicking the tyres before things get set in tablets of stone.
LikeLiked by 1 person
i unchecked the avatar impostors box (meaning i always will see all avatars in range despite their number) since i got my latest vga.
But i use a lot the arw when sailing and i can tell that my avatar before changing to a fit mesh body was around 27000k (yellow) and that was a pretty good arw compared to most avatars (even if some that sail manage to go to less then 12000kb by wearing only their shape skin and a old (really) non sculpted hair from 2006).
Still overall, now that most sailors use fit mesh bodies, their arw is never higher then 50000kb.
Also lets say that most use also fit mesh feet and hands and for reasons unknown to me (perhaps the effect of seeing the hair floating with the wind?) they still use sculpted flexi hair and if some really increases arw is that.
I did several tests just by changing from mesh hair (And a must is to choose a good brand, not naming any, their is mesh hair and mesh hair!) to flexi and my arw always increased.
Now that i wear always a fit mesh body hands and feet (Again, not mentioning brands, the only one im aware that is copy/mod, enough to say is not the most used ones), my arw when using clothes via layers, never goes higher then 13000kb and is fully unscripted (the advantage of wearing a copy/ mod fit mesh body is that you can edit it and remove any not needed anymore scripts:)).
But sailors normally don’t wear to much clothes so on live music shows, where many try to go with their best outfits i still never see any arw higher then 200.000kb, even if full mesh.
My soul mate (that refuses to wear mesh but a full Free perm bare feet, still uses the same old sculp flexi hair from 2009 (but from an amazing Japanese creator that is not anymore in Sl) and does not uses ,mesh clothes, always keep her arw around 27000kb.
Even when she uses their old sculpted high heels that are made of 220 sculpts parts each, the arw never goes higher then 50.000kb
And as i told before,we don’t have the avatar impostors box checked, so guess that for us will not matter another debug setting and we know that all can see us inworld (if only for the im’s i get all days ;))
LikeLike