Second Life - Performance Thread

[gwynchisholm]

58 minutes ago, Love Zhaoying said:

Being "wrong" or "politically incorrect" (the only serious options I see) are unethical? Today I learned something new!

In the context of a forum where people are asking questions or looking for answers, even in topics where questions and answers aren’t direct, people do look for answers to issues. You see the same occasional necrobump as all of us where someone googled a problem, and found an ages old thread about it. People do read through this stuff for troubleshooting.

That is the ethically related part. Ie forum etiquette, give specific answers not generalized ones, unless a generalized question requires a generalized answer.

Being objectively wrong is different than presenting inapplicable information.

Edited December 18, 2023 by gwynchisholm
Ethnic to ethic

[Love Zhaoying]

12 minutes ago, gwynchisholm said:

In the context of a forum where people are asking questions or looking for answers, even in topics where questions and answers aren’t direct, people do look for answers to issues. You see the same occasional necrobump as all of us where someone googled a problem, and found an ages old thread about it. People do read through this stuff for troubleshooting.

That is the ethnically related part. Ie forum etiquette, give specific answers not generalized ones, unless a generalized question requires a generalized answer.

Being objectively wrong is different than presenting inapplicable information.

Yep. I bet all the people looking for actual answers hate the trolling and mean-spirited responses. But it's a forum, not a help desk.

I assume you again meant "ethically", as "ethnic" discussions are mostly verboten.

14 minutes ago, gwynchisholm said:

That is the ethnically related part.

 

[gwynchisholm]

25 minutes ago, Love Zhaoying said:

I assume you again meant "ethically", as "ethnic" discussions are mostly verboten.

Autocorrect got me, the joys of an ipad

[filz Camino]

5 hours ago, Henri Beauchamp said:

Sure... After all, with only 16+ years of viewer development and feedback from the users of my viewer, myself having been running SL with only 10 different GPUs, I probably should not give such an advice: I'm not experienced neither competent enough... 🙄

i agree - it certainly looks that way to me, given that your advice is incorrect for me personally.

perhaps in another 16 years, you will have learned that software can respond very differently depending on how it is used and what specific hardware it is running on. and perhaps you will have finally learned the biggest lesson - quite often someone is using some software in ways we personally hadn't actually imagined and accounted for.

my best wishes for you on your continued journey of learning!

[filz Camino]

6 hours ago, gwynchisholm said:

My personal experience is very different than that sentiment about texture compression. From my uses so far, its barely noticeable outside of some terrain items where youre already seeing a pretty blown up texture. And it doesnt really cause me any issues with performance. Its impact is also negligible as far as system utilization goes. 

that's interesting - i guess it really is going to depend on the specifics of the situation. the tests i did in Peak nightclub (when i noticed my 12Gb of vram was being exceeded) was that turning on compression resulted in vram usage falling almost 50%. i don't think i've been in a situation where i have run out of vram since turning it on.

[filz Camino]

6 hours ago, Love Zhaoying said:

I'm confused. Are you saying we can't make blanket statements, or that we would merely be factually incorrect in making those statements? If we can't make the blanket statements, who will stop us from doing so?

It's so confusing.

 

we are saying that blanket statements are often incorrect in some contexts, so should be avoided. 

it is far better to say things like "texture compression TENDS to be a bad idea" (make the claim non-absolute and allow for possible exceptions) than "texture compression IS a bad idea" (an absolute truth claim, that makes no space for possible exceptions).

if course people can make (unhelpful and partially incorrect) blanket statements, as have been demonstrated in this discussion! 

Edited December 18, 2023 by filz Camino

[AmeliaJ08]

12 hours ago, gwynchisholm said:

Which was founded on whats now tech more than a decade old, for a viewer more than a decade old. In that scenario it was mostly the Radeon HD3000/4000 series that were having issues with OpenGL games in general and were performing worse than their nvidia counterparts. This was resolved with driver updates, and wasnt a concern at all for later Radeon HD cards, or the R9 series, or Polaris or Vega, etc. But still every so often i see the same blanket statement thats founded in an issue from 2008.

That isn't true. AMD had OpenGL performance issues up until quite recently and even to this day you will find OpenGL performance does not match a comparable Nvidia card, it's a lot closer than it used to be though.

That's all that advice stems from, it wasn't some baseless claim relating to obsolete cards like the HD series. The gap was only closed quite recently in 2022: https://arstechnica.com/gadgets/2022/09/rewritten-opengl-drivers-make-amds-gpus-up-to-72-faster-in-some-pro-apps/

That isn't to say AMD are not an option, the performance is more than adequate now but given SL's glacial performance on just about all hardware it was an issue that AMD hardware had a significant performance penalty in OpenGL up until quite recently.

 

 

Edited December 18, 2023 by AmeliaJ08

[JeromFranzic]

7 hours ago, filz Camino said:

that's interesting - i guess it really is going to depend on the specifics of the situation. the tests i did in Peak nightclub (when i noticed my 12Gb of vram was being exceeded) was that turning on compression resulted in vram usage falling almost 50%. i don't think i've been in a situation where i have run out of vram since turning it on.

This. Even with an older 1050 with 4 GB VRAM, I've very rarely encountered instances where I've run out of VRAM with texture compression turned on. Then again I tend to cap my dd at 128m or less most of the time and (so far) don't go beyond mid settings for PBR.

I think the VRAM autodetection for PBR is working for me. Doesn't matter if I'm in Windows or Linux, but my Linux install gives me better OS overhead vs Windows.

I've usually got some antialiasing on so my photos aren't affected much. I post-process a bit anyway. Without tc, I don't think I'd be able to tolerate virtually moshing at a club. Of course I turn off shadows (and sometimes ALM) in such areas.

[Kyrah Abattoir]

If this is any consolation, Vrchat, (the other major platform that's 100% user generated content also runs horribly. 40 people events are a slideshow unless you drop your "max rendered avatars", it could be worse, but there are quirks to the platform that limit the damage players can do.

Just like in SL, most vrchat content creators do not care about the rating of the avatars they sell because the users don't care, and therefore, no one is paying for that.

Just as with SL, it is mostly a content problem.

 

[animats]

From my perspective with Sharpview, SL non-avatar content complexity is a manageable problem. Land impact keeps things from getting so bad the GPU can't handle them. Avatars, though...

To solve this, we need some kind of mesh baking that happens on a clothing change. Like  bakes on mesh, but operating on the meshes themselves, not just textures.  Simplify stacked layers. Combine meshes. Discard triangles that can't possibly appear. Mesh reduce. Bake down to a one-piece animesh.

There are tools for this, but not for SL. Anyone tried Mesh Baker?

[Gabriele Graves]

11 minutes ago, animats said:

From my perspective with Sharpview, SL non-avatar content complexity is a manageable problem. Land impact keeps things from getting so bad the GPU can't handle them. Avatars, though...

To solve this, we need some kind of mesh baking that happens on a clothing change. Like  bakes on mesh, but operating on the meshes themselves, not just textures.  Simplify stacked layers. Combine meshes. Discard triangles that can't possibly appear. Mesh reduce. Bake down to a one-piece animesh.

There are tools for this, but not for SL. Anyone tried Mesh Baker?

That means saying goodbye to wearing animesh pets or any item that changes it's appearance via a script including a mesh body/head.

[animats]

49 minutes ago, Gabriele Graves said:

That means saying goodbye to wearing animesh pets or any item that changes it's appearance via a script including a mesh body/head.

You can still have rigged mesh doing its thing. The GPU does the work on rigged mesh.

[Gabriele Graves]

12 minutes ago, animats said:

You can still have rigged mesh doing its thing. The GPU does the work on rigged mesh.

Rigged mesh often comes with scripts to change the texture of faces, set glow, lighting for objects in the linkset.  Clothing has scripts that control alphas, textures, etc.  Mesh bodies/head have scripts that control all kinds of things from setting eye lashes , HD layers, materials, etc.  Rigged mesh hair has colour change scripts.  None of this will work if it is smooshed together so that there is one object with a simplified set of faces.

The idea only works when you only wear non-scripted objects for all rigged mesh and looking at what I wear, the majority of them have scripts in them either that or the whole thing has to be regenerated once you make any scripted change.

Edited January 9 by Gabriele Graves

[animats]

25 minutes ago, Gabriele Graves said:

Rigged mesh often comes with scripts to change the texture of faces, set glow, lighting for objects in the linkset.  Clothing has scripts that control alphas, textures, etc.  Mesh bodies/head have scripts that control all kinds of things from setting eye lashes , HD layers, materials, etc.  Rigged mesh hair has colour change scripts.  None of this will work if it is smooshed together so that there is one object with a simplified set of faces.

The idea only works when you only wear non-scripted objects for all rigged mesh and looking at what I wear, the majority of them have scripts in them either that or the whole thing has to be regenerated once you make any scripted change.

Yes. Some changes will require re-generation. That's true of BOM now.

[Gabriele Graves]

1 minute ago, animats said:

Yes. Some changes will require re-generation. That's true of BOM now.

Even with that, items that animate frequently (not animesh) wouldn't be possible anymore or they would probably cause too many updates for regeneration.  BoM is a much simpler proposition than this.

[Henri Beauchamp]

5 hours ago, animats said:

There are tools for this, but not for SL. Anyone tried Mesh Baker?

This won't work for real-time mesh baking. This is for games with pre-defined assets, not for SL... Plus, it's closed source and a commercial (paying) software.

Note also that the SL viewer does make use of (moderate) mesh optimization (see LLVolumeFace::cacheOptimize()), itself recently updated to use meshoptimizer, but this optimization step, happening each time a new mesh is loaded, won't combine meshes together...

Edited January 9 by Henri Beauchamp

[gwynchisholm]

On 1/8/2024 at 8:55 PM, Kyrah Abattoir said:

If this is any consolation, Vrchat, (the other major platform that's 100% user generated content also runs horribly. 40 people events are a slideshow unless you drop your "max rendered avatars", it could be worse, but there are quirks to the platform that limit the damage players can do.

Just like in SL, most vrchat content creators do not care about the rating of the avatars they sell because the users don't care, and therefore, no one is paying for that.

Just as with SL, it is mostly a content problem.

 

The difference is vrchat uses unity and it will always run kinda bad. However that engine choice way better utilizes modern hardware, even if it’s not perfect, it’s doing a lot more under the hood than sl is. And the biggest part for that is that it’s easier for them to implement assorted fixes to optimize the game better for the content in it.

For what VRchat is doing on a technical level, it is running exceedingly well on the average users hardware. Smooth and simple 3D models aside, realtime body and facial tracking with model deformation and stretch and all that isn’t easy to pull off and have it run well. It’s why they counteract that aspect of it with otherwise fairly low detail environments, models and textures. 
You can’t exactly stare at the pores and real time lighting and material effects on your vrchat avatar like you can in secondlife. But that is why it kinda looks like an Xbox 360 game to balance that out.

TLDR for what it is, its optimized very well, and they can do more

they only recently added the impostors style avatar rendering for crowds that SL has had for years, because their mobile app version ran bad without it

Non optimized user created content is a problem that’s difficult to manage, but the biggest issue for SL is that this game doesn’t utilize hardware well enough to brute force through it. What’s on our screens in SL is not technologically impressive, it just isn’t able to process it all. My cpu has 1 core pegged to the ceiling trying to manage the lighting and geometry while my GPU twiddles its thumbs filling all 16gb of vram with textures it can only compress so far. 
VRchat on unity is multithreaded, lighting on it means nothing, and it scales with core count. The GPU is focusing on its job of actually rendering frames since it’s not being held back waiting for the CPU. The real limitation there is geometry which is just outright demanding as all hell for that game. Unoptimized content doesn’t help, but it’s nowhere near as much of an issue in terms of texture use or prop item complexity. And really isn’t the core issue on either game. In vrchat the issue for user created content is model complexity, since all of that has to move and stretch and deform rapidly and reactively, versus sl and its static animations which are far easier to compute.

Two different games with two different performance related problems to overcome.

[Kyrah Abattoir]

On 1/13/2024 at 11:16 PM, gwynchisholm said:

(long quote)

SecondLife is built under the assumption that all assets are potentially subject to changes, this is very hard to optimize when 99.99% of games out there all use "cooked" content: Every asset that can be considered static is optimized as such and once you know what will never change you can do all kinds of advanced culling methods.

Yes SL isn't exactly cutting edge in a lot of its approaches, but the core philosophy of its design makes most common optimization approaches impossible.

We would be in a different situation is, let's say, SL had embraced a low-fi aesthetic more suitable to a streamed world but LL has been completely hands-off on content guidelines. And so users decided that they want SL to look like an AAA game, despite the fact it simply cannot do that AND run well.

You can't blame a hummer for being unable to outrun an F1.

[TheBenchmarker]

Hi! I lost track of this topic a long time ago but I'm happy to see I did kick off some sort of discussion. I've made a twitter (x) account: @TBenchmarkerSL

I will be posting the results of my testing there and on here, I hope to get some new hardware soon so I can continue testing.

[animats]

On 1/16/2024 at 2:02 AM, Kyrah Abattoir said:

SecondLife is built under the assumption that all assets are potentially subject to changes, this is very hard to optimize when 99.99% of games out there all use "cooked" content: Every asset that can be considered static is optimized as such and once you know what will never change you can do all kinds of advanced culling methods.

Yes SL isn't exactly cutting edge in a lot of its approaches, but the core philosophy of its design makes most common optimization approaches impossible.

Not impossible, just hard. Most games do their baking and optimization at content creation time. SL does some of that work at upload time. That could work better, and might in the glTF era, because more optimization technology is available now than was available when SL added mesh. There's been a lot of progress in LOD generation in recent years.

SL squeezes the lower LODs far too much, and the higher LODs not enough. That needs a redo. There's really no reason to reduce mesh below 50-100 triangles when a GPU is doing most of the work. It doesn't save any scarce resource to go down to those awful 1-triangle see-through building faces. Lower LOD limits should be more generous.

On the other hand, allowing 20,000 triangles for the highest LOD of a shoe is pointless. That should be forced through mesh reduction somewhere in the asset pipeline. Most of the real drag on the system is avatar clothing. Non-avatar objects have LI limits, which discourages such insanity.

This is why I write about the potential of doing some work on meshes during clothing changes. That's the first time that all the layers, meshes, and textures come together. If you're not within touching distance of another avatar, you should be seeing a compact version that's basically an automatically generated animesh. If you get close enough, you get the full avatar and can still read the inscription on their bracelet and count the facets on the jewels of their rings. One SL creator referred to seeing such details, only half-jokingly, as "essential SL functionality".

This is a hard problem, but not impossible. We have 2D avatar impostors now, although they're not very good.

[AmeliaJ08]

10 hours ago, animats said:

Not impossible, just hard. Most games do their baking and optimization at content creation time. SL does some of that work at upload time. That could work better, and might in the glTF era, because more optimization technology is available now than was available when SL added mesh. There's been a lot of progress in LOD generation in recent years.

SL squeezes the lower LODs far too much, and the higher LODs not enough. That needs a redo. There's really no reason to reduce mesh below 50-100 triangles when a GPU is doing most of the work. It doesn't save any scarce resource to go down to those awful 1-triangle see-through building faces. Lower LOD limits should be more generous.

On the other hand, allowing 20,000 triangles for the highest LOD of a shoe is pointless. That should be forced through mesh reduction somewhere in the asset pipeline. Most of the real drag on the system is avatar clothing. Non-avatar objects have LI limits, which discourages such insanity.

This is why I write about the potential of doing some work on meshes during clothing changes. That's the first time that all the layers, meshes, and textures come together. If you're not within touching distance of another avatar, you should be seeing a compact version that's basically an automatically generated animesh. If you get close enough, you get the full avatar and can still read the inscription on their bracelet and count the facets on the jewels of their rings. One SL creator referred to seeing such details, only half-jokingly, as "essential SL functionality".

This is a hard problem, but not impossible. We have 2D avatar impostors now, although they're not very good.

I've always wondered about the "jellydoll" avatars, how exactly are they generated? they aren't very good but does the appearance of them update or anything?

[Jackson Redstar]

all these devs in the comments here melting my brain with technical explanations.  Are there any good debug setting we can set to increase visual performance? I remember back in the old days there was settings like MeshTriangles or something and Triangle-something, damn i can't remember them now, but is there anything someone with a 'powerful enough' computer can do to, when it comes to tweaking debug settings, to improve visual performance?

[Flea Yatsenko]

6 minutes ago, Jackson Redstar said:

all these devs in the comments here melting my brain with technical explanations.  Are there any good debug setting we can set to increase visual performance? I remember back in the old days there was settings like MeshTriangles or something and Triangle-something, damn i can't remember them now, but is there anything someone with a 'powerful enough' computer can do to, when it comes to tweaking debug settings, to improve visual performance?

Lower draw distance, increase LOD (usually Object in graphics settings). Best way for higher image quality with better performance. And disable MSAA. It kills my performance when there's alpha masked textures, like plants.

Draw distance is huge, look at this area of a circle calculator

https://www.mathsisfun.com/geometry/circle-area.html

Notice how area goes from 804 at 32m view distance to 3216 at 64m view distance. That area is all filled with stuff your computer needs to render, download, etc. The less area your computer has to render stuff, the less it has to render (most of the time, there are exceptions) so the better it's going to run.

[Jackson Redstar]

29 minutes ago, Flea Yatsenko said:

Lower draw distance, increase LOD (usually Object in graphics settings). Best way for higher image quality with better performance. And disable MSAA. It kills my performance when there's alpha masked textures, like plants.

Draw distance is huge, look at this area of a circle calculator

https://www.mathsisfun.com/geometry/circle-area.html

Notice how area goes from 804 at 32m view distance to 3216 at 64m view distance. That area is all filled with stuff your computer needs to render, download, etc. The less area your computer has to render stuff, the less it has to render (most of the time, there are exceptions) so the better it's going to run.

OK I should clarify. I am looking at this from the perspective of creating video in world. Lowering draw distance is not always an option, Turning off Dynamic Draw helps keeps things rezzed but it can really degrade performance. And MSAA - Im not even sure that is.

[AmeliaJ08]

2 hours ago, Jackson Redstar said:

all these devs in the comments here melting my brain with technical explanations.  Are there any good debug setting we can set to increase visual performance? I remember back in the old days there was settings like MeshTriangles or something and Triangle-something, damn i can't remember them now, but is there anything someone with a 'powerful enough' computer can do to, when it comes to tweaking debug settings, to improve visual performance?

There really isn't much beyond disabling any extraneous stuff you might not need. Shadows, projector lighting etc but I would guess you want all this given you're doing machinima.

If you can tolerate lower quality shadows then it is worth playing with that slider, does have a significant effect in my experience. If you're using a current version of viewers you probably don't have this setting but it's worth checking that Streamed VBO's are enabled, have seen some weirdness with some viewers disabling this and the performance penalty is large. Same goes for texture memory settings, ensure that your viewer is actually using all available video memory.

Ensure your cache settings are maxed out at 10GB, you want that VRAM to be filled/re-filled from a large fast SSD cache to avoid any stutters.

LOD factor also isn't really an option in your case since you probably cannot tolerate how jankily it will behave if you're doing machinima...

Your best solution is probably turning dollars into hardware I'm afraid

 

edit: for what it is worth I do find that the PBR-era viewer runs faster on modern hardware than previous viewers did, if you're holding out and not using the Firestorm beta for example there is possibly some performance on the table.

 

 

Edited April 4 by AmeliaJ08