Lag

[ChinRey]

1 hour ago, Solar Legion said:

If you need the equivalent of four entire Regions (linear) for that, there's a problem.

No.

Take a look at the images here: https://community.secondlife.com/forums/topic/462249-what-second-life-could-have-been/, particularly the second and 8th picture.

With 128 or even 256 m draw distance what you would have seen on those pictures were a few trees in the foreground, maybe a little bit of the road in picture no. 2 and a vast stretch of empty land behind.

The second to last picture too. That stretch of road was far longer than 128 m so with SL style draw distance you wouldn't actually have seen the end when you started driving down it.

I know this kind of big(ish) landscapes are all but impossible in SL as it has turned out anyway but to me at least this is an essential quality of a good virtual reality. If you feel otherwise, I suppose we just have to agree to disagree.

 

[Solar Legion]

1 hour ago, ChinRey said:

Take a look at the images here: https://community.secondlife.com/forums/topic/462249-what-second-life-could-have-been/, particularly the second and 8th picture.

With 128 or even 256 m draw distance what you would have seen on those pictures were a few trees in the foreground, maybe a little bit of the road in picture no. 2 and a vast stretch of empty land behind.

The second to last picture too. That stretch of road was far longer than 128 m so with SL style draw distance you wouldn't actually have seen the end when you started driving down it.

I know this kind of big(ish) landscapes are all but impossible in SL as it has turned out anyway but to me at least this is an essential quality of a good virtual reality. If you feel otherwise, I suppose we just have to agree to disagree.

 

We will indeed have to "agree to disagree" here, though for quite a different reason: That is not how Second Life is set up nor is it likely to be how it will be set up any time soon.

I saw the thread you've linked when it was initially posted and I rolled my eyes then, just as I am doing so now.

Furthermore the images there are of a Region (from a different but related system - OpenSim)) owned and operated solely by you. You chose to have it be more or less "empty space" (forest land with roads) and how long to make each stretch. That same space here in second Life could well be crammed full of varied buildings and roads, not to mention the occasional skybox.

Further missed in your response is that mine was directed at someone using such a massive Draw Distance for flight while stating they do so to avoid obstacles. Such a Draw Distance is not needed for such a use case. It simply isn't - if you're flying so fast that you "need" to see that far ahead, you need to slow down as you're crossing from one Region to the next far far too rapidly.

Edited October 4, 2021 by Solar Legion
"at" not "as"!

[Jennifer Boyle]

ChinRey, what was your monitor resolution? Some months ago, I did some tests. I found that the only variables under my control that affected fps were monitor resolution, draw distance, and shadows on/off. I found 1920x1080(HD), to be my best tradeoff, even though I have a 4K monitor. That was with an RTX 2080Ti graphics adapter and a 16-core CPU.

I, like you, am frustrated by SL's poor performance. I bought my current computer, a custom build, chiefly to get better SL performance, and I didn't.

Like you, when I am in a sim where I spend much time (so that textures should be in my maximum-size-permitted cache, which is on an SSD), I sometimes watch gray patches for a long time before textures load, yet nether my CPU no my graphics adapter is under much load at all.

 

[Profaitchikenz Haiku]

52 minutes ago, Jennifer Boyle said:

sometimes watch gray patches for a long time before textures load, yet nether my CPU no my graphics adapter is under much load at all.

I've been watching this on a couple of my machines wondering if an SSD would speed things up. However, I think it's more to do with the time it takes for the region to send your viewer the detail of the objects and their textures, and then your viewer has to look through the cache to see if it has that texture. A couple of people have pointed out that sometimes having a completely empty cache results in a faster population process than having things already cached there.

In another thread, Henri has pointed out that having the cache on an SSD might shorten it's life because of the number of writes: each time a texture is fetched from cache it's last access time is updated, this means writing back to the SSD, which involves he full strip of the filing system containing that data, so I'm currently sticking to metal oxide caches.

Edited October 4, 2021 by Profaitchikenz Haiku

[ChinRey]

1 hour ago, Jennifer Boyle said:

ChinRey, what was your monitor resolution?

Oh yes, I forgot to mention that. It's 1920x1080.

Edit: I should have mentioned that too:

19 minutes ago, Profaitchikenz Haiku said:

I've been watching this on a couple of my machines wondering if an SSD would speed things up.

My computer has an almost empty (for now) 1TB SSD as the main disk and a 2TB traditional harddisk as the secondary one. Everything SL related is on the SSD. (Everything else too come to think of it, the second disk is still empty).

 

Edited October 4, 2021 by ChinRey

[Jennifer Boyle]

7 hours ago, Profaitchikenz Haiku said:

I've been watching this on a couple of my machines wondering if an SSD would speed things up. However, I think it's more to do with the time it takes for the region to send your viewer the detail of the objects and their textures, and then your viewer has to look through the cache to see if it has that texture. A couple of people have pointed out that sometimes having a completely empty cache results in a faster population process than having things already cached there.

In another thread, Henri has pointed out that having the cache on an SSD might shorten it's life because of the number of writes: each time a texture is fetched from cache it's last access time is updated, this means writing back to the SSD, which involves he full strip of the filing system containing that data, so I'm currently sticking to metal oxide caches.

Actually, I doubt having it on the SSD helps. A few years ago, I tried putting the SL program folder, cache, and data files on a ramdrive, and it did not appreciably help performance.

I think that technical progress will make my SSDs ripe for replacement by the time they wear out.

Edited October 5, 2021 by Jennifer Boyle

[Jennifer Boyle]

This thread prompted me to try an experiment.

First, my system:

CPU: AMD Ryzen Threadripper 2950X 16-Core Processor  (3493.49 MHz)
Memory: 130946 MB
Concurrency: 32
OS Version: Microsoft Windows 10 64-bit (Build 19043.1237)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce GTX 1080 Ti/PCIe/SSE2
Graphics Card Memory: 11264 MB

NOTE: THIS WAS NOT INTENDED TO BE A SIMULATION OF NORMAL VIEWER USE. I INTENTIONALLY USED EXTREME SETTINGS FOR TESTING PURPOSES.

I wanted to first determine what my system's maximum fps was, and how it would decrease with changes in settings. I was using the latest version of Firestorm.I wore only the four required avatar components plus a full-body alpha. I placed myself at 128, 128, 3900 in a Linden water sim that had no other avatars in it and contained no content other than Linden and Mole-created objects (aquatic plants).

I set all graphics settings the the minimum possible values. I set the resolution to 800x600, and the draw distance to 4 m. The fps was 167, so that must be my maximum possible fps. First, I progressively increased resolution. At 1280x1024, fps was 150; at 1920x1080, 137; and at 3840x2160, 135. The I started progressively doubling draw distance; at 8 m, fps was 137; at 16, 133; at 32, 135; at 64, 140; at 128, 135; at 256, 127; at 315, 115; at 1024, 99.

Then I set the draw distance to 128. I put on a normal outfit, with avatar complexity about 70,000. The fps was 52, dramatically less. My avatar was NOT in my field of view.

Observations: With lowest graphics settings and essentially nothing to render, there is a modest decrease in frame rate as resolution is increased. Why?

Even though I was at 4000 m in an empty sim with lowest graphics settings, there was a significant decrease in fps with increased draw distance. Why?

Even though graphics settings were lowest, and my avatar was not visible to me, there was a drastic decrease in frame rate when I put on a normal avatar instead of the minimal, invisible one. Why? It just seems crazy that something that isn't being rendered would have that effect. Doesn't that have to be poor design?

 

Edited October 5, 2021 by Jennifer Boyle

[Echelon Alcott]

8 hours ago, Jennifer Boyle said:

Like you, when I am in a sim where I spend much time (so that textures should be in my maximum-size-permitted cache, which is on an SSD), I sometimes watch gray patches for a long time before textures load, yet nether my CPU no my graphics adapter is under much load at all.

Same experience here.

7 hours ago, Profaitchikenz Haiku said:

 A couple of people have pointed out that sometimes having a completely empty cache results in a faster population process than having things already cached there.

Again, I have the same experience here. It is inconceivable to me that rendering is faster when my cache is empty. What kind of caching algorithm are they using?!?! 

I've been using SL with my viewer cache set to the minimum allowed (256 MB).

7 hours ago, Profaitchikenz Haiku said:

In another thread, Henri has pointed out that having the cache on an SSD might shorten it's life because of the number of writes: each time a texture is fetched from cache it's last access time is updated, this means writing back to the SSD, which involves he full strip of the filing system containing that data, so I'm currently sticking to metal oxide caches.

Good point. Thanks for pointing that out. I'm glad that I set my cache to the minimum possible.

[animats]

Go look at all those gorgeous pictures on Strawberry Linden's blog. That's what SL content looks like. You just have to stay still in one place for a long time as the viewer slowly catches up before you can take the picture. Moving around normally in SL is looking at a world that's blurry and constantly glitching. That's not good enough any more. Any modern game that looks that bad is laughed off the market.

LL's Project Interesting was on the right track. But they got to 70% done and gave up.

If you make that work right, the whole user experience changes. Here's some window shopping in New Babbage.

Entomology shop. You can go inside and examine all those butterflies in detail.

Map store. Find the secret map of the tunnels.

Club. Go inside.

Furniture store window display

Graves Investigations. Many occult items of interest in glass cases.

Remember Belgium! If you look closely, it's an attack by the tripods from Mars.

Pharmacy. Every bottle is labelled.

This is another demo from my test viewer (log in and cam only). There's no long waiting for the detail to appear. These pictures were taken as fast as I could get positioned in front of the window. Within 1-2s of going somewhere, you have clear textures nearby.

The whole Second Life experience changes as the viewer speeds up. You can go and look at anything that looks interesting, without having to decide "is this good enough to spend a minute waiting for loading?" Suddenly SL starts to look like an AAA title.

So, quit worrying about trying to tame creators. Fix the viewer and server and make this thing show all that beautiful content.

[Lindal Kidd]

How long before your SuperUltraMegaViewer will be ready for public release???????????

[animats]

2 hours ago, Lindal Kidd said:

How long before your SuperUltraMegaViewer will be ready for public release?

I'm shooting for log in, move, and view in 2022.

[ChinRey]

11 hours ago, animats said:

So, quit worrying about trying to tame creators.

No.

I absolutely agree with you that the server and viewer sofware need to be fixed. The stats in my original post here is more than enough proof of that.

I also absolutely agree that it's impossible to fix all the problems inefficient assets create, not without starting over again with a new grid and possibly a new userbase too (which is an option of course but not for most of the current SL users).

But we have to do as much damage control as possible. There is no realistic limit to how many tris and pixels an inconsiderate content creator can cram into even the simplest object so if we only focus on the software side of the lag/load/fps issue, all we end up with is even more inefficient content wasting all that new power and more.

[Profaitchikenz Haiku]

I can see a middle way between Animats' proposal to fix the viewer and Chin Rey's wish to control the creators: and the mechanism for it seems to partly exist.

There are, in several TPV's, various option to limit the size of things, the complexity of things, the area of things, etc to be displayed by the viewer. Despite hover tips * for some of these there is little real explanation of how they work, where they should be used, how they could make a difference.

A good in-depth tutorial showing how a busy scene of the type mentioned by Animats, including a few quite complicated avatars, with examples of how to use some of these adjustments, would go a long way to educating us in how to adjust the myriad of settings that exist in order to be able to see what we would like to, move around, and at the same time not take 30 minutes of waiting patiently to do so.

* The majority of hover tips I have tried simply repeat the name of the items I wish to learn more about with a couple or so words that tell me nothing regarding how to use it or what difference it makes.

[ChinRey]

1 hour ago, Profaitchikenz Haiku said:

I can see a middle way between Animats' proposal to fix the viewer and Chin Rey's wish to control the creators: and the mechanism for it seems to partly exist.

I think I should point out that there is no real conflict between the fixing the software issues and fixing (or at least reduce as much as possible) the content ones. on the conrrary, they depend on each other. Fixing one without adressing the other is like replacing one tire on your car when two of them are flat.

[Lindal Kidd]

2 hours ago, Profaitchikenz Haiku said:

A good in-depth tutorial showing how a busy scene of the type mentioned by Animats, including a few quite complicated avatars, with examples of how to use some of these adjustments, would go a long way to educating us in how to adjust the myriad of settings that exist in order to be able to see what we would like to, move around, and at the same time not take 30 minutes of waiting patiently to do so.

Such a tutorial, completed successfully, ought to be a requirement when applying for the ability to upload mesh.

[Ardy Lay]

Is there a setting to not render avatars that exceed a specified number of "draw calls"?  That's what I want right now.  I'd do the old Romper Room Magic Mirror thing on the club stream, calling names of avatars whom I can see.

[ChinRey]

1 hour ago, Ardy Lay said:

Is there a setting to not render avatars that exceed a specified number of "draw calls"?

The number of draw calls isn't normally a big issue in SL, it's the number of tris and pixels that matter.

There is a setting that is supposed to do more or less what you are asking for, rendering heavy avatars as "jellydolls". Unfortunately it never worked because the method SL uses to calculate the render cost for mesh avatars is broken beyond repair.

Look at the first illustration in this post by Beq Janus:

https://community.secondlife.com/forums/topic/477056-why-alpha-cuts-are-bad-for-your-health/?tab=comments#comment-2351105

The thin line to the left of each name of the list represents the avatar's actual render load, the number beside it the load calculated by the viewer and used for the "jellydoll" function. As you can see, that function is totally useless and has always been totally useless.

[Ardy Lay]

4 hours ago, ChinRey said:

The number of draw calls isn't normally a big issue in SL, it's the number of tris and pixels that matter.

There is a setting that is supposed to do more or less what you are asking for, rendering heavy avatars as "jellydolls". Unfortunately it never worked because the method SL uses to calculate the render cost for mesh avatars is broken beyond repair.

Look at the first illustration in this post by Beq Janus:

https://community.secondlife.com/forums/topic/477056-why-alpha-cuts-are-bad-for-your-health/?tab=comments#comment-2351105

The thin line to the left of each name of the list represents the avatar's actual render load, the number beside it the load calculated by the viewer and used for the "jellydoll" function. As you can see, that function is totally useless and has always been totally useless.

Read that article again and see why bunches of "alpha cuts" slow rendering.  Alpha cuts apparently cause more draw calls, draw calls are slow, slow is measured in that graph.

[ChinRey]

1 hour ago, Ardy Lay said:

Read that article again and see why bunches of "alpha cuts" slow rendering.  Alpha cuts apparently cause more draw calls, draw calls are slow, slow is measured in that graph.

Oh, I'm not at all suggesting that the number of draw calls doesn't matter and it certainly not something we should ignore - unless LL comes up with a Vulkan based viewer that is (Vulkan doesn't use draw calls the way OpenGL and DirectX do). But it's still the bloated pixel and tri/vertice counts and also the three fitmesh LoD bugs that are the biggest problems when it comes to lag caused by content.

[animats]

Has anyone tried the new LL "mesh optimization" project viewer yet?

I'd appreciate comments and samples. I don't upload enough meshes to really test this properly. Is this a good fix to the bad LOD problem?

Things to check:

• If you upload something, and ask for maximum reduction, do you get holes? It should stop reducing rather than emitting a broken model.
• On thin objects, like clothing, does it preserve the outer edges, or does it start trimming back the fabric? Again, it should stop reducing before emitting a broken model.
• Does it mess up on non-watertight meshes?

Vir Linden mentioned that it's an open source quartic mesh optimizer. That means it tries to minimize the error volume between the original and reduced meshes. That approach is very effective for well-defined volumes. Non-watertight meshes may be troublesome, because of inside/outside ambiguity. So please try this on some SL content of your own. This is an LL product, so report bugs via JIRA.

 

[ChinRey]

15 hours ago, animats said:

Has anyone tried the new LL "mesh optimization" project viewer yet?

I'd appreciate comments and samples. I don't upload enough meshes to really test this properly. Is this a good fix to the bad LOD problem?

I think not. Here is a quick test. Left to right:

• High LoD model (1282 tris)
• Optimized (manual) mid LoD model (480 tris)
• GLOD mid LoD strenghtened (640 tris)
• GLOD mid LoD default (320 tris)
• MeshOptimizer mid LoD default (428 tris)
• MeshOptimizer low LoD default (142 tris)
• MeshOptimizer lowest LoD default (20 tris)

With textures (and white specular maps):

I only included the mid LoD, not low and lowest for the optimized and GLOD options but the tri counts for the optimized low and lowest models are 70 and 18 respectively and they do of course look considerably better than the MeshOptimizer ones. The reason why MO's low and lowest models can be smaller than the high and mid models is that this mesh uses a loose vertice above the actual model to adjust LoD swap distances.

I think we'll all agree that although neither delivered a usable result, GLOD actually did "better" than the new MeshOptimizer. This is just one test though and it's possible it'll perform better with other objects. Even so, I think it's fairly obvious it isn't good enough to keep.

Edited October 7, 2021 by ChinRey
Typos

[Jennifer Boyle]

Under the TOS, LL can do whatever it wants with everything that is uploaded. To this non-techie, it seems like it would be possible to devise algorithms and, therefore, write code to optimize content. I wouldn't expect it to do as well as a skilled human being, but surely it could make badly-designed content better. Why can't this be done?

Also, couldn't code identify really bad content and the server just reject it? Just because it was good enough 20 years ago doesn't mean it's good enough now.

We need better performance, and if some old or badly-made content has to go for us to get it, so be it.

[LittleMe Jewell]

1 hour ago, Jennifer Boyle said:

To this non-techie, it seems like it would be possible to devise algorithms and, therefore, write code to optimize content. I wouldn't expect it to do as well as a skilled human being, but surely it could make badly-designed content better. 

In theory, yes.  Reality is a different beast all together. 

LL's mesh uploader already will create the lower LOD models for you, but for anything other than the simplest things, it does it poorly. 

As ChinRey showed in the post right before yours, their new mesh optimization produces crappy stuff.

Those are 2 things that LL created that supposedly will make good mesh, but doesn't.

[ChinRey]

1 hour ago, Jennifer Boyle said:

To this non-techie, it seems like it would be possible to devise algorithms and, therefore, write code to optimize content. I wouldn't expect it to do as well as a skilled human being, but surely it could make badly-designed content better. Why can't this be done?

Because it's a combination of technique, art, creativity, intuition, experience, strict logic and crazy out-of-the box thinking.

Computers don't think, they don't see and they are not creative. All they can do is slavishly follow the rules established by the developers and a million developers working together still couldn't manage all the possible situations the computer would need to handle in a complex free form visual environment like Second Life.

It is actually possible to find a compromise between cold, objective computer logic and warm, subjective human creativity but it'll have to be concsiously done that way right from the start. Prims are a very good and very simple illustration how it can be done. They are based on some very simple mathematical rules that a computer can easily handle but they have still turned out to be amazingly flexible and open for artistic creativity. Unigine's incredible Valley Benchmark is another example. (I'll add a one hour (don't worry you don't have to watch it all) video collage from it at the end of the post for those who don't want to download it themselves). The plants, rocks and terrain are all procedural, created from relatively simple mathematical formulas and thus easy for a computer to understand and manipulate.

This require a completely different approach to the buiding process though. Rather than capricious free form modelling, we have to create by changing parameters in the formulas. I know, that sounds very complicated and counter-intuitive but it isn't actually. It is exactly what we do when we build with prims and for most people it's actually a much easier way to create than free form polylist mesh building.

Here's the Valley Benchmark video. As I said, you don't have to watch all of it and I really suggest you download the actual demo so you can walk through it, not just follow the premade camera pans.

 

 

Edited October 7, 2021 by ChinRey

[animats]

6 hours ago, ChinRey said:

Even so, I think it's fairly obvious it isn't good enough to keep.

OK, please make sure Vir Linden gets that message.

What's going wrong here is applying quadric optimization to a thin shell. Note that the vase is hollow. The optimizer is trying to minimize the error volume, which is all wrong for a thin object. Roughly the same mesh optimizer is available in Blender, so you can try this.  Here's a good way to see this in Blender.

• Create a cube.
• Rescale it down to a thin, but nonzero thickness, sheet. Apply the scaling to the mesh.
• Subdivide the mesh so that you have about 5x5 squares on each of the big faces. You now have a flat piece of thin "cloth".
• In edit mode, grab the central square of the big faces, on both faces, and pull it a bit out of the sheet. You've now put a "wrinkle" in the cloth.

Try Blender's quadric mesh reduction on that. It won't flatten the "wrinkle". It will pull in the edges. Why? Because that's what changes the volume error between original and reduce version the least. That algorithm does not understand "thin sheet" at all.

This is an indication that any mesh optimization for SL clothing has to be thin sheet aware.

There are better mesh optimizers, but they are not free.