mystery complexity quadrupling

[ChinRey]

16 minutes ago, NiranV Dean said:

I might have just been lucky and this place simply doesn't bring up enough "trash" to show a difference.

You mentioned something about furry hangouts and that may explain it. I did a quick comparasion between my furry avi and a "regular" human mesh avi with similar render complexity and there was a huge difference in the fps I got. I've heard others comment about how furry places are less laggy too and it seems to me that makers of furry related fitmesh tend to be less prone to take advantage of the various render cost loopholes than makers of human fitmesh.

If I can risk a little bit of stereotyping, I also believe furry places tend to have less laggy surroundings. with less fasionably overtextured furniture etc.

[Penny Patton]

3 hours ago, NiranV Dean said:

Conclusion: SL remains different for everyone.

That's fair.  I do have an older GPU and I imagine people with less dedicated VRAM are hit harder by textures than people with newer cards with more onboard VRAM.

That said, I do believe a large number of SL users have hardware comparable to, or less powerful than, mine. Over the years I've gotten a lot of comments from people regarding the performance boosts they've experienced in sims I built, most recently with that RP area in the Outer Rim sim.

[NiranV Dean]

20 hours ago, ChinRey said:

You mentioned something about furry hangouts and that may explain it. I did a quick comparasion between my furry avi and a "regular" human mesh avi with similar render complexity and there was a huge difference in the fps I got. I've heard others comment about how furry places are less laggy too and it seems to me that makers of furry related fitmesh tend to be less prone to take advantage of the various render cost loopholes than makers of human fitmesh.

If I can risk a little bit of stereotyping, I also believe furry places tend to have less laggy surroundings. with less fasionably overtextured furniture etc.

I do notice the same. Generally speaking furries nowadays seem to be much more optimized even when not actively optimizing. Any human avatar i see for some reason drops my framerate harder than 20 furries in a club or hangout place. I'm still surprised sometimes when i see a single avatar absolutely murdering my framerate to the point i get nervous and worry i broke something in the Viewer and then notice its just a human avatar again that appeared in my draw distance doing this. Whats even weirder is that furries often use the same bodies as humans (the big ones...), texture memory usage usually goes through the roof as well with all the million fluffs that have different 1024x1024 textures for some unknown reason. Don't get me started on clothing items that allow switching textures on multiple surfaces.... each time you swap the texture you add another 1024x1024 texture, one for the arms, one for the base of the jacket, one for the zipper, another one for the neckfluff... oh and the belt... dont forget the belt... or the pockets... i had to combine these into a single texture for my own stuff.

Funny when you consider that before mesh the total opposite was true.

[ChinRey]

1 hour ago, NiranV Dean said:

I'm still surprised sometimes when i see a single avatar absolutely murdering my framerate to the point i get nervous and worry i broke something in the Viewer and then notice its just a human avatar again that appeared in my draw distance doing this.

I think this illustrates just how much damage the fitmesh LoD bugs have done.

 

1 hour ago, NiranV Dean said:

texture memory usage usually goes through the roof as well with all the million fluffs that have different 1024x1024 textures for some unknown reason. Don't get me started on clothing items that allow switching textures on multiple surfaces.... each time you swap the texture you add another 1024x1024 texture, one for the arms, one for the base of the jacket, one for the zipper, another one for the neckfluff... oh and the belt... dont forget the belt... or the pockets...

And remember that people are actually complaining about the limited number of attachments they can have. I said something about avatars with a hundred 1024s in an earlier post. I don't think that was an exaggeration, if anything it was a rather conservative estimate.

With pre-BOM mesh bodies draw calls may also be a sinigficant issue. All the segments of the bosy may use the same texture but as far as I know they are still drawn separately. How difficult would it be to implement consolidated draw calls on linkset level?

[NiranV Dean]

56 minutes ago, ChinRey said:

With pre-BOM mesh bodies draw calls may also be a sinigficant issue. All the segments of the bosy may use the same texture but as far as I know they are still drawn separately. How difficult would it be to implement consolidated draw calls on linkset level?

I wouldn't know if that would even help, as far as i remember draw calls are already consoliderated like that. An object calls the drawcalls in its children, eliminating that additional draw call wouldn't help much i suppose since you have to draw them regardless and do all the necessary work for each object, from a quick guess you'd just save a function call... not that saving a function call per linkset is nothing, considering that there are tens of thousands of draw calls and potentially saving many function calls everywhere would save a bit but i doubt it would be worth doing. It sounds more like "squeezing out" the last bit than big time optimizations with results. It would probably make the render code even more messy.

Edited August 3, 2020 by NiranV Dean

[ChinRey]

1 hour ago, NiranV Dean said:

I wouldn't know if that would even help, as far as i remember draw calls are already consoliderated like that.

So what you say is that it has already been implemented? That's good of course but is it for each prim or for linksets as a whole?

I know there was no draw consolidation in SL originally. Avi Bar Zeev himself discussed it in a 2008 blogpost (still available on the Wayback machine: https://web.archive.org/web/20190312022703/https://www.realityprime.com/blog/2008/08/how-sl-primitives-really-work/):

Quote

To be blunt, faces are something I should have tried harder to kill or minimize, way back when. Most volumes can be thought of as solid materials, where the same texture should apply throughout. Indeed, a cube could be thought of (and is handled internally as) a curve with vertices at 0, 0.25, 0.5, 0.75, and 1.0 in the parametric space, with no separate faces required. So we probably could have defaulted to a sort of 3D texturing – one texture per prim, and automatic texture coords to make it look more real. Faces with unique textures became a real pain the ass to optimize for better performance, and they don’t help streaming much either.

Later he added two comments:

Quote

If prims are first considered a single material and texture, you can always add texture layers on top of that. One layer could be for custom-painted texture areas anywhere on the prim — grafitti or posters, or whatever — and these could wrap the prim in any way, not just per face. Other layers could add reflection, bump mapping, and so on. You could even have a 2nd material and use a texture layer to blend between the two, much as terrain blends between multiple materials in different places.

There’s no reason you couldn’t then emulate what you get now, plus a lot more, and avoid the cost of having one prim fall into multiple rendering queues.

and:

Quote

As I mentioned, if I had to do it again, I would eliminate the Face concept and just begin with simple projections of the same texture everywhere, applying special cases as decals.

 

[NiranV Dean]

1 hour ago, ChinRey said:

So what you say is that it has already been implemented? That's good of course but is it for each prim or for linksets as a whole?

I know there was no draw consolidation in SL originally. Avi Bar Zeev himself discussed it in a 2008 blogpost (still available on the Wayback machine: https://web.archive.org/web/20190312022703/https://www.realityprime.com/blog/2008/08/how-sl-primitives-really-work/😞

 

I doubt something has changed since then.

Each "object" calls into its sub-objects and textures to render themselves, e.g drawcalls, kind of like a branching tree. What he's explaining is something completely different and would indeed have potential to drastically speed this up but would also invalidate pretty much any and all tools (and potentially content) we have right now unless we do it in a way that makes them stay compatible.... aaand i start talking like LL.

[ChinRey]

2 minutes ago, NiranV Dean said:

 aaand i start talking like LL.

Don't worry, we won't tell.

[Peter Stindberg]

I'm late to the party, it seems. These three pages have been an interesting read, and especially @ChinRey's input was valuable and her backstory all too familiar.

I now know, that OBJECT_RENDER_WEIGHT is unreliable (I'm one of ChinRey's "clueless developers") and incorporate that information into my planning, however, something else has brought me to this thread: OBJECT_RENDER_WEIGHT does not get reported at all in approximately 2/3 of the cases.

I need to get the data extracted - probably should have done before reopening the thread - but the situation is as follows: I placed a test-script on a medium-busy sim, get avatar UUID's via llGetAgentList and get the render weight of each newly arriving avatar via llGetObjectDetails.

Without running the actual numbers, I see a render weight reported only about 1/3 of a time. I even did a delayed second call of llGetObjectDetails, to see if that figure simply needs time to be reported, but it didn't change much.

I'm going to add some statistics/logging to my test script, so I can return with hard data soon, but has anybody noticed this behaviour as well?

Update: First test data is in. Out of five avatars, zero had a render weight reported. Two of the five left the region and returned very shortly after, just one of them had a render weight reported. All of them are "proper" avatars, not bots.

Update 2: Seems to be a timing issue. Resetting it while avatars are on the sim gets a render weight almost all the time. As does querying for it when an avatar left (as the data is cached for a bit by the sim). But it does not seem available right away, when an avatar enters a sim.

Edited April 3, 2021 by Peter Stindberg
Added more test data

[ChinRey]

5 hours ago, Peter Stindberg said:

Seems to be a timing issue. Resetting it while avatars are on the sim gets a render weight almost all the time. As does querying for it when an avatar left (as the data is cached for a bit by the sim). But it does not seem available right away, when an avatar enters a sim.

That's right. I can't remember if it's been mentioned in this thread already but the servers don't calculate render weights for avatars. Instead they retrieve data from clients and they only request that data every few seconds. Originally they used the average of data from all agents in the region and neighbor regions but I think they finally came to their senses and today it seems only the data from the agent in question counts.

Edit: Strangely, the OBJECT_RENDER_WEIGHT misery still makes me particularly agitated even though I've seen much worse before and after. I think it was partly bcause it's such a classic example how poor ground work can ruin a brilliant idea, partly because it was the tipping point that made me realise just how bad SL development was during the six dark years.

Edited April 3, 2021 by ChinRey

[Peter Stindberg]

3 hours ago, ChinRey said:

Strangely, the OBJECT_RENDER_WEIGHT misery still makes me particularly agitated

Yes, that was clearly visible from the thread. *hugs*

I read the trhead carefully, and to me the conclusion was, that initially it was upon feedback from other viewers, but that that has changed in the meantime. I tried to move the llGetObjectDetails as far back in the detection, as possible, but that brought no concernible change. I shy from using llSleep since I consider it bad style. So the best bet for now is grabbing that metric upon departure from the region.

[Peter Stindberg]

OK, I promised some more data, and the more I delve into this, the more crazy it gets. Basically, @ChinRey ist right on all accounts - the metric is more or less completely useless, the way it is implemented right now.

The following screenshots come from the tracker I mentioned before. I am tracking arrivals, departures and movement with it, and added the registering of render weight to it.

Exhibit A:

This avatar moves between 3 parcels on our sim. I confirmed with her (she's a good friend) that she did not change her outfit during that visit. The tracker shows she was the only person in the region at the time of measurement.

In theory, the four measurements should all show the same value. Yet they fluctuate. Not by much, but still. Unfortunately, we don't know her actual render weight as displayed in the viewer.

Exhibit B:

This is the same region, again with only one visitor at the time. The avatar visited twice - since my tracker registered them never before they must have arrived from somewhere else on their first visit. During the first visit, the render weight stayed the same - contrary to Exhibit A. What is interesting is, that upon logoff of the avatar, the region FPS dropped dramatically. That could have been correlation....

... if not for their second visit 20 minutes later. I assume they logged on on our region. However, the render weight is about 30% lower during the second visit, so maybe they came from somewhere else and changed outfits. The entry render weight could not be measured (not "known" to the sim upon time of entry), however the weight changes while they move from parcel to parcel more significantly than in Exhibit A. 

What is remarkable, is that upon their logoff, region FPS dropped again dramatically. So I lean towards the side of causality by now.

I updated the user manual of my tracker with a looooooooooong explanation about everything I learned about render weight, and appealed to the users to not use render weight as justification for banning visitors and consider it an unreliable metric (at best).

Thanks again everybody who contributed to this thread. It has been quite the ride.