MeshMaxConcurrentRequests – The new RenderVolumeLOD that’s killing what SL looks like for some

(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…

Corrected blog:

ALMOST EVERYTHING written below is wrong about how this thing works. Why leave it here? Because

  1. I wrote it and I find people drama-freak when I delete mistakes claiming I’m trying to hide things… and
  2. 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:
MeshMaxConcurrentRequests Default of 32
To something really high:
MeshMaxConcurrentRequests Set To 145
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…

11 Comments (+add yours?)

  1. garvie
    Apr 01, 2013 @ 10:28:44

    i’ve been experimenting with that setting too for months now. i am at 350 i think and still no ‘performance’ hit. until your blog i was never sure exactly what it does. indeed i am still not sure how it works, does it count as the number of discrete meshes one can see at a time, or if it is the LI count per mesh? if the latter we might as well all slide that sucker to the max and see how it goes.


  2. Ciaran Laval
    Apr 01, 2013 @ 11:57:35

    Interesting, I have reported an issue to the Jira where Mesh items do not show up at all, although I know they are there. Next time it happens I shall look for this setting.


  3. Trackback: MeshMaxConcurrentRequests - The new RenderVolumeLOD that's killing what SL looks like for some | Second Life - Guides - Tutorials |
  4. Tank_Master
    Apr 01, 2013 @ 20:31:54

    That debug only affects the maximum number of mesh objects the viewer will request from the server at any particular point of time, it has nothing to do with content being displayed or rendering.


    • Pussycat Catnap
      Apr 02, 2013 @ 00:47:05

      Perhaps. Though it does seem to have the impact on total. Something to investigate, given the lack of documentation and that the ‘mesh not rendering when there is too much mesh around’ problem is a common one.


  5. Inara Pey
    May 11, 2013 @ 13:08:54

    You might want to read Lette Ponnier’s comments on MeshMaxConcurrentRequests, written in Sept 2012:

    “Bumping this debug up is, indeed, recommended for helping mesh to appear. However: leaving it at a high number is neither recommended (by us) nor necessary for keeping the mesh rendered. Some people experience higher rates of crashing when this is set to a higher number (over 100 or so). Regardless of whether you’re having trouble, though, “requests” refers to how much communication is going on between you and the server, and the more requests are being made, the more it will contribute to sim lag because you’re simply giving it more work to do. If there’s only one person with their setting this high, the effect will be totally unnoticeable. But if we’re talking about 40 people all sending >100 requests to the sim whenever mesh appears, then sad to say, this one will end up contributing to the lag you’re all feeling.

    “So our recommendation is: bump this up when you need to, and return it to default once you can view the mesh.”

    (Lette is a member of the Firestorm support team)



    • Trezz Vyper
      Dec 27, 2013 @ 10:07:58

      Anything reliant on requests and bandwidth limits is going to produce lag in-world. While it’s a logical statement to say turn the setting down, once the mesh has loaded, it’s an ironically similar statement to what’s been exampled in the 3’rd paragraph of this blog.

      It’s like scripts, we all know the more you run (or those that are not well coded), the more lag they produce. Multiply that by the number of people on a sim and it’s welcome to lag city – GOL dance club is a prime example!

      Asking people to limit their scripts is, in most cases, a useless exercise. So while I get the reason behind not having MeshMaxConcurrentRequests set to a high setting, the most likely reality is, when people find out about this, they’ll set it higher and higher and not change it back, why? Exactly the same reason they don’t care about number of scripts.

      I’d like to say hopefully this mesh issue will be sorted, soon. But given Lette Ponnier’s wrote about this issue back in Sept 2012 and 2013 is almost over, it’s sadly looking like it wont be resolved anytime soon.


      • Inara Pey
        Dec 30, 2013 @ 12:41:20

        Actually, it is being resolved.

        Because of the stress that setting MeshMaxConcurrentRequests too high is already producing, the Lab is in the process of replacing the debug setting and its associated capability with a new capability & debug.

        The difference? The new capability (GetMesh2) and its associated debug (Mesh2MaxCocurrentRequests) will be clamped, and people will not be able to set ridiculously high request values.

        Further, as the new capabilities are being transitioned-in to the grid in early 2014, the Lab will be clamping the current MeshMaxConcurrentRequests – although the exactly value at which it will be calmped is unclear, although it is likely to be well under 100.

        As it is, and in preparation for this change, Firestorm already clamp the number of MeshMaxConcurrentRequests to a maximum of 64.

        The work which will introduce these changes has actually been going-on for a while within the Lab, with Monty Linden leading the charge. The first phase of changes (for texture handling) were introduced in 2012. Since then, in 2013, we’ve seen a number of additional improvements on the HTTP front, and Monty has been hard at work in getting the mesh side of things under control to prevent it “shotgunning” (as he calls it) the network so badly.

        Right now, the server-side of his mesh work (the new capabilities) are ready to go. All that’s needed for this phase of the work to be completed are the viewer-side updates – and they are due to surface in a project (or possibily a release candidate) viewer very early in 2014. From there they will progress to both the de facto release viewer and to TPVs.

        All of this work is laying the foundations of Monty’s ultimate goal of introducing HTTP pipelining to the platform.

        I’ve covered Monty’s HTTP work at length in my own blog as a part of my weekly SL project update reports, and you can read more there, if interested.

      • Pussycat Catnap
        Dec 30, 2013 @ 12:51:16

        I noted that this blog was in error up top a few months back, and have linked to my corrected version. Which is intentionally written in a voice of: ‘walk myself through the thoughts in a non-technical way’.

        I set it currently at 8.

        This for me a great example of techies using a term of art in a ‘public place’ where non-techies will see it and apply a plain language definition to it in an effort to solve a problem that on the surface looks related.

        Its a great case for never publicly using what is a ‘term of art’ on one’s industry without good explanation.

        A variable like:
        “Mesh2MaxCocurrentRequests” is just going to lead to the same problem: maxing out to whatever cap they set.

        I’d recommend something like:


        Something that clues people in to “set this too high and you whack everything.”

        Maybe even

        – and make it a setting, entered as x:y that determines how much of your bandwidth goes to mesh.

        As long as the debug settings are available to the public, and some critical things everyone MUST adjust like the sculpty one and the camera ones are there… then the settings in there need to have some thought to being sensible to non-techies, or at least non-dangerous if tweaked.

      • Inara Pey
        Jan 09, 2014 @ 06:48:58

        BTW: The server-side updates are now becoming visible. The Lab has a project viewer supporting the new capability and debug, complete with the cap on usage. The code is also now available for TPVs to integrate into their offerings.

        There will be a transitional period when both the “old” and “new” capabilities will co-exist on the grid, but as the server-side changes are fully deployed and the server code reaches a de facto release status and finds its way into TPV releases, we can reasonably expect the older capabilities to be discontinued.

  6. Inara Pey
    Dec 30, 2013 @ 13:05:07

    @ Pussycat

    No matter what the explanation given or the name applied, the reality is some will always go for the highest they can and be damned. The difference here is that by clamping things on a individual basis, overwhelming the capability is less likely to occur even on a collective basis. And that’s a whole lot better than has been the case where just a single high setting can overwhelm the capability right from the get-go and cause problems for more than just the individual concerned.

    As to “set things too high and you whack everything” – that’s precisely what Monty has been saying, and people like myself and Nalates Urriah have been repreating via our blogs :).

    Monty will, it seems, also be saying it once again when the current batch of HTTP are ready to go “live” both viewer-side and server-side. He has apparently crafted a blog post on the subject ready for wen the viewer-side updates go out.

    Remember, as well, that all this is sort-of “interim”. As pipelining comes in, things like separate channels for mesh and for textures will be effectively disappearing.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: