(No this is not an April Fool’s Post. :) Didn’t realize it was April 1st today).
EDIT October 17, 2013: Further research has changed my perception of the cause of the issue I was seeing. It is I believe related to the meshmaxconcurrent setting and another debug setting, but the solution is more nuanced than either maxing or mining them. Working on a new blog, leaving this one here for a reason:
Bad documentation… Techies: If you don’t write docs, or write bad docs, people will look at things and use common language to define them.
Mesh max concurrent: maximum mesh concurrently existing. Makes language sense. BUT that is not what it actually means in SL… it actually means ‘number that will go into the download pipe at the same time’ as in: how many lanes wide is the freeway bridge – that is your pipe. How many cars on the bridge at the same time – that is this setting.
- But that is not the plain English way to read it…
ALMOST EVERYTHING written below is wrong about how this thing works. Why leave it here? Because
- I wrote it and I find people drama-freak when I delete mistakes claiming I’m trying to hide things… and
- What is below is a common misconception of the issue. I’m leaving this here as a warning to techies: use terminology that makes plain language sense, or risk non-techies reading your words using a dictionary and not a computer-science degree…
– I deal with that myself all the time as a political scientist with terms like ‘minority’ or ‘redistribution of wealth’ that have meanings which are very different from what a dictionary will tell you. The situation below: is what happens when techies use their inside terminology to outsiders.
EDITED to take into account what was stated in the third comment. Looked a little further into it after that.
Ever see people who look like this:
That’s not your graphics card failing, its not SL failing, its not your viewer failing, its not you failing, its not them failing.
Its on Linden Lab this time.
Its most likely about MeshMaxConcurrentRequests, an obscure setting that determines how many mesh items can be downloaded and rendered at the same time. Maybe not a total, but rather like bandwidth: number of items it will grab at once… and its chocked from not enough feeds in and one getting stalled.
Because mesh these days is super common. Like fleas on a dog, its rampant and out of control.
Because its good. People love it. It looks super sharp. You might hate it, but most are using it. Over 97% of people can see it now, but I suspect most of them have never even heard of this.
Linden Lab, when they put out mesh, decided nobody would ever really care for it. We know from their mouth they never expected [much or any] mesh clothing… (/facepalm)… and that’s what its mostly for now…
So they set the default for how many mesh items to stream in at once to a really low number.
The problem is that the method often stalls, and when it stalls on something it will often never bother to make a second check. Why? Not sure. My guess is you run out of ‘lines’ before you run out of items – and so nothing ever ‘goes looking for something to do’. So in a room of 300 mesh items (not unusual if you think about it), your 31st line stalls out, line 32 doesn’t go look at it, but moves to item 32. Line 1 comes back after done with the first item and moves to the 33rd item…
Do prims or sculpties or textures do this? Work on an easily choked stream? I don’t know…
I suspect that if you could only get 32 prims at a time. Or 32 sculpties even. Or 32 textures… they might often fail to ever appear as well… Or maybe they just have a method that isn’t stall/choke prone…
Most people have heard of renderVolumeLOD. Its that setting that says you can’t see sculpties unless they’re glued to your avatar’s eyes. The default for that has been 1.25 or something since Sculpties first came out, and if anyone actually leaves it there, SL looks horrible.
Well that’s happening all over again now, with MeshMaxConcurrentRequests.
The fix is easy:
Go into debug settings:
Change that 32:
To something really high:
Note that even this high, 145. I -STILL- find myself regularly in places where the 146th mesh item fails to show up… because yeah, mesh really IS that common now…
But I keep upping this number, and it hasn’t hurt my speed yet. No idea yet how high we can go… but we all need to go a little higher.
Mesh is here now, and its everywhere, and we all want our SL to look nice. Changing this setting will let you see SL as it exists today. Leaving it at 32 means you’re going to miss a lot of content when those stalls and chokes happen. There in my SL home, most of the furniture is now mesh. Every day more and more people are replacing older content with mesh. You’re looking at at least 19 mesh items in this highly cropped photo. The full render was a LOT more, plus a ton of them all around above, below, and in front of me.
The 32 value just will not do as a default. But given how Linden Lab still has yet to fix RenderVolumeLOD, don’t expect them to fix this one either, even if it means already most newbies are seeing an SL that is half invisible…
The counter might be that going too high means you over burden your bandwidth by telling it to focus way too much on mesh. But it appears that if you have a whole lot of lines open, and say… number 31 does choke on its item, then when you’ve grabbed up the last mesh item, the next line in the list gets back and gets item 31… I’ve read that this choke / stall issue was fixed a year ago. But mesh is still often failing to show up. And adjusting this -does- fix that…