Performance impact questions

[Icarus Lytton]

Hello all of you!

I'm a long term builder in SL but I've always been hanging in the dark a bit when it came to what affects performance. Because of the way Avatars can have such a huge impact on performance (by wearing badly made and/or prim/PE/script heavy elements) it's often hard to link viewer lag to any specific element.

I've just created a new hangout on a new sim - size 16000sqm. Personally I have a very powerful viewer and can turn on all the bells and whistles and still keep a good framerate but for some of the visitors the hangout is unbearably laggy whenever just a few avatars are present.

I've tried experimenting but the results aren't really clear so I decided to come to this forum to see if any of you could help me out.

My questions are basically this:

- what are the main causes of viewer lag (besides the obvious elements such as particle count and view distance and other viewer settings)? I suspect alpha textures contribute a great deal

- In games, they design areas in such a way that you can only ever see a certain amount of polygons at once to avoid performance hits. How would you do this in SL? Is placing a large prim going to stop the viewer from rendering the items behind it? Does it work with sculpties as well? Or do you have to use actual raised land for this to work? From my experience, SL seems to not give a **bleep** what you actually see but still renders it or part of it at least - or is there a trick for this?

I hope someone can give a clear answer because I couldn't find any topic on this (strangely enough) despite it being quite a big issue for building - especially with all the high-detail and low-prim mesh abound (which seriously made lag worse).

[arton Rotaru]

Yeah, avatars are most likely still the worst offenders regarding performance. Each one of them may work ok for oneself, but as soon as they meet up with a couple of similar heavy avatars, things go haywire.

If you pull up the the Scene Statistics display (Develop > Consoles > Scene Statistics), you can see the triangles visible from objects, and from avatar attachments. If you have, lets say, 500 ktris from the environment visible, and 2.5 million tris from attachments, you know that it wouldn't help that much to work on the environment alone. There would be still 2.5 million tris left even in an empty space.

Also, in SL there are usually way to many objects with way too many unique textures, on too little spaces. Which can make even high end GPUs look poor, due to the CPU overhead by too many draw calls. Too many alpha blending textures, too many local lights, to many of everything....

Object occlusion works to some degree, but not as much as one would expect, at least from what I can see. In other game engines there is the abilltiy to mark objects as occludees, and others as occluders, to make sure hidden objects won't render at all. As well as they can make use of texture atlases, and combining multiple objects into one, with just one material to reduce the number of draw calls etc pp..

I'm afraid there isn't that much you can do in SL, besides stripping down the place significantly. Fewer objects, with less unique textures, setting alpha plants to alpha masking, fewer lights, and particles etc..

But you would still have to deal with heavy avatars.

 

[Perrie Juran]

---

arton Rotaru wrote:

Yeah, avatars are most likely still the worst offenders regarding performance. Each one of them may work ok for oneself, but as soon as they meet up with a couple of similar heavy avatars, things go haywire.

If you pull up the the Scene Statistics display (Develop > Consoles > Scene Statistics), you can see the triangles visible from objects, and from avatar attachments. If you have, lets say, 500 ktris from the environment visible, and 2.5 million tris from attachments, you know that it wouldn't help that much to work on the environment alone. There would be still 2.5 million tris left even in an empty space.

 

---

Avatars are certainly the worst offenders.  And since the advent of MESH, the Draw Weight for Avatars on average has gone up.  Way up.

I certainly don't want to see a return of the old ARC Wars, when it was called Avatar Render Cost.  It could be a real drama fest at times.  People would get called out in public at clubs for being over weight.  But people need to realise that sometimes they are their own walking lag bombs.

I am of the firm opinion that listing the Render Weight for any worn item should be mandatory in the Market Place.  No different than Land Impact for rezzed objects. 

</soap box>

 

[arton Rotaru]

Yeah no ARC wars please. If I remember correctly there has been Linden talk recently, about auto de-rendering heavy avatars along with a message like, 5 out of 10 avatars see a simplified version of your avatar. To make people aware that they aren't as pretty for everyone, as they think they are.  :matte-motes-smitten:

[Perrie Juran]

---

arton Rotaru wrote:

Yeah no ARC wars please. If I remember correctly there has been Linden talk recently, about auto de-rendering heavy avatars along with a message like, 5 out of 10 avatars see a simplified version of your avatar. To make people aware that they aren't as pretty for everyone, as they think they are.  :matte-motes-smitten:

---

I take advantage of the derender feature in Firestorm at crowded clubs.

I don't like doing it but I suffer greatly from the texture memory crashes and this at least helps alleviate it for me.

The more MESH clothes I am around the faster and more likely I am to crash.

I know some of you creators labour very hard to optimise your creations, but sadly I think you are in a minority.  Too many just want to take the money and run.

Regarding LL, I have for a very long time maintained that they need to be more proactive and agressive in educating people.  They need to be the ones to take the lead on it.  Big time.

[Jenni Darkwatch]

There's an auto-derender function in the SL Viewer, yes. I do not think the function is exposed in the UI, but it's there and works quite nicely. Any avi hit by it just flat out disappears from view, which works fine for me

[arton Rotaru]

---

Perrie Juran wrote:

Regarding LL, I have for a very long time maintained that they need to be more proactive and agressive in educating people.  They need to be the ones to take the lead on it.  Big time.

---

Yup, I also would like to see LL play a bigger role in this field.

[SaraCarena]

---

arton Rotaru wrote:

......... If I remember correctly there has been Linden talk recently, about auto de-rendering heavy avatars along with a message like, 5 out of 10 avatars see a simplified version of your avatar. To make people aware that they aren't as pretty for everyone, as they think they are.  :matte-motes-smitten:

---

Yes auto de-rendering within settable limits based on arc/arw plus the option to see how many nearby avatars are or are not rendering your avatar is in development and was discussed at TPV meeting 19/12/14.

between 20.00 mins and 40.00 mins

[arton Rotaru]

Thanks! :matte-motes-smile:

[SaraCarena]

I`ve found the debugs in sl viewer which I think you`re referring to;

 

RenderAutoMuteByteLimit Maximum bytes of attachments before an avatar is rendered as a simple impostor (0 for no limit)

RenderAutoMuteFunctions Developing feature to render some avatars using simple impostors or colored silhouettes. (Set to 7 for all functionality)

RenderAutoMuteLogging Show extra information in viewer logs about avatar rendering costs

RenderAutoMuteRenderWeightLimit Maximum render weight before an avatar is rendered as a simple impostor (0 to not use this limit)

RenderAutoMuteSurfaceAreaLimit Maximum surface area of attachments before an avatar is rendered as a simple impostor (0 to not use this limit)

 

They`re in Firestorm, Alchemy and exposed in the ui in Black Dragon too, but I get av imposters in the form of coloured silhouettes rather than they disappear completely. Not keen on sihlouettes or 2d sprites and like as many 3d av`s on screen as possible but I`m interested to know how to make them disappear completely.