Avatar Rendering Complexity

[Theresa Tennyson]

---

Phil Deakins wrote:

I disagree. Thin clients are not viewers because they don't 'view' SL. Yes, thin clients can be written from scratch. There's nothing difficult about that. But I did mean

actual

viewers - those that 'view' SL. That that's why they are called viewers - because they view SL.

So I repeat -

nobody has made a viewer except LL. All the 3rd party ones are all LL viewers that have been modified.

Since you don't know of any, I am much more confident about that statement, simply because why would anyone reinvent the wheel when they don't have to? Why would anyone write a viewer from scratch when the entire code for such good viewers is freely available and modifiable to taste. It could be done, of course, but I don't think anyone has been silly enough to actually do it, and neither do you.

---

Even Lumiya, the Android Second LIfe viewer?

[Rhonda Huntress]

Thank Odin it's Freya's Day.

We can argue about anything here on the forums

[Madelaine McMasters]

---

Rhonda Huntress wrote:

Thank Odin it's Freya's Day.

We can argue about anything here on the forums

---

No we can't.

[Pamela Galli]

---

Madelaine McMasters wrote:

---

Rhonda Huntress wrote:

Thank Odin it's Freya's Day.

We can argue about anything here on the forums

---

No we can't.

---

:matte-motes-evil:

[Madelaine McMasters]

---

Pamela Galli wrote:

---

Madelaine McMasters wrote:

---

Rhonda Huntress wrote:

Thank Odin it's Freya's Day.

We can argue about anything here on the forums

---

No we can't.

---

     :matte-motes-evil:

 

---

 

[Torrie Mint]

Thank you very much

[Phil Deakins]

---

Theresa Tennyson wrote:

---

Phil Deakins wrote:

I disagree. Thin clients are not viewers because they don't 'view' SL. Yes, thin clients can be written from scratch. There's nothing difficult about that. But I did mean

actual

viewers - those that 'view' SL. That that's why they are called viewers - because they view SL.

So I repeat -

nobody has made a viewer except LL. All the 3rd party ones are all LL viewers that have been modified.

Since you don't know of any, I am much more confident about that statement, simply because why would anyone reinvent the wheel when they don't have to? Why would anyone write a viewer from scratch when the entire code for such good viewers is freely available and modifiable to taste. It could be done, of course, but I don't think anyone has been silly enough to actually do it, and neither do you.

---

Even Lumiya, the Android Second LIfe

viewer

?

---

I'm not familiar with that one. Who wrote it? Was it written from scratch by someone other that LL?, or did someone take the LL code and heavily modify it to work with Android? I've no idea. If someone wrote it from scratch, then I'll concede and one viewer wasn't written by LL, but not until I know the answer.

[Pamela Galli]

---

Madelaine McMasters wrote:

---

Pamela Galli wrote:

---

Madelaine McMasters wrote:

---

Rhonda Huntress wrote:

Thank Odin it's Freya's Day.

We can argue about anything here on the forums

---

No we can't.

---

     :matte-motes-evil:

 

---

 

---

☠ 

[Penny Patton]

---

Torrie Mint wrote:

Im with you I could care less to see how badly the labs hardware is running, we know its junk they dont need to keep rubbing it in.

---

I just want to address this comment and the conversation that has spun off of it because there's a lot of misunderstanding and misinformation being tossed around on all sides.

 Torrie's implication here is that SL runs so poorly because the hardware at LL is bad. Others have "corrected" this by claiming the reason is LL's code is bad. Still others are blaming the computers of other SL users. None of which are really true.

-----

Here's the short TL;DR version:

LL should have capped avatar draw weight from the beginning. They didn't, so content creators create really laggy content and casual SL users have no way of knowing that the content they're wearing is the source of so much lag. The only way to fix this is to get content creators to stop making laggy content.

LL is trying to do that by showing people how laggy their avatars are. This probably isn't the best way to do it because, again, they have no way of knowing what content is laggy and what isn't until after we've already bought it and seen what it does to our Draw Weight.

-----

Does that make sense? If not, here's the longer, more detailed explanation.

The main reason SL runs so poorly, and has such high hardware requirements, is that the content within SL (scripts, textures, models) lack optimization. By which I mean they use far more resources than they need.

We have mesh bodies and other 3D models that have way more polygons than they need to achieve the quality of their appearance, scripts that use sim processing resources unecessarily, and textures that bog down graphics hardware without actually adding any significant detail to the item they cover.

 The problem with avatars is that there's no cap on resource use. When you build on land in SL you're limited by the "Prim Limit" or "Land Impact" of the land. If you only have 100-500LI to work with, then every point counts, so content creators try to make everything they sell as low a point cost as possible. This is why we have gorgeous mesh furniture that only uses a single LI point. Why we have houses that cost 30LI instead of 300LI. The point restriction for land encourages content creators to optimize (their models at least, LL neglected to include texture use so that is wildly out of control).

 Since avatars have no such point limit, you can attach more polygons, textures and scripts to your avatar than you could rez in half a sim. You can literally walk around SL wearing more polygons than you'd find in the level map of a modern AAA videogame, slathered in over a gigabyte of textures. Some people in SL are doing exactly that, and are entirely unaware of it.

 All of this makes SL run more slowly, no matter how powerful your computer is.

 To be perfectly clear, optimizing content does not mean reducing its detail. The idea is to reduce the amount of rendering resources used while keeping the detail and quality.

 If you are a content creator, it's realitively easy to optimize what you make and sell. There are tools built into 3D modelling software to help, and just being smart about texture and script use can help you reduce memory and processing without sacrificing details or features. It's not a lot of work.

 I stress that it's easy for content creators because they need to be the ones encouraged to optimize. Even if you're an experienced content creator it is difficult, sometimes impossible, to modify content you've bought into being less laggy.

What LL has done by introducing this "Jellybabies" feature after more than a decade without any attempt to encourage content creators to optimize the avatar content they create is make the average user feel like they're being penalized for something out of their control. It's not like they can go to the marketplace and filter content by draw weight. They can't even see the draw weight until after they've bought the item and worn it. And that's if they even understand the significance of draw weight at all.

 Most don't, and to be honest there's no reason they should have to be concerned with something like content optimization. That's like a videogame developer selling an unoptimized game and telling their customers to optimize it themselves.

 How would I fix this problem if I were LL right now?

 Well, first, I'd try to reach out the community via the blog, quote of the day, and other channels to explain why low draw weights are important for everyone, that this is a tool meant to help people have a better experience.

 Second, I'd reach out to content creators and say "Look, Bento is coming out soon. We're going to tie new draw weight limits to avatars wearing Bento content. We're going to give them the tools to manage their draw weight, and we're giving you, the content creators, the tools to make low draw weight a selling point."

 How would that work?

 I'd put some sort of cap on avatar draw weight, say 50,000, but it would ONLY kick in if you attached an item that uses Bento features (or any other new content related features to come out in the future). If you detached that content you'd revert to no cap. So you could continue to use old, unoptimized content, just not with the new features going forward.

 Content reators would be made aware of this long before Bento actually released. Giving them time to start making low draw weight content, or advertise the draw weight of content they currently have out. This would work exactly how the change from "prims" to "land impact calculation" came about. You can still use old, sculpty content, but the moment you link it to mesh or try to use materials on it the LI cost goes up.

 I'd add a new option to Marketplace listings, allowing content creators to state the draw weight of their content, just like the prim count is currently listed. So you could could easily filter content by draw weight. If there's a way to select individual attachments and see their draw weight I'd add that, too. Anything to make it easy to manage draw weight.=

 This way, old, laggy content would be slowly phased out over time, rather than forcing people to confront their draw weight immediately, without any help or context.

 

[Qie Niangao]

---

Phil Deakins wrote:

---

Theresa Tennyson wrote:

---

Phil Deakins wrote:

[...] -

nobody has made a viewer except LL. All the 3rd party ones are all LL viewers that have been modified.

 [...]

---

Even Lumiya, the Android Second LIfe

viewer

?

---

I'm not familiar with that one. Who wrote it? Was it written from scratch by someone other that LL?, or did someone take the LL code and heavily modify it to work with Android? I've no idea. If someone wrote it from scratch, then I'll concede and one viewer wasn't written by LL, but not until I know the answer.

---

I can't speak definitively, but as a practical matter, the author must have re-used most of the rendering pipeline -- it's just too fantastically complex to re-implement from scratch. But the product is an impressively stark departure from LL's viewer, and much more ambitious in vision and scope than any of the third party graphical viewers that run on conventional platforms.

It's really necessary to try it out to see how innovative an SL UI can be. To me, it's the exception that proves the rule: all the other TPVs I've tried are so similar to LL's that it would be difficult to justify all the work that went into opensourcing the code.*

(Note, though, that I haven't tried them all. In particular, I suspect CtrlAltStudio's Rift viewer may have done some interesting VR UI work, I just don't have the interest in current generation VR to find out.) 

[Qie Niangao]

---

HoppytheWanderer wrote:

It would be nice, I don't really care if people with their performance slider set to low can't render me.

One thing I found odd is that an item consisting of mostly invisible objects had a very high rendering complexity. Shouldn't something like that have a rendering cost close to zero since there almost nothing to render?

---

You'd think. I remember sitting in a Nyx Linden office hour where they mumbled something about an objective of doing exactly that: not rendering full-alpha stuff. Pretty sure they never got 'round to that, because as you observe, stuff gets the same complexity score whether it's visible or not. 

I'm too lazy to test, but it would be interesting to see whether alpha-masking decreased the complexity score compared to alpha-blending. It's many times easier to render, but I couldn't even guess whether the score reflects it. If it does, it would be one quick and easy savings.

(The law of unintended consequences made this particular feature backfire spectacularly for non-attached content: Try switching from alpha-blending to alpha-masking on a legacy torus or sculpty. Ithat makes it much easier to render but because it swaps to Mesh accounting, it gets scored hundreds of times higher land impact.)

[ChinRey]

---

Salomena Askari wrote:

How can i hide thise message.. ? i want see that..cause a bug ? when i change sim it show me again and again..

---

Unsurprisingly, this discussion got a bit out of hand. Here's a reply to the original question as I understood it...

Yes, there is a bug that causes that alert to pop up again, and again and again, sometimes when you move to a different sim, sometimes with no apprent reason at all. It even gives faulty messages. About an hour or two ago I got an alert saying "Your avatar weight is 56314. You will not be seen by half the avatars in your vicinity". Ten minutes later I got a new alert saying: "Your avatar weight is 56314. You will be render by all avatars in your vicinity". Hopefully they'll fix that bug soon.

You should think twice before switching it off though. Despite that flaw, it is important info and you really need to know how much you are lagging down your own and other people's viewers.

[ChinRey]

---

wherorangi wrote:

the rendering engine is 100% LL code in all desktop viewers. As is the data transport, storage and connectivity engines

---

 I don't know if this is correct but according to Beq Janus (and she usually knows what she's talking about) there used to be 3rd party viewers with alternative rendering engines but that changed after the Emerald scandal and LL does no longer allow that.

My impression is that although the SL rendering engine is far from ideal, it's not that bad either. I've tried to make scenes with a render load aproximating what you'd find in a professionally made virtual environment and the performance seem to be slightly worse than what we should expect but not critically so. I think there has been a gradual detrioration over time. When I revisit scenes that haven't changed for years, they seem to be slightly slower to load now than they used to. Not sure what that means and it seems more like a caching and/or data transfer issue than actual rendering performance.

But in any case, the lag caused by inefficient software is minor compared to the lag caused by inefficient content.

[ChinRey]

Wow! Penny's post sums up a lot. It should be mandatory reading for everybody in SL! Thank you, Penny!

 

One comment though:

Although the situation for rezzed objects isn't nearly as bad as for avatars and worn objects, it's far from rosy red. For a start textures don't count towards land impact and they contribute far more to the overall lag level than geometry does. Also, with mesh it is possible to cheat with land impact, You just butcher the LOD models and tell the users they have to increase their RenderVolumeLODFactor. The situation here is so bad that Firestorm actually has bloated LOD factor as default.

Although avatar render weight is the biggest lag issue overall, it is not hard to find examples of SL scenes where the combination of texture abuse and poor LOD models adds far more render lag than a dozen heavy avatars would. Ironically, it's very often content creators who regard themselves - and successfully promote themselves as - top notch who make those mistakes. The philosophy seems to be that it has to be top quality if only the people who can afford the most expensive gpus are able to see it properly. (and the very best works are of course the ones that'll bring even a GeForce GTX 1080 to its knees...)

[Theresa Tennyson]

---

Qie Niangao wrote:

---

HoppytheWanderer wrote:

It would be nice, I don't really care if people with their performance slider set to low can't render me.

One thing I found odd is that an item consisting of mostly invisible objects had a very high rendering complexity. Shouldn't something like that have a rendering cost close to zero since there almost nothing to render?

---

You'd think. I remember sitting in a Nyx Linden office hour where they mumbled something about an objective of doing exactly that: not rendering full-alpha stuff. Pretty sure they never got 'round to that, because as you observe, stuff gets the same complexity score whether it's visible or not. 

I'm too lazy to test, but it would be interesting to see whether alpha-masking decreased the complexity score compared to alpha-blending. It's many times easier to render, but I couldn't even guess whether the score reflects it. If it does, it would be one quick and easy savings.

(The law of unintended consequences made this particular feature backfire spectacularly for non-attached content: Try switching from alpha-blending to alpha-masking on a legacy torus or sculpty. Ithat makes it much 

easier

to render but because it swaps to Mesh accounting, it gets scored hundreds of times

higher

land impact.)

---

Alpha masking does eliminate the multiplier for alpha textures from the ARC equation and makes it so an object doesn't appear when "highlight transparent" is selected. There is some witchcraft that can be done with mesh that allows something like a Catwa head with extreme amounts of geometry which is normally invisible to not have that geometry counted for ARC purposes but it looks like you can't have a legacy object with no texture at all.

As far as as the land impact of sculpts and tori: Sculpts will no more than double in land impact because of the increase in download weight with new accounting. Tori will increase dramatically if their physics type is "prim", double if it's "convex hull" and stay the same as their legacy score if their physics type is "none."

[Theresa Tennyson]

---

ChinRey wrote:

---

wherorangi wrote:

the rendering engine is 100% LL code in all desktop viewers. As is the data transport, storage and connectivity engines

---

 I don't know if this is correct but according to Beq Janus (and she usually knows what she's talking about) there used to be 3rd party viewers with alternative rendering engines but that changed after the Emerald scandal and LL does no longer allow that.

My impression is that although the SL rendering engine is far from ideal, it's not that bad either. I've tried to make scenes with a render load aproximating what you'd find in a professionally made virtual environment and the performance seem to be slightly worse than what we should expect but not critically so. I think there has been a gradual detrioration over time. When I revisit scenes that haven't changed for years,

they seem to be slightly slower to load now than they used to. Not sure what that means and it seems more like a caching and/or data transfer issue than actual rendering performance.

But in any case, the lag caused by inefficient software is minor compared to the lag caused by inefficient content.

---

Textures are now cached on a series of content-delivery server nodes all over the world. If any given texture is on your nearest node it will load faster than previously, but if it isn't it will load slower until it's in your local node's cache.

[wherorangi]

---

ChinRey wrote:

---

wherorangi wrote:

the rendering engine is 100% LL code in all desktop viewers. As is the data transport, storage and connectivity engines

---

 I don't know if this is correct but according to Beq Janus (and she usually knows what she's talking about) there used to be 3rd party viewers with alternative rendering engines but that changed after the Emerald scandal and LL does no longer allow that

---

yes that happened. Some early TPVs started to add on things like extra and multi attachment points and stuff. Which could only render properly for the users of those TPVs. For others (incl. LL viewer users) the stuff would just be a mess of pixels on their screens

LL knock that all on the head, bc their view was that all SL users should be able to render everything iin their own used viewers similarly, regardless of source. So the TPV program (since Oz Linden came) has been far more collaborative and structured than it was previous

+

ps. Geenz Spad was mention earlier [Theresa] about the work on materials. That was a major contrib to the rendering engine. So I just acknowledge that as well here

 

eta; [Theresa]

[Gayngel]

I JellyDolled everyone except you baby:heart:

[SugareeRose]

No one seems to know how to turn that thing off. It's  annoying!  The techie side is interesting, but that  Avatar Complexity Rendering pop up is annoying as hell.  So, how do you turn it off?   I've gone back to the ealier version of Firestorm until I  can disable it.

Thanks for reading my rant.

[wherorangi]

---

SugareeRose wrote:

No one seems to know how to turn that thing off

---

jjccc posted the fix earlier in the thread. I just repost here for you

+

To turn off the Complexity message notifications, go to Show Debug Settings in Advanced menu

find debug entry: ShowMyComplexityChanges, and set  to 0

if you cant see the Advanced menu then: Ctrl+Alt+Shift+D to toggle/show/hide the menu

[Rhonda Huntress]

---

SugareeRose wrote:

No one seems to know how to turn that thing off.

---

It was posted 3 times in this thread already plus another time after you asked.

[Phil Deakins]

---

Qie Niangao wrote:

---

Phil Deakins wrote:

---

Theresa Tennyson wrote:

---

Phil Deakins wrote:

[...] -

nobody has made a viewer except LL. All the 3rd party ones are all LL viewers that have been modified.

 [...]

---

Even Lumiya, the Android Second LIfe

viewer

?

---

I'm not familiar with that one. Who wrote it? Was it written from scratch by someone other that LL?, or did someone take the LL code and heavily modify it to work with Android? I've no idea. If someone wrote it from scratch, then I'll concede and one viewer wasn't written by LL, but not until I know the answer.

---

I can't speak definitively, but as a practical matter, the author must have re-used most of the rendering pipeline -- it's just too fantastically complex to re-implement from scratch. But the product is an impressively stark departure from LL's viewer, and much more ambitious in vision and scope than any of the third party graphical viewers that run on conventional platforms.

It's really necessary to try it out to see how innovative an SL UI can be. To me, it's the exception that proves the rule: all the other TPVs I've tried are so similar to LL's that it would be difficult to justify all the work that went into opensourcing the code.*

(Note, though, that I haven't tried them all. In particular, I suspect CtrlAltStudio's Rift viewer may have done some interesting VR UI work, I just don't have the interest in current generation VR to find out.) 

---

Thank you for that, Qie. Theresa has posted in this thread since I asked the question, but hasn't offered an answer, so it appears that she doesn't know the answer, although, to be fair, she only asked about Lumiya. She didn't offer it as an example of a viewer that LL didn't fundamentally write.

[Maxine Kohime]

Thats bad, I spent a fortune on my Avatar, looking good is the most important thing to me. So I fear now I made LL and other rich with my money and can throw away now lots ot it because of that?!

Who can I sue to get my money back?

[Rhonda Huntress]

Maxine, do you have any newer shots than what you have on the flicker link from your profile?  I don't see anything there that would be ARC heavy to the point of being worried about it.

[Anita61 Anatine]

So what? You can still look as good as you want and friends can choose to render you fully if they want to .Apart from a general setting there's also a per avatar setting.

If your avatar compexity is very high I may choose to render you as jellydoll becuase I do not want you lagging me.

It's all about choices and this feature helps you make those choices! It's a dynamic setting, if I go to a full shopping event I choose to set my slider as low as possible, I'm there to shop and don't need to see all the other avatars. I put my slider higher if I'm at a place with less avatars. 

If you want to complain at all, go to the creators who made the items that make your complexity count way up and ask them if they can maybe remake their items. Or just embrace the new feature and be greatfull you now have the power to reduce lag!