Details

    • Type: New Feature
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Phoenix Firestorm Next
    • Component/s: Performance
    • Labels:
      None
    • Environment:
    • SL Avatar Name:
      Chalice Yao
    • Patch attached:
      Patch attached
    • Reported In:
      Firestorm 5.0.7.52912 Release

      Description

      Heya! Long time!

      I have a little patch for FireStorm that consists of a couple of features I think SL should have had eons ago.

      • It allows people to get an easy overview of an avatar's VRAM usage - it gets displayed in the tag, just like Render Weight does. Also, like Render Weight, you are able to limit the visibility of avatars that are over a certain amount of VRAM. Many many people have absolutely no idea how much RAM their avatar and attachments are using- they are oblivious to the massive bloat many creations actually put on them. This will help, a lot.
      • The second component is the ability to see the VRAM, triangles and vertices (properly calculated) of any selected object in an inspect window, including totals and broken down by link in the linkset, including multiple selected objects. This allows for quick identification of the efficiency of an item, without having to take measures that would otherwise not be ToS compliant. This properly iterates over the individual links and shows proper totals, unlike the obscure and almost not-known render debug display or even somewhat stowed away simple FS VRAM info.

      I need to stress that this info is kind of important - especially the Avatar and Object VRAM totals and by-link-breakups. It has become pretty much one of the top performance killers in SL over the last years - not only clogging up people's network lines on TP to new places, downloading potentially hundreds of megabytes of data per avatar (Which is just horrible for metered lines as well..), but also clogging the cache and sending SL's less-than-stellar texture cache handling into an endless churn. And easily seeing how much texture memory an Avatar or Object uses, has been a really...really big eye opener when it comes to a lot of content where it has been rather obscure and somewhat hidden away before.
      Consider the fact that lots and lots of avatars out there easily use over a hundred, sometimes several hundreds of MB of textures. Way, way too much content - be it attachments, buildings or what have you - simply are a torrent of 1024's. And the consumers don't even know or are aware of the insane memory bloat. Now consider what happens at places where lots of avatars meet.

      Please take this patch into consideration and inclusion without changing the pre-defined defaults for jellybabying - they are quite sane at over a hundred MBs per avatar, but can of course be adjusted to need. This overall set of features is supposed to help improve performance, but even more importantly to make people aware - consumers as well as creators - of the efficiency of items.

      Obviously basic information like that should have been in SL from the start. The grid might have become a much more content-efficient place akin to other game-ish environments out there.

      Credits for this go to me, as well as Arcane Portal who's been a driving force and co-coder behind this.

        Activity

        Hide
        jessica_lyon Jessica Lyon added a comment -

        Chalice? There's a good possibility LL may really appreciate this. Have you submitted it to them?

        Show
        jessica_lyon Jessica Lyon added a comment - Chalice? There's a good possibility LL may really appreciate this. Have you submitted it to them?
        Hide
        chalice yao Chalice Yao added a comment -

        Not yet, but now we're considering it!

        Show
        chalice yao Chalice Yao added a comment - Not yet, but now we're considering it!
        Hide
        jessica_lyon Jessica Lyon added a comment -

        Please consider it! There's a fairly good chance they'll take it, and if LL adopt it will be even better. There is a chance they could consider this falling under the "Shared experience" policy. I'll talk to Oz about it this week.

        Show
        jessica_lyon Jessica Lyon added a comment - Please consider it! There's a fairly good chance they'll take it, and if LL adopt it will be even better. There is a chance they could consider this falling under the "Shared experience" policy. I'll talk to Oz about it this week.
        Hide
        ansariel.hiller Ansariel Hiller added a comment - - edited

        My personal opinion about this: I like the way to easily see how much VRAM is used up by textures, but did you check how much performance impact measuring the texture sizes per avatar is going to impose? On the other hand, I don't think installing a feature to show avatars as impostors because of their amount of texture memory on our own is a good idea. First, the proposed values are simply unrealistic and might work for avatars being stuck in 2012 - people wearing Catwa mesh heads would be impostored to everyone using the low graphics defaults because the head alone is exceeding that limit. This would lead to second: Creators distributing notecards saying "latest Firestorm is broken - fix it by cranking up the value of debug xyz to 1000000" and not helping anything at all - let's just call it the RenderVolumeLODFactor paradoxon. And third: How does this help reducing content not worn by avatars, like the usual deco stuff coming with 4MB textures for the tiniest bits?

        This doesn't mean I'm against reducing the inflationary use of high res textures for things it's completely unnecessary for. But I think this will just lead to a) Firestorm being perceived adding some "stupid" feature to screw users and creators and b) the resulting drama because of it. It would be much much better if LL adds this as an official feature, so it is perceived as an official suggestion/guideline/whatever and not Firestorm trying to impose arbitrary limits on users.

        Show
        ansariel.hiller Ansariel Hiller added a comment - - edited My personal opinion about this: I like the way to easily see how much VRAM is used up by textures, but did you check how much performance impact measuring the texture sizes per avatar is going to impose? On the other hand, I don't think installing a feature to show avatars as impostors because of their amount of texture memory on our own is a good idea. First, the proposed values are simply unrealistic and might work for avatars being stuck in 2012 - people wearing Catwa mesh heads would be impostored to everyone using the low graphics defaults because the head alone is exceeding that limit. This would lead to second: Creators distributing notecards saying "latest Firestorm is broken - fix it by cranking up the value of debug xyz to 1000000" and not helping anything at all - let's just call it the RenderVolumeLODFactor paradoxon. And third: How does this help reducing content not worn by avatars, like the usual deco stuff coming with 4MB textures for the tiniest bits? This doesn't mean I'm against reducing the inflationary use of high res textures for things it's completely unnecessary for. But I think this will just lead to a) Firestorm being perceived adding some "stupid" feature to screw users and creators and b) the resulting drama because of it. It would be much much better if LL adds this as an official feature, so it is perceived as an official suggestion/guideline/whatever and not Firestorm trying to impose arbitrary limits on users.
        Hide
        pennypatton Penny Patton added a comment -

        @Ansariel

        You're conflating unoptimized with quality. Higher VRAM usage does not mean your content looks any better. If you are wearing well made, optimized content it is easy to have a gorgeous, highly detailed avatar while coming in well below the proposed value.

        The reason content such as the Catwa heads use so much VRAM is because they aren't optimized well. And they're not optimized well because Second Life has never done anything to discourage unoptimized content. Making this problem visible, encouraging optimization and providing the tools to help people do it, all seem to be the point of this feature. How can it help reduce environmental content? Reading the description, it seems to include the ability to show the VRAM usage of any selected object, worn or in world, which would be incredibly useful for both regular users and content creators alike.

        I do think you're absolutely right that if this feature were to be rolled out with no fanfare, people would not understand the point of it and probably attempt to just disable it like you say. Having a discussion on how best to roll this feature out is, I believe, time better spent than hoping LL will take it on. With that in mind, I suggest not releasing this feature right away, and instead telling people it is coming, why it is coming, and providing both content creators and users alike with tips on how they can reduce the VRAM use of their own avatars before the feature is released.

        A version of Firestorm with the feature could be distributed as an optional download in the meantime, along with tips and suggestions on optimizing content, so that content creators can get a feel for how to make their own content ready ahead of time.

        Another option could be to initially roll out a version of the feature which simply allows you to see the VRAM on avatars with the jelly doll feature turned off by default. This would allow users to take advantage of the jelly doll feature for high-VRAM avatars if they choose to, but not inconvenience more casual SL users and those of us not quite ready to give up our Catwa heads before Catwa has had a chance to release an optimized version.

        Optimized content is only a plus. There is no downside to encouraging optimization.

        Show
        pennypatton Penny Patton added a comment - @Ansariel You're conflating unoptimized with quality. Higher VRAM usage does not mean your content looks any better. If you are wearing well made, optimized content it is easy to have a gorgeous, highly detailed avatar while coming in well below the proposed value. The reason content such as the Catwa heads use so much VRAM is because they aren't optimized well. And they're not optimized well because Second Life has never done anything to discourage unoptimized content. Making this problem visible, encouraging optimization and providing the tools to help people do it, all seem to be the point of this feature. How can it help reduce environmental content? Reading the description, it seems to include the ability to show the VRAM usage of any selected object, worn or in world, which would be incredibly useful for both regular users and content creators alike. I do think you're absolutely right that if this feature were to be rolled out with no fanfare, people would not understand the point of it and probably attempt to just disable it like you say. Having a discussion on how best to roll this feature out is, I believe, time better spent than hoping LL will take it on. With that in mind, I suggest not releasing this feature right away, and instead telling people it is coming, why it is coming, and providing both content creators and users alike with tips on how they can reduce the VRAM use of their own avatars before the feature is released. A version of Firestorm with the feature could be distributed as an optional download in the meantime, along with tips and suggestions on optimizing content, so that content creators can get a feel for how to make their own content ready ahead of time. Another option could be to initially roll out a version of the feature which simply allows you to see the VRAM on avatars with the jelly doll feature turned off by default. This would allow users to take advantage of the jelly doll feature for high-VRAM avatars if they choose to, but not inconvenience more casual SL users and those of us not quite ready to give up our Catwa heads before Catwa has had a chance to release an optimized version. Optimized content is only a plus. There is no downside to encouraging optimization.
        Hide
        ansariel.hiller Ansariel Hiller added a comment -

        I am not mixing things up here nor did I say unoptimized, high res (and as a result high VRAM) consuming textures are better. As I have written I am all for reducing the inflationary amount of high res textures for every tiny bit. But I am against adding this feature without the support of LL as it will just create drama as "Firestorm is forcing us to create low quality products" reactions. Even more if the proposed (arbitrary) limits will instantly render a high amount of people as jelly dolls - just to prove some point.

        Show
        ansariel.hiller Ansariel Hiller added a comment - I am not mixing things up here nor did I say unoptimized, high res (and as a result high VRAM) consuming textures are better. As I have written I am all for reducing the inflationary amount of high res textures for every tiny bit. But I am against adding this feature without the support of LL as it will just create drama as "Firestorm is forcing us to create low quality products" reactions. Even more if the proposed (arbitrary) limits will instantly render a high amount of people as jelly dolls - just to prove some point.
        Hide
        pennypatton Penny Patton added a comment -

        Your comment that the proposed jelly doll values were "unrealistic" and might only work for "avatars being stuck in 2012" seemed to suggest you believed only older content could have lower VRAM usage. I apologize if that is not what you meant.

        "As I have written I am all for reducing the inflationary amount of high res textures for every tiny bit. But I am against adding this feature without the support of LL as it will just create drama as "Firestorm is forcing us to create low quality products" reactions. Even more if the proposed (arbitrary) limits will instantly render a high amount of people as jelly dolls - just to prove some point."

        Waiting on LL to do something reasonable has never been a good option and the derender feature is offered for more practical purposes than to simply 'prove some point' (some of us do enjoy good framerates and the ability to enjoy higher graphics settings in SL), but again I do agree that if this feature were just rolled out tomorrow as-is there would be drama because people would not understand why they were being derendered. That is why I said as much and offered several solutions to circumvent the drama before it even begins. I'm sure everyone would be open to hearing more ideas before determining how to proceed.

        Show
        pennypatton Penny Patton added a comment - Your comment that the proposed jelly doll values were "unrealistic" and might only work for "avatars being stuck in 2012" seemed to suggest you believed only older content could have lower VRAM usage. I apologize if that is not what you meant. "As I have written I am all for reducing the inflationary amount of high res textures for every tiny bit. But I am against adding this feature without the support of LL as it will just create drama as "Firestorm is forcing us to create low quality products" reactions. Even more if the proposed (arbitrary) limits will instantly render a high amount of people as jelly dolls - just to prove some point." Waiting on LL to do something reasonable has never been a good option and the derender feature is offered for more practical purposes than to simply 'prove some point' (some of us do enjoy good framerates and the ability to enjoy higher graphics settings in SL), but again I do agree that if this feature were just rolled out tomorrow as-is there would be drama because people would not understand why they were being derendered. That is why I said as much and offered several solutions to circumvent the drama before it even begins. I'm sure everyone would be open to hearing more ideas before determining how to proceed.
        Hide
        miro.collas Miro Collas added a comment -

        I'll offer a support perspective, if I may, based on the existing jellydolls (complexity).

        The overwhelming majority of users want jellydolls gone, so they crank the setting up to "No limit". They see it not as a feature, but an annoyance, even a bug. We've even gotten abuse over it.

        Some small percentage will take note when it is explained, most don't. Further, a surprisingly large number (well, perhaps not surprising at all, really) actually believe that jellydolls add to lag, rather than mitigate it.

        Ansariel is correct that makers would start telling people to go to debug settings - as already happens with LOD: some creators tell their customers to set it to 10. [facepalm]

        As for waiting for LL to do this, see Jess' post above.

        This idea is great for those who have some understanding of how SL works. The problem is, the vast majority don't. And of those, a significant percentage don't want to. They just want everything to look pretty, work well, so they can have fun, and not ever think of settings. And if you think about it, that isn't unreasonable.

        In my view, if this is implemented, it should be off by default. Or at the very least, default values should be very generous such that existing content (eg Catwa, etc) won't trigger jellies. Those who know, can then tweak values as they like, while the majority would see little to no change.

        Show
        miro.collas Miro Collas added a comment - I'll offer a support perspective, if I may, based on the existing jellydolls (complexity). The overwhelming majority of users want jellydolls gone, so they crank the setting up to "No limit". They see it not as a feature, but an annoyance, even a bug. We've even gotten abuse over it. Some small percentage will take note when it is explained, most don't. Further, a surprisingly large number (well, perhaps not surprising at all, really) actually believe that jellydolls add to lag, rather than mitigate it. Ansariel is correct that makers would start telling people to go to debug settings - as already happens with LOD: some creators tell their customers to set it to 10. [facepalm] As for waiting for LL to do this, see Jess' post above. This idea is great for those who have some understanding of how SL works. The problem is, the vast majority don't. And of those, a significant percentage don't want to. They just want everything to look pretty, work well, so they can have fun, and not ever think of settings. And if you think about it, that isn't unreasonable. In my view, if this is implemented, it should be off by default. Or at the very least, default values should be very generous such that existing content (eg Catwa, etc) won't trigger jellies. Those who know, can then tweak values as they like, while the majority would see little to no change.
        Hide
        pennypatton Penny Patton added a comment -

        When the Jelly Dolls feature first rolled out most avatars I encountered were above the 120k threshold. These days I tend to keep my draw weight cap at 80k and yet I see fewer jelly dolls.

        Sure, a lot of users don't like the draw weight cap and go out of their way to disable it, but it seems to me that, on the whole, it has had a positive impact on avatar draw weights.

        I'm not saying it has solved the problem of high draw weight avatars entirely, only that it has had a generally positive effect when all is said and done, and I believe if we're going to point at the uproar the jelly dolls feature caused when it first released we need to keep this outcome in mind to give us proper perspective. Sometimes to effect a positive change you need to rock the boat and upset some people.

        Show
        pennypatton Penny Patton added a comment - When the Jelly Dolls feature first rolled out most avatars I encountered were above the 120k threshold. These days I tend to keep my draw weight cap at 80k and yet I see fewer jelly dolls. Sure, a lot of users don't like the draw weight cap and go out of their way to disable it, but it seems to me that, on the whole, it has had a positive impact on avatar draw weights. I'm not saying it has solved the problem of high draw weight avatars entirely, only that it has had a generally positive effect when all is said and done, and I believe if we're going to point at the uproar the jelly dolls feature caused when it first released we need to keep this outcome in mind to give us proper perspective. Sometimes to effect a positive change you need to rock the boat and upset some people.
        Hide
        miro.collas Miro Collas added a comment -

        Perhaps, yes. But anyone who pushes low defaults has to also be willing to do a week (at least!) in support and take the ensuing abuse.

        In case it wasn't clear, my reply wasn't for or against the proposed feature itself. Rather, I am addressing defaults. In summary, defaults should be such that most people don't notice that the feature has been introduced.

        Now if I were to offer an opinion on the feature itself, I would say, personally, I don't see the need for it. But that's me. I cannot speak for all of SL. I do agree that it would be much better if LL adopted it first.

        Show
        miro.collas Miro Collas added a comment - Perhaps, yes. But anyone who pushes low defaults has to also be willing to do a week (at least!) in support and take the ensuing abuse. In case it wasn't clear, my reply wasn't for or against the proposed feature itself. Rather, I am addressing defaults. In summary, defaults should be such that most people don't notice that the feature has been introduced. Now if I were to offer an opinion on the feature itself, I would say, personally, I don't see the need for it. But that's me. I cannot speak for all of SL. I do agree that it would be much better if LL adopted it first.
        Hide
        beqphoenixjira Beq Janus added a comment -

        More information is a good thing.

        One of the reasons I have added the Mesh Information panel and the "LOD view" in the forthcoming release is to give users a chance to look at the #triangles and what the LODs look like, before they buy. It is truly targetted at builders of course but that is a nice side-effect. It doesn't help at all with stuff from MP. The same applies to the physics shape view, it is a tool that allows you to understand a little more and answer some of the "why?" questions. Will most users understand enough to use it? probably not, but just a tiny few more IMing a creator to tell them "I didn't buy your X because you skimped on the LOD models and the physics was crap" might be a trickle to start eroding the mentality of lazy design.

        The information presented here is excellent, but as Miro has noted, if we default it such that Catwa heads (the most popular in SL at present) don't show right is just going to annoy people into hiding it.

        We've spent quite a lot of time sending things to Oz relating to how broken things are. The fact that you can easily game the LOD with rigged mesh, a problem exacerbated with Animesh, and which further extends the bugs in the viewer that are relied upon by a lot the rigged mesh content (LOD by the avatar BB box, LOD calculation broken and using double the radius of the avatar BB, etc etc) all needs to be rounded up and thought through by the lab with a view to fixing things. It is really hard, possibly impossible to fundamentally change things and retain back compatibility.

        The best that can be done at the moment is try to educate and inform creators, Adding more information into the viewer to warn people "hey, you know how things just got slow as hell? Here's why" has to be a good thing, but if it is in their face by default they'll just switch it off.

        Show
        beqphoenixjira Beq Janus added a comment - More information is a good thing. One of the reasons I have added the Mesh Information panel and the "LOD view" in the forthcoming release is to give users a chance to look at the #triangles and what the LODs look like, before they buy. It is truly targetted at builders of course but that is a nice side-effect. It doesn't help at all with stuff from MP. The same applies to the physics shape view, it is a tool that allows you to understand a little more and answer some of the "why?" questions. Will most users understand enough to use it? probably not, but just a tiny few more IMing a creator to tell them "I didn't buy your X because you skimped on the LOD models and the physics was crap" might be a trickle to start eroding the mentality of lazy design. The information presented here is excellent, but as Miro has noted, if we default it such that Catwa heads (the most popular in SL at present) don't show right is just going to annoy people into hiding it. We've spent quite a lot of time sending things to Oz relating to how broken things are. The fact that you can easily game the LOD with rigged mesh, a problem exacerbated with Animesh, and which further extends the bugs in the viewer that are relied upon by a lot the rigged mesh content (LOD by the avatar BB box, LOD calculation broken and using double the radius of the avatar BB, etc etc) all needs to be rounded up and thought through by the lab with a view to fixing things. It is really hard, possibly impossible to fundamentally change things and retain back compatibility. The best that can be done at the moment is try to educate and inform creators, Adding more information into the viewer to warn people "hey, you know how things just got slow as hell? Here's why" has to be a good thing, but if it is in their face by default they'll just switch it off.
        Hide
        whirly.fizzle Whirly Fizzle added a comment -

        This feature will be discussed at the next TPV meeting on Nov 17th: https://wiki.secondlife.com/wiki/TPVD/Developers_Group_Agenda

        Show
        whirly.fizzle Whirly Fizzle added a comment - This feature will be discussed at the next TPV meeting on Nov 17th: https://wiki.secondlife.com/wiki/TPVD/Developers_Group_Agenda
        Hide
        Arcane Portal Arcane Portal added a comment -

        Second Life famously needs a beefier computer than it should in order to get acceptable frame rates. Play almost any modern game on a decent PC and you'll have a steady 60FPS all day with current generation graphical standards. The same cannot be said for Second Life as a whole largely due to the fact that many creators have had no incentive to create well optimized content, and do not understand the link between texture usage and performance.

        Jellydolls based on complexity was a good start for letting people know what might be dragging down their performance, but unfortunately, excessive texture usage has just as bad, and often far greater of a performance impact, yet there's been no way to even tell, or much less do anything about it.

        Currently there are avatars in the avatar complexity green zone, yet they fill up literally 1/4th of the SL's maximum video memory on their own, but since they aren't jellied, people think they're fine when it couldn't be further from the truth, so even dropping down the graphics setting does little to help the actual problem, and it is a huge, easily fixable problem that is actively getting worse.

        Furthermore, the idea that one's avatar would need to look like it was stuck in 2012 in order to be below the limits is silly. Even the Catwa heads can be brought down to levels below the VRAM limit suggested for even the lowest graphical settings, it has been done. The stock head itself is half the VRAM limit for the lowest graphic setting with no modification, and can be knocked down even further with some tinkering. It is also worth mentioning that the required changes the creator would have to make in order to make the heads massively more optimized fresh off the store shelf are quite trivial. All they'd need to do is issue an update and then congratulations, everyone using the heads grid-wide would suddenly use less memory. With some know how, it is fixable by end users right now, and would certainly be more so if the creator had the means to identify the problem themselves. The thought of withholding such an important a feature because of a single creator's poor practices (which are almost certainly due entirely to simple innocent ignorance this feature set sheds light on), especially when it is an easy fix, is short sighted.

        Another thing to mention about the Catwa heads is the HUD alone uses a bit over 151MBs of texture memory, meaning everyone using the HUDs has that much less memory for everything else. This is not at all unique to Catwa either, and is, again, something entirely avoidable (and fixable) if creators had the information to do so.

        We've sat on releasing this feature set for a long time, partly due to expected criticism, and partly due to wanting to make sure the maximum limit was reasonable while still serving the intended purpose. Admittedly, we did mostly focus on the ultra graphics setting; I do see how issues could be taken with some of the lower graphics values, but the final numbers we came up with were anything but arbitrary. They are based on the various VRAM averages we saw, with consideration for both the hardware users running different settings might be using, and the number of avatars in populated areas (keeping in mind much more than just avatar textures fill up one's VRAM). For example, 160MB-ish was decided upon for the Ultra since that was a strangely common range for good looking avatars that, while definitely wearing poorly optimized content, weren't wearing many things that were too insane. The gap after that range tended to shoot up massively.

        As nice as it would be to include everyone, there needs to be a cutoff point and that is what we landed on. That is not to say that all the numbers must be set in stone without any sort of compromise, I never expected it to go that smoothly, and I get that compromise is the name of the game when it comes to such a matter, but thought was was put into it. The important thing here is keeping the long term point of the feature in mind when proposing new values. Make no mistake, this is addressing a problem that has become wildly out of control, and people, most importantly creators, will need time to adapt.

        You can have a mesh body with tattoo layers and an entirely unseen hidden applier layer outfit, a bento mesh head, mesh hair, rings and other jewelry, and mesh clothing while holding a mesh pet with a mesh companion next to you, all while looking up to par with current fashion visual standards, and still be below the suggested maximum limits. All it takes is the ability to actually know the impact of what you are buying, or creating, and choose accordingly.

        Second Life has inspired countless people to find their creative side and make things they never imagined they could make, and that is wonderful! However, we can't pretend that there are not very real hardware limitations, with a very real performance impact that drastically affects literally everyone. Having the means to moderate avatars that may be beyond what your PC is capable of dealing with, and the ability find out how efficient an item is, is a basic necessity. As it has been said, it could be off by default, making it entirely optional from the start, but it would still there for those who would use it.

        Imagine trying to play a current gen title on a low to mid range PC, one with aging older hardware, or a laptop with integrated graphics, and imagine being able to turn down model detail, disable anti-aliasing, and lower the draw distance, but no matter what, you are forced to use 4k textures everywhere. That is essentially Second Life right now.

        Having said all that, I do very much understand how having the avatar jellying based on VRAM as an official Linden Lab viewer feature would cause far less community uproar for the Firestorm team. I agree that the jellying by avatar VRAM portion as something coming from LL instead would be better. There are some issues to work out (such as some textures still downloading before the cutoff), but having such basic information easily viewable is something that has been desperately needed for years. I also quite like the idea of letting people know and prepare months ahead of time before anything starts getting jellied.

        I apologize for such a large wall of text, but there was a lot I felt needed to be said.

        Show
        Arcane Portal Arcane Portal added a comment - Second Life famously needs a beefier computer than it should in order to get acceptable frame rates. Play almost any modern game on a decent PC and you'll have a steady 60FPS all day with current generation graphical standards. The same cannot be said for Second Life as a whole largely due to the fact that many creators have had no incentive to create well optimized content, and do not understand the link between texture usage and performance. Jellydolls based on complexity was a good start for letting people know what might be dragging down their performance, but unfortunately, excessive texture usage has just as bad, and often far greater of a performance impact, yet there's been no way to even tell, or much less do anything about it. Currently there are avatars in the avatar complexity green zone, yet they fill up literally 1/4th of the SL's maximum video memory on their own, but since they aren't jellied, people think they're fine when it couldn't be further from the truth, so even dropping down the graphics setting does little to help the actual problem, and it is a huge, easily fixable problem that is actively getting worse. Furthermore, the idea that one's avatar would need to look like it was stuck in 2012 in order to be below the limits is silly. Even the Catwa heads can be brought down to levels below the VRAM limit suggested for even the lowest graphical settings, it has been done. The stock head itself is half the VRAM limit for the lowest graphic setting with no modification, and can be knocked down even further with some tinkering. It is also worth mentioning that the required changes the creator would have to make in order to make the heads massively more optimized fresh off the store shelf are quite trivial. All they'd need to do is issue an update and then congratulations, everyone using the heads grid-wide would suddenly use less memory. With some know how, it is fixable by end users right now, and would certainly be more so if the creator had the means to identify the problem themselves. The thought of withholding such an important a feature because of a single creator's poor practices (which are almost certainly due entirely to simple innocent ignorance this feature set sheds light on), especially when it is an easy fix, is short sighted. Another thing to mention about the Catwa heads is the HUD alone uses a bit over 151MBs of texture memory, meaning everyone using the HUDs has that much less memory for everything else. This is not at all unique to Catwa either, and is, again, something entirely avoidable (and fixable) if creators had the information to do so. We've sat on releasing this feature set for a long time, partly due to expected criticism, and partly due to wanting to make sure the maximum limit was reasonable while still serving the intended purpose. Admittedly, we did mostly focus on the ultra graphics setting; I do see how issues could be taken with some of the lower graphics values, but the final numbers we came up with were anything but arbitrary. They are based on the various VRAM averages we saw, with consideration for both the hardware users running different settings might be using, and the number of avatars in populated areas (keeping in mind much more than just avatar textures fill up one's VRAM). For example, 160MB-ish was decided upon for the Ultra since that was a strangely common range for good looking avatars that, while definitely wearing poorly optimized content, weren't wearing many things that were too insane. The gap after that range tended to shoot up massively. As nice as it would be to include everyone, there needs to be a cutoff point and that is what we landed on. That is not to say that all the numbers must be set in stone without any sort of compromise, I never expected it to go that smoothly, and I get that compromise is the name of the game when it comes to such a matter, but thought was was put into it. The important thing here is keeping the long term point of the feature in mind when proposing new values. Make no mistake, this is addressing a problem that has become wildly out of control, and people, most importantly creators, will need time to adapt. You can have a mesh body with tattoo layers and an entirely unseen hidden applier layer outfit, a bento mesh head, mesh hair, rings and other jewelry, and mesh clothing while holding a mesh pet with a mesh companion next to you, all while looking up to par with current fashion visual standards, and still be below the suggested maximum limits. All it takes is the ability to actually know the impact of what you are buying, or creating, and choose accordingly. Second Life has inspired countless people to find their creative side and make things they never imagined they could make, and that is wonderful! However, we can't pretend that there are not very real hardware limitations, with a very real performance impact that drastically affects literally everyone. Having the means to moderate avatars that may be beyond what your PC is capable of dealing with, and the ability find out how efficient an item is, is a basic necessity. As it has been said, it could be off by default, making it entirely optional from the start, but it would still there for those who would use it. Imagine trying to play a current gen title on a low to mid range PC, one with aging older hardware, or a laptop with integrated graphics, and imagine being able to turn down model detail, disable anti-aliasing, and lower the draw distance, but no matter what, you are forced to use 4k textures everywhere. That is essentially Second Life right now. Having said all that, I do very much understand how having the avatar jellying based on VRAM as an official Linden Lab viewer feature would cause far less community uproar for the Firestorm team. I agree that the jellying by avatar VRAM portion as something coming from LL instead would be better. There are some issues to work out (such as some textures still downloading before the cutoff), but having such basic information easily viewable is something that has been desperately needed for years. I also quite like the idea of letting people know and prepare months ahead of time before anything starts getting jellied. I apologize for such a large wall of text, but there was a lot I felt needed to be said.
        Hide
        Arcane Portal Arcane Portal added a comment -

        Here are some examples showing people who have put together nice avatars that are within the maximum VRAM cutoff limit. I really recommend giving each of them a good look over, because I am certain nobody would think a single one of these avatars was not up to modern standards. Note the listed texture memory in their name tags.

        Full avatar:
        https://i.imgur.com/mOtZpZd.jpg

        Close up:
        https://i.imgur.com/Pd0B3HU.jpg

        Avatar 2 full body:
        https://i.imgur.com/VKeDJK5.jpg

        Avatar 2 Close up:
        https://i.imgur.com/OI8oTao.jpg

        Full avatar pair:
        https://i.imgur.com/h5EuFAS.jpg

        Close up 1:
        https://i.imgur.com/bYSDbEJ.jpg

        Close up 2 showing a Catwa head using only 26MBs:
        https://i.imgur.com/OHKrEs3.jpg

        Full body avatar:
        https://i.imgur.com/cxJBKDb.jpg

        Close up for detail:
        https://i.imgur.com/4psfC87.jpg

        Avatar full body:
        https://i.imgur.com/ukJwF3y.jpg

        Close up:
        https://i.imgur.com/vDOdDcP.jpg

        Full body avatar, note that this person is only 46MBs total:
        https://i.imgur.com/7DRa1Ts.jpg

        ...and their Catwa head comes in just under a whopping 15 whole megabytes:
        https://i.imgur.com/RiqsxC7.jpg

        Full avatar view:
        https://i.imgur.com/eDuvY3Y.jpg

        and a close up of him:
        https://i.imgur.com/6WCf3pz.jpg

        and with his Catwa head selected, using about 23MBs:
        https://i.imgur.com/ybwIDvA.jpg

        Now, it is very much worth noting that many of their attachments are not particularly well optimized, and in some cases a single small item accounts for up to half of their texture memory. If something like this feature set had been part of Second Life much earlier, and items were made with optimization in mind, nobody would be arguing that you couldn't look up to par under the suggested VRAM cutoff for even the lowest graphic setting.

        Show
        Arcane Portal Arcane Portal added a comment - Here are some examples showing people who have put together nice avatars that are within the maximum VRAM cutoff limit. I really recommend giving each of them a good look over, because I am certain nobody would think a single one of these avatars was not up to modern standards. Note the listed texture memory in their name tags. Full avatar: https://i.imgur.com/mOtZpZd.jpg Close up: https://i.imgur.com/Pd0B3HU.jpg Avatar 2 full body: https://i.imgur.com/VKeDJK5.jpg Avatar 2 Close up: https://i.imgur.com/OI8oTao.jpg Full avatar pair: https://i.imgur.com/h5EuFAS.jpg Close up 1: https://i.imgur.com/bYSDbEJ.jpg Close up 2 showing a Catwa head using only 26MBs: https://i.imgur.com/OHKrEs3.jpg Full body avatar: https://i.imgur.com/cxJBKDb.jpg Close up for detail: https://i.imgur.com/4psfC87.jpg Avatar full body: https://i.imgur.com/ukJwF3y.jpg Close up: https://i.imgur.com/vDOdDcP.jpg Full body avatar, note that this person is only 46MBs total: https://i.imgur.com/7DRa1Ts.jpg ...and their Catwa head comes in just under a whopping 15 whole megabytes: https://i.imgur.com/RiqsxC7.jpg Full avatar view: https://i.imgur.com/eDuvY3Y.jpg and a close up of him: https://i.imgur.com/6WCf3pz.jpg and with his Catwa head selected, using about 23MBs: https://i.imgur.com/ybwIDvA.jpg Now, it is very much worth noting that many of their attachments are not particularly well optimized, and in some cases a single small item accounts for up to half of their texture memory. If something like this feature set had been part of Second Life much earlier, and items were made with optimization in mind, nobody would be arguing that you couldn't look up to par under the suggested VRAM cutoff for even the lowest graphic setting.
        Hide
        ansariel.hiller Ansariel Hiller added a comment -

        Actually I think blaming texture sizes and resulting VRAM usage as THE remaining performance killer is distracting from the REAL performance killers. Yes, exceeding texture limits and the resulting rescaling and constant reloading of images is A problem, but it is not THE problem, it is one among a bunch of issues. LL's 64bit viewer will be able to use up to 2GB for textures AFAIK and there are some improvements to the texture cache in LL's pipeline, so it will improve things to some extend - not necessarily much for people on older hardware though, but still.

        But by all the focus on the textures, it would have been a great idea to check the fast timers view and GPU monitor to see where the actual problems lie: All that ancient code in the viewer not making use of "new" CPU features, ancient code in the shader files, the crazy amount of small vertex buffers instead of fewer larger ones, CPU still doing calculations that could be done by the GPU much faster, old old OpenGL stuff that forces Macs into version 2.1 - just to mention a few. And the biggest performance improvement in rendering an avatar as jelly doll because of their texture usage isn't achieved by the reduced texture load, but the fact the time for calculating the avatar vertices and writing all the vertex buffers for it is saved.

        P.S.: I love how all the linked pictures of good looking avatars within the texture limit come without jewelry.

        P.P.S.: I'm also wondering a bit why you didn't bring this up with LL at the first place?

        Show
        ansariel.hiller Ansariel Hiller added a comment - Actually I think blaming texture sizes and resulting VRAM usage as THE remaining performance killer is distracting from the REAL performance killers. Yes, exceeding texture limits and the resulting rescaling and constant reloading of images is A problem, but it is not THE problem, it is one among a bunch of issues. LL's 64bit viewer will be able to use up to 2GB for textures AFAIK and there are some improvements to the texture cache in LL's pipeline, so it will improve things to some extend - not necessarily much for people on older hardware though, but still. But by all the focus on the textures, it would have been a great idea to check the fast timers view and GPU monitor to see where the actual problems lie: All that ancient code in the viewer not making use of "new" CPU features, ancient code in the shader files, the crazy amount of small vertex buffers instead of fewer larger ones, CPU still doing calculations that could be done by the GPU much faster, old old OpenGL stuff that forces Macs into version 2.1 - just to mention a few. And the biggest performance improvement in rendering an avatar as jelly doll because of their texture usage isn't achieved by the reduced texture load, but the fact the time for calculating the avatar vertices and writing all the vertex buffers for it is saved. P.S.: I love how all the linked pictures of good looking avatars within the texture limit come without jewelry. P.P.S.: I'm also wondering a bit why you didn't bring this up with LL at the first place?
        Hide
        pennypatton Penny Patton added a comment -

        No one is saying that the VRAM issue is SL's one solitary issue, however it is a major one and dismissing a potential solution to this one problem because it doesn't fix every other SL issue is not productive in any way.

        Furthermore, some of us have been enjoying better performance and better graphics in SL for years now, simply because we do understand the practical realities of content creation for realtime 3D rendering. We've taken steps to mitigate the problems brought on by poorly made SL content as much as we can in our own little corners of SL and not only seen marked improvement ourselves, but been able to share it with others. To deny that badly made content has a significant impact on performance is to assert that you believe people like us are magical wizards who can simply will SL to achieve higher framerates through the power of faith.

        It's not magic. It's simply understanding the problem and addressing it with real solutions.

        Show
        pennypatton Penny Patton added a comment - No one is saying that the VRAM issue is SL's one solitary issue, however it is a major one and dismissing a potential solution to this one problem because it doesn't fix every other SL issue is not productive in any way. Furthermore, some of us have been enjoying better performance and better graphics in SL for years now, simply because we do understand the practical realities of content creation for realtime 3D rendering. We've taken steps to mitigate the problems brought on by poorly made SL content as much as we can in our own little corners of SL and not only seen marked improvement ourselves, but been able to share it with others. To deny that badly made content has a significant impact on performance is to assert that you believe people like us are magical wizards who can simply will SL to achieve higher framerates through the power of faith. It's not magic. It's simply understanding the problem and addressing it with real solutions.
        Hide
        ansariel.hiller Ansariel Hiller added a comment -

        Like I said before: How does rendering avatars as impostors help with the other badly made content out there? Like this house a friend once bought that came with over 700MB of textures itself without any deco stuff? The deco stuff that often comes with 4MB textures for every bell and whistle? Don't get me wrong here, I'm all for improving performance because it's ridiculous how slow SL is. However, reducing avatar textures would only have minimal effect to achieve this and is rather a placebo than a real solution. But you seem to be obsessed that it's avatar textures that are a main cause that now has to be cured instantly by imposing texture limits on people that you came up with after evaluating avatars that you define as "good looking". And to enforce that, it seems to me that you decided to take a shortcut via Firestorm instead of bringing this topic up with Linden Lab.

        Anyway: This is going to be discussed at the next TPV meeting and personally I am against implementing a function to impostor avatars based on used texture memory without this being an official feature of Linden Lab. Adding the informational part is a good thing though.

        Show
        ansariel.hiller Ansariel Hiller added a comment - Like I said before: How does rendering avatars as impostors help with the other badly made content out there? Like this house a friend once bought that came with over 700MB of textures itself without any deco stuff? The deco stuff that often comes with 4MB textures for every bell and whistle? Don't get me wrong here, I'm all for improving performance because it's ridiculous how slow SL is. However, reducing avatar textures would only have minimal effect to achieve this and is rather a placebo than a real solution. But you seem to be obsessed that it's avatar textures that are a main cause that now has to be cured instantly by imposing texture limits on people that you came up with after evaluating avatars that you define as "good looking". And to enforce that, it seems to me that you decided to take a shortcut via Firestorm instead of bringing this topic up with Linden Lab. Anyway: This is going to be discussed at the next TPV meeting and personally I am against implementing a function to impostor avatars based on used texture memory without this being an official feature of Linden Lab. Adding the informational part is a good thing though.
        Hide
        chalice yao Chalice Yao added a comment -

        > But by all the focus on the textures, it would have been a great idea to check the fast timers view and GPU monitor to see where the actual problems lie: <snip>

        > Like I said before: How does rendering avatars as impostors help with the other badly made content out there?

        First off, the patch contains functionality to analyze the texture usage of in-world objects, up to multi-object selections down to single links. It gives people the ability to see just how much said in-world content eats up in terms of resources - especially houses given that those tend to be demo-able in world, pre-purchase. I have chosen multiple times not to get an SL home or other demo-rezzed item from the marketplace based on the information I was able to get with this functionality. That's how it helps.

        Second, a way of blocking avatars from loading more textures past the limit is simply shown by the fact that in a room full of avatars in-world content tends to pale in comparison. At an event I was at, 29 avatars clocked at a total memory usage of 5.6 gigabytes.
        Five. Point. Six. Gigabytes. Just the avatars.
        A minimum amount of textures was shared, so that number, even if you trim some duplicates away, still remains at around 5.4-5.5 gigabytes. Notably is that this was not an event that had the max amount of avatars around. And it shows how even a handful of avatars out of that bunch exceeds the strain on VRAM that even bad actual in-world content creates.
        It is eerily similiar to amounts of scripts, where even a small bunch of avatars tends to create more script strain on the sim with their attached masses of scripts than the statically placed items. I don't think that rather analog development in comparing avatar vs. in-world item numbers is a coincidence.
        I also believe that, while simply showing the numbers help a lot if you are a person that has some technical knowledge and/or a sense and desire for efficient content, it does not, at all, provide any kind of incentive for the average creator and consumer to improve the situation unless they gain an actual advantage in doing so. Nor does only showing the information help the people with lower end hardware to have a more tolerable resource usage put on their hardware from content that already exists.

        Third, you keep on saying 'But what about these other issues.'. Other issues are not the topic of the patch. Texture information and limiting is. That's all it is about, and all it wants to handle. If somebody wants to handle other issues that the client has, I encourage them.
        Even saying 'But how does it help with placed items' is not a negative on the functionality that it does provide already. It is simply an indication that maybe there are even more functionalities that could be added onto this later. Step by step, SL can be improved.

        Lastly, no. This is not a 'shortcut' via Firestorm. We've been enjoying this functionality for a while, but we figured that it simply won't improve the grid and help people out there by just staying in our hands. And since the code is firestorm compatible, we figured we'd try and make it available to your viewer first - especially because we don't agree with the policies and politics of some of the other TPVs out there. And quite frankly we didn't think that LL would, at all, be intereste, and that you'd like the opportunity to be the first to have the feature among the TPVs willing to take it.
        LL's seeming enthusiasm for this kind of functionality has taken us by QUITE some surprise - quite a happy surprise, actually - so yes. I'll be at the TPV meeting.

        Show
        chalice yao Chalice Yao added a comment - > But by all the focus on the textures, it would have been a great idea to check the fast timers view and GPU monitor to see where the actual problems lie: <snip> > Like I said before: How does rendering avatars as impostors help with the other badly made content out there? First off, the patch contains functionality to analyze the texture usage of in-world objects, up to multi-object selections down to single links. It gives people the ability to see just how much said in-world content eats up in terms of resources - especially houses given that those tend to be demo-able in world, pre-purchase. I have chosen multiple times not to get an SL home or other demo-rezzed item from the marketplace based on the information I was able to get with this functionality. That's how it helps. Second, a way of blocking avatars from loading more textures past the limit is simply shown by the fact that in a room full of avatars in-world content tends to pale in comparison. At an event I was at, 29 avatars clocked at a total memory usage of 5.6 gigabytes. Five. Point. Six. Gigabytes. Just the avatars. A minimum amount of textures was shared, so that number, even if you trim some duplicates away, still remains at around 5.4-5.5 gigabytes. Notably is that this was not an event that had the max amount of avatars around. And it shows how even a handful of avatars out of that bunch exceeds the strain on VRAM that even bad actual in-world content creates. It is eerily similiar to amounts of scripts, where even a small bunch of avatars tends to create more script strain on the sim with their attached masses of scripts than the statically placed items. I don't think that rather analog development in comparing avatar vs. in-world item numbers is a coincidence. I also believe that, while simply showing the numbers help a lot if you are a person that has some technical knowledge and/or a sense and desire for efficient content, it does not, at all, provide any kind of incentive for the average creator and consumer to improve the situation unless they gain an actual advantage in doing so. Nor does only showing the information help the people with lower end hardware to have a more tolerable resource usage put on their hardware from content that already exists. Third, you keep on saying 'But what about these other issues.'. Other issues are not the topic of the patch. Texture information and limiting is. That's all it is about, and all it wants to handle. If somebody wants to handle other issues that the client has, I encourage them. Even saying 'But how does it help with placed items' is not a negative on the functionality that it does provide already. It is simply an indication that maybe there are even more functionalities that could be added onto this later. Step by step, SL can be improved. Lastly, no. This is not a 'shortcut' via Firestorm. We've been enjoying this functionality for a while, but we figured that it simply won't improve the grid and help people out there by just staying in our hands. And since the code is firestorm compatible, we figured we'd try and make it available to your viewer first - especially because we don't agree with the policies and politics of some of the other TPVs out there. And quite frankly we didn't think that LL would, at all, be intereste, and that you'd like the opportunity to be the first to have the feature among the TPVs willing to take it. LL's seeming enthusiasm for this kind of functionality has taken us by QUITE some surprise - quite a happy surprise, actually - so yes. I'll be at the TPV meeting.
        Hide
        ansariel.hiller Ansariel Hiller added a comment -

        At an event I was at, 29 avatars clocked at a total memory usage of 5.6 gigabytes.

        Calculating 29 avatars with the proposed hard limit in this patch of 160 MB of textures and it is still 4.6 GB. Does this make it any better?

        Show
        ansariel.hiller Ansariel Hiller added a comment - At an event I was at, 29 avatars clocked at a total memory usage of 5.6 gigabytes. Calculating 29 avatars with the proposed hard limit in this patch of 160 MB of textures and it is still 4.6 GB. Does this make it any better?
        Hide
        pennypatton Penny Patton added a comment -

        Are you actually asking whether or not reducing the VRAM load by entire GB is an improvement?

        Also, remember that as content creators are discouraged from leaving their content unoptimized it will become increasingly easy for the average resident to fall well below the 160MB limit.

        It's like Land Impact. You want to get the most content onto your land, so when you see a chair that uses 200 LI and a chair that looks just as good but only uses 1LI, you're obviously going to choose the chair with the lower LI. Even if you have 200 LI left to use because you can better use that LI for more content.

        Encourage people to want to keep their VRAM use low and they will approach their avatar accessories with the same mindset.

        Show
        pennypatton Penny Patton added a comment - Are you actually asking whether or not reducing the VRAM load by entire GB is an improvement? Also, remember that as content creators are discouraged from leaving their content unoptimized it will become increasingly easy for the average resident to fall well below the 160MB limit. It's like Land Impact. You want to get the most content onto your land, so when you see a chair that uses 200 LI and a chair that looks just as good but only uses 1LI, you're obviously going to choose the chair with the lower LI. Even if you have 200 LI left to use because you can better use that LI for more content. Encourage people to want to keep their VRAM use low and they will approach their avatar accessories with the same mindset.
        Hide
        Arcane Portal Arcane Portal added a comment - - edited

        It should honestly go without saying that there is much more to Second Life's performance problems than what this patch is focused on, and it would be lovely to fix every single one of them some day, but if nobody ever tries to lay a foundation for progress, one problem at time, then none will be made. As you say, avatar textures are most definitely not THE sole remaining performance roadblock, and nobody has said this is the case. Yes, there are other problems, no, jellying avatars does not help out with rezzed content, but nobody is claiming it does. The reason emphasis has been placed on avatar textures is because part of this feature set deals with them specifically, not because we believe that alone will solve everything.

        The fact does remain that avatars do play a large part of the bigger picture. There's also the fact that even though there are other contributing factors to performance as a whole, it does not negate improvements in one specific area. Those with less powerful hardware (and less VRAM in this case), which is a large portion of SL's user base, will benefit the most from any sort of performance improvement.

        As for "good looking" avatars, replace that with "modern day", "typical", or anything of your choice. It was a general term to differentiate the average avatar one might see today, from ones stuck in 2012, as some would say.

        The snapped pictures were what people had on at the time for their own personal styles, and looking over them again, most have some jewelry or equivalent adornments. Jewelry is by far the easiest type of attachment to keep/make low VRAM due to the nature of its size, wearing more doesn't make it any harder to stay within the limit so long as a person is capable of making informed choices, which the other half of this patch helps with a lot: https://i.imgur.com/zH2idAn.jpg

        Show
        Arcane Portal Arcane Portal added a comment - - edited It should honestly go without saying that there is much more to Second Life's performance problems than what this patch is focused on, and it would be lovely to fix every single one of them some day, but if nobody ever tries to lay a foundation for progress, one problem at time, then none will be made. As you say, avatar textures are most definitely not THE sole remaining performance roadblock, and nobody has said this is the case. Yes, there are other problems, no, jellying avatars does not help out with rezzed content, but nobody is claiming it does. The reason emphasis has been placed on avatar textures is because part of this feature set deals with them specifically, not because we believe that alone will solve everything. The fact does remain that avatars do play a large part of the bigger picture. There's also the fact that even though there are other contributing factors to performance as a whole, it does not negate improvements in one specific area. Those with less powerful hardware (and less VRAM in this case), which is a large portion of SL's user base, will benefit the most from any sort of performance improvement. As for "good looking" avatars, replace that with "modern day", "typical", or anything of your choice. It was a general term to differentiate the average avatar one might see today, from ones stuck in 2012, as some would say. The snapped pictures were what people had on at the time for their own personal styles, and looking over them again, most have some jewelry or equivalent adornments. Jewelry is by far the easiest type of attachment to keep/make low VRAM due to the nature of its size, wearing more doesn't make it any harder to stay within the limit so long as a person is capable of making informed choices, which the other half of this patch helps with a lot: https://i.imgur.com/zH2idAn.jpg

          People

          • Assignee:
            beqphoenixjira Beq Janus
            Reporter:
            jessica_lyon Jessica Lyon
          • Votes:
            4 Vote for this issue
            Watchers:
            12 Start watching this issue

            Dates

            • Created:
              Updated: