How Much Does Unoptimized Content Actually Affect Us?

[Penny Patton]

I've noticed that whenever the topic of content optimization is brought up, a lot of people assume it would maybe have some positive effect, but not all that much.

This is completely wrong, so I booted up Second Life on two different computers, one a laptop using onboard graphics, and ran around some of Second Life's best optimized locations.

You can read the full article here.

To sum it all up, if your computer was made in the last 10 years and has just about any sort of dedicated graphics card, you should be able to run SL at nearly max settings, getting 30-60FPS or better and never experience texture thrashing, graphics stuttering, long rez times, or any of the other numerous SL graphics woes you probably experience constantly. In other words, Second Life should run like a dream, even on a 10 year old computer.

And it does, right now, in sims that have been optimized by people who know what they're doing.

This is, of course, assuming your avatar is also far more optimized than the typical SL avatar. Most people are their own worst enemy in this regard and never even realize it. Avatars have gotten so much worse, even just in the past year or two.

 If I go to similarly high-detail sims made by people who don't optimize, I'm lucky if my computer doesn't crash before everything has finished rezzing unless I turn my graphics settings way, way down.

 And if you're running SL on a toaster, you'd experience an even more noticeable performance boost. Essentially, the less powerful your hardware, the more you gain from optimized content. On an MS Surface Book with onboard intel graphics I was getting 40fps with everything short of Deferred Rendering/Advanced Lighting Model turned on. And, again, no stuttering, no texture thrashing, and lightning fast rez times.

And to be absolutely clear, none of these environments feature game designer levels of content optimization. We are talking bare minimum, common sense optimization. Well within what can be expected from any SL content creator.

• Using low poly content with well made LOD models.
• Masking alpha textures rather than using blended mode.
• Keeping texture use reasonable.

If you're a content creator and want to know more about how you can optimize your own work, there are some links in the article you might want to check out.

[Profaitchikenz Haiku]

16 hours ago, Penny Patton said:

If I go to similarly high-detail sims made by people who don't optimize, I'm lucky if my computer doesn't crash before everything has finished rezzing unless I turn my graphics settings way, way down.

I went through this exercise last year helping some friends with their parcel, steadily weeding out massive textures and the odd high-LI structure that also seemed to contribute to loading issues. We moved the landing point around the parcel until we found a spot that caused such crashes and tracked down various items which were then replaced with lower-poly alternatives or re-textured.

After the work was done I could visit with a laptop running Intel integrated graphics and still view the whole parcel build with the LL viewer's minimum draw-distance with no rezzing crashes or noticeable delays.

We found Firestorm's object VRAM tab the most useful here as it showed the total texturing for individual  children in a linkset, for which I don't think I've ever seen any alternative way of doing it.

One thing here I think creators could assist with is to provide the textures on a link set as full-perms if they are using 1024-sized images, because that allows them to be downloaded, resized, and then uploaded and re-applied.

[arabellajones]

On 6/24/2019 at 10:35 PM, Profaitchikenz Haiku said:

One thing here I think creators could assist with is to provide the textures on a link set as full-perms if they are using 1024-sized images, because that allows them to be downloaded, resized, and then uploaded and re-applied.

I'm not sure they would do that, some would start screaming about content theft, but 1024-size images are all too common, and the way the graphics sub-systems work on the viewer you have to get very close before you see the full resolution version on clothing.

For a good example of essentially unoptimised clothes, The Lindens have given us the four SL16B outfits, with 1024-size textures and very high mesh density. The way the LOD-switching distances are calculated for a rigged mesh,  graphics are weighed down with sub-pixel triangles, and the download weight rises a lot, hurting sim crossings and teleports.

My usual avatar, mesh body, mesh clothes, and all, comes in at around half the ARC of one of these outfits. Just the texture sizes would make a big difference, with minimal effort.

These things are choices, I can see reasons for 1024-size on a large object, but I doubt the competence of some creators who use them.

 

[Wulfie Reanimator]

1 hour ago, arabellajones said:

My usual avatar, mesh body, mesh clothes, and all, comes in at around half the ARC of one of these outfits. Just the texture sizes would make a big difference, with minimal effort.

A little side-note: ARC is an entirely useless metric for any purpose. See:

https://community.secondlife.com/forums/topic/431342-land-impact-of-mesh-head/page/2/?tab=comments#comment-1841410

[ChinRey]

11 minutes ago, Wulfie Reanimator said:

A little side-note: ARC is an entirely useless metric for any purpose.

More details about this:

https://community.secondlife.com/forums/topic/419469-rigged-mesh-lod-bug/

and

https://community.secondlife.com/forums/topic/426621-what-the-fitmesh-lod-bug-actually-means/?tab=comments#comment-1783665

To sum it up: Due to a combination of three (at least) bugs, the entire LoD system is effectively disabled for fitted mesh. The ARC, however, is calculated as if LoD worked as intended.

 

 

[Coffee Pancake]

I would actually argue for 4096 maps and encourage atlasing, capping the max resolution is something that can be done in the veiwer and they are already progressively encoded. Better texture management in the viewer is one of the simpler problems over detailed content presents, but any efforts in that direction are dependent on the new cache and render code from LL as right now it's not practical to aggressively ensure every texture is at the optimum resolution. (Not literally dependent, but none of the TPV's have the resources to code & optimise something today that's going to need a complete do over when LL push changes)

There is nothing we can do about mesh detail and LOD models. Junk today will be junk tomorrow will be junk forever. Focus on educating people about that.

[animats]

I'd still like to find a leather jacket and biker boots that don't have 10x the triangles they need. I have a pair of boots where each rivet has a full 3D model.

[Penny Patton]

15 hours ago, CoffeeDujour said:

I would actually argue for 4096 maps and encourage atlasing, capping the max resolution is something that can be done in the veiwer and they are already progressively encoded. Better texture management in the viewer is one of the simpler problems over detailed content presents, but any efforts in that direction are dependent on the new cache and render code from LL as right now it's not practical to aggressively ensure every texture is at the optimum resolution. (Not literally dependent, but none of the TPV's have the resources to code & optimise something today that's going to need a complete do over when LL push changes)

There is nothing we can do about mesh detail and LOD models. Junk today will be junk tomorrow will be junk forever. Focus on educating people about that.

This is why I've always felt the better metric is texture memory, rather than the size of individual textures. If we had some tools that reigned in memory use LL could increase the maximum texture size without worrying that people will employ the same bad habits, just with much larger textures.

[Coffee Pancake]

We're still having difficulty communicating that there are places you can not go with the stock 512mb viewer, and SL is still flooded with users on vintage hardware.

Blocking vintage hardware (that lies about the amount of VRAM on offer, and chokes when you try and then use what it offers) would have a massive impact to concurrency numbers. Entire countries would go dark.

[arabellajones]

On 6/29/2019 at 4:14 PM, ChinRey said:

More details about this:

https://community.secondlife.com/forums/topic/419469-rigged-mesh-lod-bug/

and

https://community.secondlife.com/forums/topic/426621-what-the-fitmesh-lod-bug-actually-means/?tab=comments#comment-1783665

To sum it up: Due to a combination of three (at least) bugs, the entire LoD system is effectively disabled for fitted mesh. The ARC, however, is calculated as if LoD worked as intended.

 

 

Please note that the texture system doesn't have any connection to the LOD system, calculating mipmap usage independently of LOD switching distances, and maximum texture size, which might never be seen by a user in-world, but which has to be downloaded and processed by the viewer, does affect the ARC number.

Since the Lindens have known about this for a long time, and said sweet fanny adams about changing how it works, persisting in calling this LOD behaviour a bug, and ignoring it, seems like foolish wilful blindness. If that's how the system works, why aren't you using it? Why do you persist in using high triangle counts for the Low and Lowest LOD models, which still have to be downloaded and stored locally?

But, before you get all snooty about this, look at what you make in wireframe mode. If the edges of the triangles are so close together that the item looks solid, can your opinion on optimised content be worth anything?

[arabellajones]

On 6/30/2019 at 9:01 AM, Penny Patton said:

This is why I've always felt the better metric is texture memory, rather than the size of individual textures. If we had some tools that reigned in memory use LL could increase the maximum texture size without worrying that people will employ the same bad habits, just with much larger textures.

Penny, I agree about memory use having more relevance than than texture size, but they still have to be downloaded, and having better use of memory by the viewer isn't going to help download, streaming, or whatever other label the Lindens are using this week. I can already set my viewer to not display larger than 512-size, but there's no way to not download the 1024-size original.

Besides, pixel count, in the data or for the size on screen, it what the graphics system works with. There are shoes in these SL16B sets which have the laces modelled and textured, distinct faces around 10cm across. Why is a 1024-size texture even being used for something that small? That works out at 10 pixels per millimetre. I reckon the level of detail in the model is a bit wasted, but as a texture? (The same shoes have a texture for the lining, the inside of the shoe that nobody sees while it is worn, and that's another 1024-size!)

[ChinRey]

2 hours ago, arabellajones said:

But, before you get all snooty about this, look at what you make in wireframe mode.

Who? Me???

 

2 hours ago, arabellajones said:

Since the Lindens have known about this for a long time, and said sweet fanny adams about changing how it works, persisting in calling this LOD behaviour a bug, and ignoring it, seems like foolish wilful blindness.

The problem LL has here is that it's extremely difficult to find a solution. Fix the formula to reflect the reality and the calculated ARC for most fitted mesh will skyrocket. Fix the bugs themselves and most of the existing fitted mesh will be broken. A dual system with old mesh calculated the old way and only correct the bug for new mesh will have serious consequences too.

 

2 hours ago, arabellajones said:

Please note that the texture system doesn't have any connection to the LOD system,

Yes, that's a different issue and equally serious. SL has some sort of mipmapping but it doesn't work as well as it should and even if it did, it wouldn't have helped with bandwidth and VRAM usage.

[ChinRey]

2 hours ago, arabellajones said:

But, before you get all snooty about this, look at what you make in wireframe mode.

Who? Me???

 

2 hours ago, arabellajones said:

Since the Lindens have known about this for a long time, and said sweet fanny adams about changing how it works, persisting in calling this LOD behaviour a bug, and ignoring it, seems like foolish wilful blindness.

The problem LL has here is that it's extremely difficult to find a solution. Fix the formula to reflect the reality and the calculated ARC for most fitted mesh will skyrocket. Fix the bugs themselves and most of the existing fitted mesh will be broken. A dual system with old mesh calculated the old way and only correct the bug for new mesh will have serious consequences too.

 

2 hours ago, arabellajones said:

Please note that the texture system doesn't have any connection to the LOD system,

Yes, that's a different issue and equally serious. SL has some sort of mipmapping but it doesn't work as well as it should and even if it did, it wouldn't have helped with bandwidth and VRAM usage.

 

2 hours ago, arabellajones said:

There are shoes in these SL16B sets which have the laces modelled and textured, distinct faces around 10cm across. Why is a 1024-size texture even being used for something that small? That works out at 10 pixels per millimetre.

You think that is bad? I have a pair of boots with a separate 1024 texture for a small bran label on the bottom fo the sole. Needless to say, I haven't sued those since I found out.

[Penny Patton]

2 hours ago, arabellajones said:

Penny, I agree about memory use having more relevance than than texture size, but they still have to be downloaded, and having better use of memory by the viewer isn't going to help download, streaming, or whatever other label the Lindens are using this week. I can already set my viewer to not display larger than 512-size, but there's no way to not download the 1024-size original.

You're misunderstanding me. I'm saying the amount of memory textures use is a better metric than the number or pixel size of the textures. 

A single object might usefive textures, but have them all be 256x256 and that is way better than an object using one 1024x1024 texture because it's using less memory. Or, you might have a set of 12 filler buildings to use in a city sim, and the houses might use a single 4096x4096 texture atlas.  That's way better than if each building was using a different single 1024x1024 texture apiece.

It's the memory use that affects performance. The memory use is also the file size so that affects downloads. Reduce the total texture memory use of a sim by 2GB and that is 2GB worth of texture data your viewer doesn't have to download.

[Penny Patton]

1 hour ago, ChinRey said:

The problem LL has here is that it's extremely difficult to find a solution. Fix the formula to reflect the reality and the calculated ARC for most fitted mesh will skyrocket. Fix the bugs themselves and most of the existing fitted mesh will be broken. A dual system with old mesh calculated the old way and only correct the bug for new mesh will have serious consequences too.

I don't think the problem is so insurmountable.

Solution 1: Fix it so LOD is used properly by rigged mesh. Make it abundantly clear, scream it from the mountains so all SL users and content creators know this is happening, then delay rolling out the fix while you reach out to the most popular mesh body creators so they can make any necessary changes and release free updates. For said content creators, making such a fix would be annoying, but not difficult or all that time consuming.

Solution 2: Make ARC accurately reflect the lack of proper LOD. Sure, ARC shoots up for a lot of people, but....so what? Is ARC actually used by anything? It wouldn't be the first time avatar complexity calculations have drastically changed.

Edited July 1, 2019 by Penny Patton

[Penny Patton]

On 6/30/2019 at 9:49 AM, CoffeeDujour said:

We're still having difficulty communicating that there are places you can not go with the stock 512mb viewer, and SL is still flooded with users on vintage hardware.

Blocking vintage hardware (that lies about the amount of VRAM on offer, and chokes when you try and then use what it offers) would have a massive impact to concurrency numbers. Entire countries would go dark.

I'm not sure what you mean by this post.

I agree that blocking older hardware would be a bad idea.....but unless there's a post I'm just not seeing, I don't think anyone suggested blocking hardware.

And if anything, the fact that so many SL users rely on older or less expensive hardware is yet another reason why optimization is so important. As I demonstrated, even a laptop with onboard graphics can run SL on medium settings at a respectable framerate and no other performance issues in environments with bare-bones optimizations to the content.

 Up until it died, my backup SL computer was a Toshiba Portege from 2007. I was able to use that with deferred rendering enable and still get around 20fps. And no, that's not a typo, the laptop was released in 2007. Onboard Intel graphics, no videocard. Could run SL with deferred rendering enabled and at around 20fps. I used it regularly when I was away from home. I couldn't leave the safety of those optimized sims, it would crash almost immediately anywhere else, but as long as I stayed in a handful of sims that weren't overburdened with excessive texture use, and I derendered avatars with excessive textures, I could run SL better than a lot of people experience with much more powerful machines.

Edited July 1, 2019 by Penny Patton

[Profaitchikenz Haiku]

46 minutes ago, Penny Patton said:

I'm not sure what you mean by this post.

I sort of get it, in that there's plenty of people (pensioners, myself included) who can't afford a new PC every other year and are clinging on to old hardware hoping that there's not going to be a sea change resulting in us no longer being able to do anything other than log in via Radegast. As for the rest of the paragraph, remember most pensioners are incapable, incoherent and  incontinent, so yes, it's possible entire countries would go dark. ( I know, I just won the bad pun of the year award)

 

[arabellajones]

2 hours ago, Penny Patton said:

I don't think the problem is so insurmountable.

Solution 1: Fix it so LOD is used properly by rigged mesh. Make it abundantly clear, scream it from the mountains so all SL users and content creators know this is happening, then delay rolling out the fix while you reach out to the most popular mesh body creators so they can make any necessary changes and release free updates. For said content creators, making such a fix would be annoying, but not difficult or all that time consuming.

Solution 2: Make ARC accurately reflect the lack of proper LOD. Sure, ARC shoots up for a lot of people, but....so what? Is ARC actually used by anything? It wouldn't be the first time avatar complexity calculations have drastically changed.

When I look at some of the behaviour of non-rigged mesh in SL, I do wonder how many creators know what they're doing.. You can make vehicle wheels which don't collapse into lumps of triangles as you move to the side of the road: I've done it.

ARC is used by the Max Complexity limit in graphics settings. You know, the Jelly Dolls. It's a poorly implemented pieced of UI and to see anything over about 350k complexity you have to switch off the limit. That's risky, because of griefers with graphics bombs.

As far as I can tell, the LOD switching is badly calculated for rigged mesh, making the Medium->Low and Low->Lowest switching mostly irrelevant, because of Draw Distance settings. but it still seems to happen, and the ARC calculation gives plausible answers.

We have confusing documentation (and I have ranted about that) but I don't see any signs of things not working as documented. Could things be done better? Yes, but I am not confident that some of the big name, high sales, creators could optimise their way out of a soggy wet paper bag. Rather than learn just how to do their job, they start screaming "It's a bug!", and go on to do nothing.

And you know what started me off on this: people using 1024-size textures with pointless alpha channels. Let me check, rez the original version of this pair of shoes, so it does't invoke the rigged-mesh bug excuse: 6264 display weight. Used reduced size textures, without the alpha channels, and I get a display weight of 2998. The LOD switching distances shown by the Firestorm editor look right for a mesh object of that size. Let's try the Inspect right-click...

1024-size textures with alpha channels: 12,288 KB VRAM

Reduced-size textures with no alpha channels: 1,536 KB VRAM

Yep, it's an insanely high triangle count as well, but textures are so easy to re-scale, and it looks like these people don't even bother to try.

The Download/Streaming weight reported doesn't change, which is a bit odd.

[arabellajones]

The computer I am currently using is about ten years old, with a much more recent graphics card. The old nVidia 750 I used was pretty slow, but OK for standing around at an event. The replacement I got makes other things more comfortable. Computers which are that old can fail for all sorts of reasons. I don't think I am using anything super-powerful. And I am trying, when I make stuff, not to waste the computer power my audience might have.

I have seen a fancy dress with an ARC of over 1 million. I did look, once. It did did nasty things to the frame rate that old 750 was giving me.

[Penny Patton]

2 hours ago, Profaitchikenz Haiku said:

I sort of get it, in that there's plenty of people (pensioners, myself included) who can't afford a new PC every other year and are clinging on to old hardware hoping that there's not going to be a sea change resulting in us no longer being able to do anything other than log in via Radegast. As for the rest of the paragraph, remember most pensioners are incapable, incoherent and  incontinent, so yes, it's possible entire countries would go dark. ( I know, I just won the bad pun of the year award)

 

No, no. I understand all that. What I don't understand is what point Coffee is trying to make by pointing that out. No one suggested blocking vintage hardware, so why make that argument as if someone was suggesting we do it? SL would also lose a lot of concurrency if we banned all residents whose usernames include vowels, but it wouldn't make any sense for me to point that out as a response to this thread because no one in this thread has voiced an anti-vowels stance.

[Penny Patton]

2 hours ago, arabellajones said:

Yes, but I am not confident that some of the big name, high sales, creators could optimise their way out of a soggy wet paper bag. Rather than learn just how to do their job, they start screaming "It's a bug!", and go on to do nothing.

Sure, but you point out yourself that LL has done a bad job of communicating just why optimization is necessary. My position has always been that LL needs to do better in this regard, I strongly believe there should be an official content creation blog, using Linden/Mole created content as examples of how to optimize and why it's important. I also believe LL should provide better tools to content creators to help make optimizing easier. In any case, many content creators might not know how to optimize right now, but that's largely because they've never tried. Put them in a position where they have to optimize their content better and they'll figure it out pretty fast. It doesn't require any skills they don't already have if they're making content in the first place.

If they won't learn, there are plenty who will be more than happy to take their business.

[Ana Stubbs]

12 minutes ago, Penny Patton said:

No, no. I understand all that. What I don't understand is what point Coffee is trying to make by pointing that out. No one suggested blocking vintage hardware, so why make that argument as if someone was suggesting we do it? SL would also lose a lot of concurrency if we banned all residents whose usernames include vowels, but it wouldn't make any sense for me to point that out as a response to this thread because no one in this thread has voiced an anti-vowels stance.

As I understand it, the current issue is that some old computers misreport the amount of graphics memory available. If SL believes them and tries to fill it, the viewer crashes in such a way that you can't then get in and change the setting, effectively blocking them from SL.

This was briefly refered to in passing in a TPV developer's meeting, so it's no wonder you're a bit confused. I only happened to hear about it because there's sufficent gibberish in those for the recordings to make nice background noise while I work.

[Penny Patton]

36 minutes ago, Ana Stubbs said:

This was briefly refered to in passing in a TPV developer's meeting, so it's no wonder you're a bit confused. I only happened to hear about it because there's sufficent gibberish in those for the recordings to make nice background noise while I work.

Ok yeah, I think I understand now. I'm not sure how it prevents them from changing the setting. Is it not something they can change from preferences on the log-in screen, before actually logging in?

Edited July 1, 2019 by Penny Patton

[Profaitchikenz Haiku]

37 minutes ago, Penny Patton said:

Is it not something they can change from preferences on the log-in screen

I just tried and with an un-crashed viewer, yes, you can change it. What I don't know is if a crashed viewer would be unable to display the screen at all, or the preferences, because it's the same rendering engine driving the UI as drives the inworld view? (in the incidents where I have had the screen go to garbage I have always been able to simply restart the browser)

Big thanks to Ana for this information, I had dropped the graphics memory from 1024 to under 512 on the machine with a GT710 card because of repeated crashes when visiting some places with lots of mesh buildings in close proximity. It's now much more reliable and only gives me the speckled up-chuck pattern if I encounter too many mesh avatars. Nice to have an explanation for what was really just a blind guess.

Edited July 1, 2019 by Profaitchikenz Haiku
lepsling

[Coffee Pancake]

13 hours ago, Penny Patton said:

I'm not sure what you mean by this post.

I agree that blocking older hardware would be a bad idea.....but unless there's a post I'm just not seeing, I don't think anyone suggested blocking hardware.

That the stock viewer is capped at 512 because that's been an ok default value that hasn't cause problems for most users. Asking the host OS how much VRAM there is seems like something SL should base the allocation on .. the problem is a lot of machines just outright lie about how much VRAM there is .. and when SL tries to use it, very bad things happen. 

The only practical solution is draw a line and unchain the VRAM allocation from legacy machines, in the case of SL that isn't an option. LL are stuck and blind between two big rocks, so have opted to do nothing for years in the hope that this older hardware would just naturally go away, only SL hasn't remained static in that time. It's an SL developers Kobayashi Maru.

13 hours ago, Penny Patton said:

And if anything, the fact that so many SL users rely on older or less expensive hardware is yet another reason why optimization is so important. As I demonstrated, even a laptop with onboard graphics can run SL on medium settings at a respectable framerate and no other performance issues in environments with bare-bones optimizations to the content.

That imaginary old hardware you had in mind when writing that paragraph is waaay too new. If SL could magically be 50% faster it wouldn't be enough to matter.

13 hours ago, Penny Patton said:

 Up until it died, my backup SL computer was a Toshiba Portege from 2007. I was able to use that with deferred rendering enable and still get around 20fps. And no, that's not a typo, the laptop was released in 2007. Onboard Intel graphics, no videocard. Could run SL with deferred rendering enabled and at around 20fps. I used it regularly when I was away from home. I couldn't leave the safety of those optimized sims, it would crash almost immediately anywhere else, but as long as I stayed in a handful of sims that weren't overburdened with excessive texture use, and I derendered avatars with excessive textures, I could run SL better than a lot of people experience with much more powerful machines.

Yeah, we're talking about entirely different classes of hardware.