Lag

[Qie Niangao]

2 hours ago, Profaitchikenz Haiku said:

The keynote here I'm trying to make is that it's the application of the script that really determines how to compile it, not just a desire to always attain the fastest possible runtime performance.

I guess, but the range of applications for which Mono is at a disadvantage is pretty narrow. Again, for smaller scripts, Mono will use less memory, as well as perform faster—and that performance isn't so much about a script's own responsiveness but more about its effect on other competing scripts in aggregate: script lag.

[Solar Legion]

5 hours ago, Desiree Moonwinder said:

When on my standalone SIM, I put my draw distance to 4096 so that I can build from top to bottom without bothering to move my avatar.  I do have a couple of spotter Alts that I stand near the points I'm building, so I can cam back and forth with radar. 

I have mainland experience and stitched-together region experience, and so I'm telling you from experience the only way to get performance in SL for combat and such is to have a single stand-alone region.  That's just the beginning of course.  You also have to keep inworld scripts low and meshes reasonable. 

That's nice.

All it changes is the addition of specific edge cases and clarification of my statement to concern most other cases.

In short: You're an edge case. No one should be using such a high Draw Distance as a go to, day to day setting. No one should be using such a high Draw Distance for vehicular transit.

You prefer to build in such a manner - that's lovely.

As for the second half? Nothing at all to do with keeping a reasonable Draw Distance.

Edited October 12, 2021 by Solar Legion

[Qie Niangao]

6 hours ago, Desiree Moonwinder said:

When on my standalone SIM, I put my draw distance to 4096 so that I can build from top to bottom without bothering to move my avatar.  I do have a couple of spotter Alts that I stand near the points I'm building, so I can cam back and forth with radar. 

But… isn't draw-distance measured from the cam location, regardless of avatar location? If the cam is moved down to these spotter alts, then that becomes the center of the draw distance, right?

(There used to be an oddity that the six nearest non-ALM point lights were measured in proximity to the avatar, not the cam, but I have no idea if that changed or if there may be other oddities, still.)

[Desiree Moonwinder]

4 hours ago, Qie Niangao said:

But… isn't draw-distance measured from the cam location, regardless of avatar location? If the cam is moved down to these spotter alts, then that becomes the center of the draw distance, right?

The performance is inconsistent.  If you pop draw distance to 4096, everything works all the time.  At draw distance of 256 * SQRT(2), which is the SIM diagonal, sometimes radar won't let you cam to the spotter alt 2000 meters away.  It seems to change with server and viewer updates.  I have not tested it again this week. 

[Desiree Moonwinder]

quote borked

Edited October 12, 2021 by Desiree Moonwinder
quote borked

[Desiree Moonwinder]

5 hours ago, Solar Legion said:

In short: You're an edge case. No one should be using such a high Draw Distance as a go to, day to day setting. No one should be using such a high Draw Distance for vehicular transit.

Well, let me give you another example.  I have an Intel i9 and an Nvidia GTX 2080 Ti, which I bought as the top-of-the-line on 2000-series launch day (a Titan card overtook it some months later).  I have a custom build computer on the way with an Nvidia GTX 3090, but I doubt it will help much with SL; I'm buying it to render in Blender.  

I am at a muti-SIM roleplay area.  There are only six avatars within my draw distance. I am only getting twelve (12) frames a second.  

I am running the default graphics settings that Firestorm thinks I should run: 128-meter draw distance, one step down from Ultra Quality, which means Advanced Lighting Model on and Ambient Occlusion off.  

The bottom line is SL performance is just awful in multi-region configurations, period.  You have to go to a skybox or a stand-alone region to get good performance, even with top-flight hardware. 

It is the norm for SL graphics performance to be awful, even with great hardware.  Getting good performance requires you to have a region build that is itself a corner case. 
 

[ChinRey]

1 hour ago, Desiree Moonwinder said:

The bottom line is SL performance is just awful in multi-region configurations, period.  You have to go to a skybox or a stand-alone region to get good performance, even with top-flight hardware.

It would of course be possible on a separate continent far away from the usual SL clutter but it would cost you an arm and a leg with the tier prices LL charges.

Edit: I'm curious, how do you get 4096 m draw distance? Firestorm caps it at 1024. Is there another viewer that gives you more?

Edited October 12, 2021 by ChinRey

[Desiree Moonwinder]

10 minutes ago, ChinRey said:

Edit: I'm curious, how do you get 4096 m draw distance? Firestorm caps it at 1024. Is there another viewer that gives you more?

Type in local chat:

dd 4096

Then your draw distance is 4096.  

[Solar Legion]

Again, that's nice.

Bottom line: For normal use (and as a general rule) one should not be using higher than 256 meters (an entire region) for the majority of their activities. As far as I am concerned that is simply how it is at present.

[ChinRey]

7 minutes ago, Desiree Moonwinder said:

Type in local chat:

dd 4096

Then your draw distance is 4096.  

Aww, thanks a lot!

[ChinRey]

3 minutes ago, Solar Legion said:

For normal use (and as a general rule) one should not be using higher than 256 meters (an entire region) for the majority of their activities. As far as I am concerned that is simply how it is at present.

Yes, unfortunately that is how it is at present.

But this is Ruritania, a region on the hypergrid nine times the size of an SL region. It's not a particularly light weight region, it's actually really heavy: Lots of moving objects, seriously overweight trees (with alpha blending even) etc. In the second picture each of the 11 rose bushes linig the gravel path has 9,816 tris, each of the six petunia globes 3,472. This may still be high performance by current SL standards but it wouldn't be difficult at all to make a larger and more detailed scene with only a fraction of the server and client load.

When I took the pictures there were 21 NPCs (those are bots run by the sim server for those not familar with OpenSim NPCs) and two avatars in the region. The hardware and graphics settings are the same as in the Bellisseria pic that started this thread except I cranked the LoD factor up to 4 for good measure yet the frame rate I get is four times as high.

---

Anyway, this reply was supposed to draw distance, not performance. If I were to choose between Bellisseria and Ruritania, I know very well which I would have preferred to have my virtual home in. There would be no contest even if I ignored the huge performance difference and the panoramic view is one of the main reasons. Others may see it different of course and that's OK but please do not tell me or anybody else what we should want from a virtual world.

[Ardy Lay]

OpenSimulator OBVIOUSLY has better rendering performance than Second Life.  😉 

[ChinRey]

8 minutes ago, Ardy Lay said:

OpenSimulator OBVIOUSLY has better rendering performance than Second Life.  😉 

Yes, especially since it's exactly the same render engine

Seriously, this particular comparasion is all about more efficient - or at least less inefficient - content of course.

Edited October 12, 2021 by ChinRey

[Ardy Lay]

We need more render engines, Scotty!

[Ardy Lay]

5 hours ago, ChinRey said:

Seriously, this particular comparasion is all about more efficient - or at least less inefficient - content of course.

Would be nice if the render engine didn't have to stop, stuff an envelope, address it, apply postage and run it to the mailbox every time it encountered a surface whose parameters were a bit different from the one it is working on.

[Profaitchikenz Haiku]

12 hours ago, Ardy Lay said:

Would be nice if the render engine didn't have to stop, stuff an envelope, address it, apply postage and run it to the mailbox every time it encountered a surface whose parameters were a bit different from the one it is working on.

But that's happening in both SL and the Opensim.

I've been pondering Chin Rey's points about Ruritania, and as far as I can tell, the min difference between SL and the Opensims is that SL has all the asset servers in one place, but the Opensim has wide diversity of hosting. So is the bottlenecking simply down to that? Too much in one small place?

Edited October 13, 2021 by Profaitchikenz Haiku

[Ardy Lay]

2 hours ago, Profaitchikenz Haiku said:

But that's happening in both SL and the Opensim.

I've been pondering Chin Rey's points about Ruritania, and as far as I can tell, the min difference between SL and the Opensims is that SL has all the asset servers in one place, but the Opensim has wide diversity of hosting. So is the bottlenecking simply down to that? Too much in one small place?

I think she was pretty clear in that she was comparing the content of each location, not the hosts or the clients.  I just have to sow confusion when people come in Second Life forums talking about "OpenSim", knowing they are really talking about another simulator called OpenSimulator, and comparing "performance".  The methodology she used, waiting for things to load and quiesce, is appropriate to minimize any difference to RENDERING PERFORMANCE caused by TRANSFER PERFORMANCE, so where it is hosted it probably not significant to rendering performance.

Sure, geometry and texture volume make a large difference in rendering time from one scene to the next.  Sure, those seem like the most likely candidates in all scenes, but, the way she tosses aside the results of scientific evaluations of what the Second Life Viewer is spending time on when rendering has me convinced she is ignoring the effects of other face parameters and the face-multiplying effect of "alpha-cutting" avatar mesh bodies, but, to be fair, she doesn't ever seem to talk about alpha-cut avatar mesh bodies, but she did refer to some data presented in another thread that was solely about alpha-cut mesh bodies and their tyranny against Second Life rendering performance, thus, I spoke up.

Edited October 13, 2021 by Ardy Lay

[Ardy Lay]

1 minute ago, Ardy Lay said:

.

 

 

Edited October 13, 2021 by Ardy Lay

[Desiree Moonwinder]

I just noticed that when I turn the graphics setting called "Maximum Complexity" down and thereby "jelly bean" all the avatars that my frame rate tripled from 15 fps to 45 fps for about a minute, and then sunk back to 15 fps.  When jellybeaning first came out, it required your graphics card to do all the rendering work and then threw that away, with no net reduction in rendering work.  I thought LL was fixing that, but <REDACTED>.

Correction.  My bad.  The drop to 15 fps was because I moved the window to the background to type here.  Performance really does increase nowadays if you jellybean everyone.  This is highly relevant for combat games.

 

Edited October 13, 2021 by Desiree Moonwinder

[ChinRey]

14 minutes ago, Ardy Lay said:

The methodology she used, waiting for things to load and quiesce, is appropriate to minimize any difference to RENDERING PERFORMANCE caused by TRANSFER PERFORMANCE, so where it is hosted it probably not significant to rendering performance.

You're absolutely right. This particular comparasion was of scenes after they had been fully loaded and stabilized so it's all about viewer load/performance and has nothing to do with the servers.

The post wasn't actually supposed to be about performance at all. What I wanted to do was show the difference between a cramped closed-space SL scene and the kind of open panoramic scenes we can't realistically have in SL. But when I noticed the big difference in frame rate, something I actually didn't expect, I had to mention it an maybe maybe I got a bit carried away.

[Profaitchikenz Haiku]

23 minutes ago, ChinRey said:

show the difference between a cramped closed-space SL scene and the kind of open panoramic scenes we can't realistically have in SL.

I visited Ruritania a few months ago to look a the railways there, and I did find the spaciouusness of it very appealing. It is one of the best places in the Metaverse I have ever visited.

[ChinRey]

3 hours ago, Ardy Lay said:

she doesn't ever seem to talk about alpha-cut avatar mesh bodies, but she did refer to some data presented in another thread that was solely about alpha-cut mesh bodies and their tyranny against Second Life rendering performance, thus, I spoke up.

The thread as a whole was about alpha-cuts ut the post I referred to wasn't. It only showed the difference between calculated and actual render load without going into what the causes may be. There are several other more significant reasons for the deviation.

I don't think I've ever joined a discussion about alpha cuts specifically but I believe I was the first one to bring up the general problem with a large number of draw calls on this forum many moons ago. I got very little, if any, response then.

There are four reasons I'm not too concerned about alpha cuts/draw calls anymore:

1. In stark contrast to their successors, Rosedale, Ondrejka, Bar-Zeev and Call were very conscious about viewer performance. They were considering a different way to handle textures on prims that would have drastically reduced the number of draw calls but they never implemented it. Bar-Zeev mentioned it in passing in a blog post once but never bothered to elaborate on it. I think it's safe to assume they tested it out and decided it wasn't an important issue.
2. After I posted my concern about draw calls here, I did some tests myself, spiltting up meshes to increase the draw calls. I was not able to induce a measurable frame rate that way. Those tests may not have been conclusive though since I did them in an all but empty sandbox with very little "background load".
3. BOM eliminates the need for alpha cuts. I hope and believe non-BOM mesh bodies and body parts will be a thing of the past fairly soon.
4. Vulkan does not use draw calls at all and I don't think Metal does either. LL has been trying to find a way to switch from OpenGL to Vulkan and it won't be too long before they have to. Once that switch happens, draw calls will be a thing of the past.

Edit: If it turns out draw calls/alpha cuts are a significant problem it's probably better to leave it to programmers to deal with it rather than content creators or users. Firestorm already has a function for consolidating faces with the same textures as part of their dae export feature. I don't know much about the SL code of course but in theory at least it shouldn't be too difficult to add something similar to the rendering pipeline.

Edited October 13, 2021 by ChinRey

[Coffee Pancake]

3 hours ago, Profaitchikenz Haiku said:

But that's happening in both SL and the Opensim.

I've been pondering Chin Rey's points about Ruritania, and as far as I can tell, the min difference between SL and the Opensims is that SL has all the asset servers in one place, but the Opensim has wide diversity of hosting. So is the bottlenecking simply down to that? Too much in one small place?

Eeeehhhhh

OpenSim put's hosting and asset delivery in the hands of the region you're visiting, seeing how OS users like to boast you can run a sim on anything, this rarely turns out to be a good thing, especially once you have more than a couple of avatars maxing out the servers bandwidth. In essence OS does it way SL used to back in the bad old days before we had the CDN.

 

[Silent Mistwalker]

1 hour ago, Desiree Moonwinder said:

The drop to 15 fps was because I moved the window to the background to type here. 

Mine is always exactly 16.1 fps when it is running in the background while focus is on another window. Must be hard coded somewhere. lol

[Ardy Lay]

1 hour ago, Silent Mistwalker said:

Mine is always exactly 16.1 fps when it is running in the background while focus is on another window. Must be hard coded somewhere. lol

See debug setting BackgroundYieldTime.  It is usually 40 milliseconds.