Too Many 1024 Textures and the NEW (please hurry) Land Impact rules

[Kyrah Abattoir]

Yeah I was baffled when they introduced the features, they would rather implement a "trust" based cludge than actually have the simulator load the mesh.

(I assume the simulator just loads the "prim" fallback, since meshs where defined as prim shapes for pre-mesh viewers)

[Fionalein]

15 minutes ago, ChinRey said:

You can say that again but if you expect anybody to listen, you'll be sorry.

Sadly they started turning up at events now - but there at least the population there is high enough that an average ARC gleaned from all nearby might be well somewhere in plausible range.

[ChinRey]

2 hours ago, Fionalein said:

Sadly they started turning up at events now

Technically that's nothing new, we launched the original one at Colabor88.

Or possibly Uber, it's so long ago and I've been trying to supress the memory of it all. (If I sound especially grumpy today, it's because I was reminded of the misery.)

To be fair, if you turn up with a good old system avatar with not too many sculpts or flexis in your hair and not too many polys in your shoes, you won't have any problems. But if you arrive with a relatively low lag mesh avatar, there's a good chance you will be kicked out while others with far heavier avis may pass with flying colors.

 

2 hours ago, Kyrah Abattoir said:

Yeah I was baffled when they introduced the features, they would rather implement a "trust" based cludge than actually have the simulator load the mesh.

I think we need a bit of history here. The ARC feature was added to lsl long before the jellydolls, back when LL couldn't care less about client side load. When Oz read my JIRA, showing how badly his predeccesors had bodged that job, he probably didn't believe his own eyes.

The server wouldn't have to actually laod the mesh btw, it would just need the key data relevant to the render weight formula.

Anyways, there is a moral here - and I'm actually serious:

Any code and feature added to the SL software after Cory Onderjka was fired in 2007 and before Oz and Ebbe took over in 2014, is presumed to be fatally flawed unless proven otherwise.

(I have to add that I can think of two features right away that have been proven otherwise. They are still the exceptions, not the rule though.)

Edited July 18, 2018 by ChinRey

[Penny Patton]

While jelly dolls are better than nothing, and they have encouraged many content creators to be more mindful about ARC, I've always felt it was a backwards way of approaching the problem, for many of the reasons already given. There really should be a hard, universal cap. And to be effective it would need to include texture use, or texture use could be it's own cap.

People don't understand why land impact exists. Most people clearly don't understand optimization at all. Some are downright willfully ignorant about it. But because Land Impact is a hard cap, they have to work within it. It encourages them to find ways to make the best looking content they can, with the lowest LI. Do the same with avatars and you'll see the same sort of effect. Content creators will want to make the best looking attachments/mesh bodies/etcetera for the lowest resource point cost.

 Granted, there are problems with how LI is calculated, but LL is working to address that now, and done well it is an effective means of curbing the worst habits we see. And that's all you really need to do, curb the worst habits. It doesn't even need to be super strict to achieve that. Limiting people to a universal (as in everyone has the same calculations, and ARC isn't relative based on your hardware) ARC of 100,000 and a VRAM limit of 100MB would be enough to see a dramatic improvement in performance across the board.

  Of course, like I said earlier in the thread, I'd give a grace period where the limits where displayed but not enforced, so content creators would have time to change their habits, release updates, and generally make the transition as smooth as possible for the average SL user.

[Theresa Tennyson]

6 hours ago, Kyrah Abattoir said:

Yeah I was baffled when they introduced the features, they would rather implement a "trust" based cludge than actually have the simulator load the mesh.

(I assume the simulator just loads the "prim" fallback, since meshs where defined as prim shapes for pre-mesh viewers)

The simulator doesn't have to  "load" anything attached to an avatar because avatar attachments are non-physical and every nanosecond the simulator spends thinking about the three-dimensional properties of an avatar attachment is an utter waste of time.

[Kyrah Abattoir]

1 minute ago, Theresa Tennyson said:

The simulator doesn't have to  "load" anything attached to an avatar because avatar attachments are non-physical and every nanosecond the simulator spends thinking about the three-dimensional properties of an avatar attachment is an utter waste of time.

My point is that the render cost metrics should be determined by the region and not some weird client based consensus, because the second scripts start to use this metric a little too much is the second clients will start to come out with an option to "disable reporting render cost"

[Theresa Tennyson]

30 minutes ago, Kyrah Abattoir said:

My point is that the render cost metrics should be determined by the region and not some weird client based consensus, because the second scripts start to use this metric a little too much is the second clients will start to come out with an option to "disable reporting render cost"

You're asking a "busy blind person" to do something they are completely unequipped to do. The reason that the server asks multiple viewers now is to make spoofing the number largely impractical - you can turn off yours, but the avatar next to you will send your numbers whether you like it or not.

[Coffee Pancake]

6 minutes ago, Theresa Tennyson said:

You're asking a "busy blind person" to do something they are completely unequipped to do. The reason that the server asks multiple viewers now is to make spoofing the number largely impractical - you can turn off yours, but the avatar next to you will send your numbers whether you like it or not.

It would be largely impractical if the spread of viewer users was more balanced. It's not. There is one game in town and we all know what it is.

[Kyrah Abattoir]

And you underestimate people's eagerness to break a feature that annoys them, if they are given the opportunity to do so. ex: look_at targets.

[Coffee Pancake]

Kinda why we at Catznip decided to just not touch that code at all, ever. We ship the Linden default and plan on continuing to do so .. but that doesn't stop it being one of the top FAQs.

How do I hide mine and enable everyone else's.... yeaaaaah no.

[Kyrah Abattoir]

It's funny because the look_at targets where once praised of making secondlife avatars more alive and believeable. Hell, I use a simmilar system in unity to get characters to look at what the player is looking.

But this is SL and people just turn it off .

[Chic Aeon]

1 hour ago, Penny Patton said:

Of course, like I said earlier in the thread, I'd give a grace period where the limits where displayed but not enforced, so content creators would have time to change their habits, release updates, and generally make the transition as smooth as possible for the average SL user.

I don't disagree with you in spirit but I have a hard time convincing myself that the majority (or even half - maybe a quarter) of content creators will redo and update as needed -- mostly because it seem logical that the folks that need to make the most changes are the ones that are purposefully making the oh so pretty but OMG heavy and difficult to render mesh.   They might -- if the edict was enforced -- change their methods in the FUTURE and that would be good. No argument there.   

I only know of two very visible creators (events et al) that have changed they way they make mesh -- this  year after the Firestorm Tools came out. The others who I so hoped would make some changes, have not. These are NOT stupid people. They have made their choices and they are sticking to them.  That is certainly their right. It just impacts a much larger demographic than their customers.  Pretty much anyone who goes anywhere gets to deal with heavy mesh, giant texture downloads and faulty LODs (a whole 'nother issue I know). 

If I was trying to enjoy Second Life on a $500 computer I would be in deep trouble. Happily I am not. 

[Fionalein]

45 minutes ago, Chic Aeon said:

I only know of two very visible creators (events et al) that have changed they way they make mesh -- this  year after the Firestorm Tools came out. The others who I so hoped would make some changes, have not. These are NOT stupid people. They have made their choices and they are sticking to them. 

Why should they? Once rules are enfocred their fanfolks will return to buy more stuff fit for the rules "evil Lindens plagued us with" ...

[Chic Aeon]

55 minutes ago, Fionalein said:

Why should they? Once rules are enfocred their fanfolks will return to buy more stuff fit for the rules "evil Lindens plagued us with" ...

I guess I am a big believer in "the greater good" ethic :D.   Since it really does take NO MORE TIME (people keep putting that out there and it is not true -- perhaps a myth perpetrated by The Offenders LOL) to make mesh that is a game asset than a more complex mesh (perhaps with the same land impact because of zeroing out one two or THREE levels) than it does to make efficient mesh with good LODs and physics -- I can't really see what the issue is.  A few different clicks on the uploader screen (no custom LOD time) and the mesh would be able to work for most folks, not just the LOD4 crowd.  

And the texture thing while pretty isn't TEN TIMES lovelier than a more reasonable bake.

But things are what they are. The best we can do is to try and explain the 'whys' and 'wherefores' for the folks coming in to create. 

On an aside, I seldom feature any LOD4 builds on my blog and now if I do it is noted that it is a LOD4 build. I really can't do much else and live with myself - happily.   

 

 

 

 

[ChinRey]

3 hours ago, Theresa Tennyson said:

You're asking a "busy blind person" to do something they are completely unequipped to do.

You're probably right, it's not a good idea to load that work onto the sim server. But that's exactly what happens now. The only difference between what actually happens and what Kyrah suggests is where the server gets the data from - from clients or from the assets servers.

Nor is it a good idea to let the assets servers handle the task. Even though they have all the data readily available, it's better to let them focus on delivering the goods.

The best solution would probably have been to introduce a dedicated assets management server to handle those calculations and several other assets related processes but that would of course require such dramatic changes to the software, it's not realistic.

There are two other possible solutions though.

One would be to limit the range and only use data from nearby avatars. The reason the numbers are so skewed isn't that the data comes from clients, it's because it may come from the wrong clients - ones that are way out of view distance.

The other solution would have been to deprecate the function. Providing false and misleading information, it serves no meaningful purpose, so why keep it? Today that would probably cause some protests from the sellers of ARC monitors but that wouldn't have been a problem when I filed the JIRA, we had already taken our off the market awaiting some sort of solution and there were no others around.

[Fionalein]

10 hours ago, ChinRey said:

The other solution would have been to deprecate the function. Providing false and misleading information, it serves no meaningful purpose, so why keep it? Today that would probably cause some protests from the sellers of ARC monitors but that wouldn't have been a problem when I filed the JIRA, we had already taken our off the market awaiting some sort of solution and there were no others around.

+/- some thousands it usually is within some plausible range - these orbs do their job, it is sloppy patchworked job with a lot of duct tape - but they do it.

[Coffee Pancake]

Policing performance in the client is the responsibility of the client, not the server. There is immense variability in client capability and performance that to allow one person to set limits for everyone based upon there personal configuration is idiotic in the extreme. 

Creating a revolving door and ejecting "bad" avatars based upon an arbitrary and ignorant interpretation of numbers adds significant load to a region, on busy regions such as events this simply makes SL's inherent performance woes even worse.

What's faster than checking and ejecting avatar variables when they arrive, not checking. 

[ChinRey]

11 hours ago, Fionalein said:

+/- some thousands it usually is within some plausible range

Hmmm... that shouldn't be possible. The tests I did back in early 2016 quite often showed deviations up to 50% and so did Casper Werden's tests last year.

However, LL has been known to sneak in and correct bugs long after they've rejected the JIRA so it's time for a new test...

and...

They have actually gone further than I suggested. The lsl function now simply relays your render weight readout from your viewer. That opens up for some interesting possibilities for people who like to play with the viewer code.

Still, one bug fixed, only three more to go.

 

10 hours ago, CoffeeDujour said:

Policing performance in the client is the responsibility of the client, not the server. There is immense variability in client capability and performance that to allow one person to set limits for everyone based upon there personal configuration is idiotic in the extreme.

You can say that but it is LL's responsibility to provide reliable data to users. LL has finally started to realize that now but it took them far too long and that delay cost them far too much.

Because ultimately it's Linden Lab's problem. A fairly new user who finds Second Life too laggy, will not start tinkering with their graphics settings or decide to buy a heftier computer. They'll decide SL is crap and leave.

As for how unreliable ARC is, here are two fairly random examples - anybody are welcome to check some of their own fitted meshes, the more data we have, the better. I'm not showing pictures of course or even mention brands, it's just two different pieces of fitted mesh.

• Example 1
  • 72,271 triangles
  • 42,048 Kb VRAM
  • Normal and specular maps
  • Render weight: 4,343
• Example 2
  • 52,371 triangles, three quarters of them fully transparent
  • 22,532 Kb VRAM
  • No additional visual effects
  • Render weight: 9,126

The item in example 2 is clearly the least laggy of them yet it has more than twice the calculated render weight of no. 1. That is how unreliable ARC is for mesh avatars.

Edited July 20, 2018 by ChinRey

[Love Zhaoying]

1 hour ago, ChinRey said:

• Example 1
  • 72,271 triangles
  • 42,048 Kb VRAM
  • Normal and specular maps
  • Render weight: 4,343
• Example 2
  • 52,371 triangles, two thirds of them fully transparent
  • 22,532 Kb VRAM
  • No additional visual effects
  • Render weight: 9,126

The item in example 2 is clearly the least laggy of them yet it has more than twice the calculated render weight of no. 1. That is how unreliable ARC is for mesh avatars.

What accounts for the higher weight in Example 2? The transparent triangles?

[Love Zhaoying]

On 7/11/2018 at 2:04 PM, animats said:

Callan Merriman said she'd seen slow graphics with 1024^2 images on tiny objects.

@Callum Meriman, does your gender often get mistaken? 

[Fionalein]

1 hour ago, ChinRey said:

They have actually gone further than I suggested. The lsl function now simply relays your render weight readout from your viewer. That opens up for some interesting possibilities for people who like to play with the viewer code.

Wait,  if someone does not want to be kicked out of events for wearing their superantique Gorean-BDSM devices all they have to do is to set the function to return a low constant? Good thing those types usualy cannot program...

Edited July 19, 2018 by Fionalein

[Coffee Pancake]

55 minutes ago, Fionalein said:

Wait,  if someone does not want to be kicked out of events for wearing their superantique Gorean-BDSM devices all they have to do is to set the function to return a low constant? Good thing those types usualy cannot program...

But they don't make TPV viewers .. furrys OTOH.

[Coffee Pancake]

1 hour ago, Love Zhaoying said:

What accounts for the higher weight in Example 2? The transparent triangles?

Yes. The viewer is exceptionally harsh on transparency.

[ChinRey]

4 hours ago, Love Zhaoying said:

What accounts for the higher weight in Example 2? The transparent triangles?

No. The difference in the numbers is all about the fitmesh LoD bug. But the difference in actual performance is further increased by the transparent triangles.

The first item is a linkset of eight meshes that were uploaded at minimum size with all lowest LoD models reduced down to a single triangle. So the ARC calculation assumes that it is only rendered as eight triangles while it actually is 72,271.

The second item was uplaoded at roughly the actual size. It's made from many mall aprts so it too benefits greatly from the LoD bug but not nearly as much as the first. It looses some of that "advantage" since the calculation doesn't give it credit for the invisible triangles. Running the formula in reverse, it seems the calculation assumes it's rendered as c. 800 triangles. The actual numbers are 17,457 visible triangles plus 34,914 invisible ones. The invisible triangles do add to the workload but of course, not nearly as much as the visible ones.

These two examples illustrate quite well the effect of the fitmesh LoD bug and the failure to take fully transparent faces into account. But I mentioned three bugs - there are actually four or possibly even five. I take the two I forgot about first:

The fifth potential bug is that the render weight formula doesn't seem to know about fitted mesh at all, at least it's not mentioned in the documentation. I assume it uses the same 1.2 multiplier as it does for rigged mesh but I can't find a way to confirm this and even if it's the case, there's good reason to question whether that multiplier is a realistic one.

The fourth bug is that unless there has been an undocumented update very recently, the render weight formula does no take normal and specular map into account in any way whatsoever. You can add as many of them as you like - and with as high resolution as you like - and it won't change the calculated render weight at all.

---

The third bug is the really difficult one: the whole weigth system does not take cpu load into account.

We've all seen fitmesh items hovering in the air around avatars for ages before they finally fall into place. That is almost certainly caused by cpu load, the fitted mesh has to be preprocessed before it can even be handled over to the gpu in a meaningful way. Cpu load is one of the two main reason why sculpts have a reputation for being laggy and from observation it seems a typical fitted mesh is almost as heavy as a typical sculpt there, maybe even heavier.

I mentioned earlier in the thread that Chalice Yao and Vaelissa Cortes had done a number of load tests. These were rather informal so indicative rather than conclusive but one of the things they saw, was the fitted mesh seems to add considerable work to the cpu even after they have been preprocessed. The main reason seems to be that the shader code can't handle fitmesh very well (which, if I understand correctly, should also have a serious negative impact on gpu performance).

Cpu load is something everybody have ignored until now. We've all simply assumed that client side lag is all about gpu and bandwidth. Unfortunately it's beginning to look more and more like the client's cpu can be a significant limiting factor for SL prformance and that is soemthing that really should be examined closer.

Edited July 19, 2018 by ChinRey

[Coffee Pancake]

30 minutes ago, ChinRey said:

We've all seen fitmesh items hovering in the air around avatars for ages before they finally fall into place. That is almost certainly caused by cpu load, the fitted mesh has to be preprocessed before it can even be handled over to the gpu in a meaningful way.

As I understand it, CPU is an indirect issue but not the direct cause. There is often a large queue of objects to be processed and that postpones fetching/processing the rigging. So the viewer knows its an attachment, it knows the point ... and it knows the scale/rotation etc.. which gets binned when the rigging loads and the object snaps onto an avatar.

The client is in a hurry to get stuff on your screen and in this case, that is not the best option to take.

Edit : To add, there is no delay getting it to your GPU, you wouldn't see it if that hadn't already happened.

Edited July 19, 2018 by CoffeeDujour