MeshMaxConcurrentRequests, TextureFetchConcurrency, HTTP Textures, Texture Thrashing, and Why isn’t my stuff rezzing yet?

Its been a very long time since I posted to my blog. I’m still out there, though I’m not as active in SL as I was, I haven’t moved away from it at all.

(I even have more land now than I did when I was more active, but that’s another side topic about land obsession… I rebought my original plot of land in SL, in Fietzo sim, just… because…)

Back in April I wrote about a problem with meshes often failing to download. Looking in the settings and reading some comments of a rather techie worded nature I came to the conclusion that it was driven by a setting in debug known as:


Now lets look at the Debug Settings wiki, which is a little more detailed now than it used to be, though it is also possible I just missed this bit before.

It says this:

“Number of threads to use for loading meshes.”
Defaults to 32.

Yeah um… OK. Like, whatever. What’s this mean and why do we care?

What that comes down to is that it is not a setting for the total number of meshes you can see at a time, but a setting for how many you can download at the same time.

So lets think of a bridge, like the Bay Bridge between San Francisco and Oakland. That bridge has I think, 5 lanes… that’s like your internet speed – how much room you have. In your preferences there is a bandwidth setting. That setting is basically: How many cars can I put on the bridge at the same time?

So this debug setting is basically… How many of those cars can be Priuses? This being San Francisco… everybody wants to pack a Prius on that bridge, and the more of them we put on there, the less room we have for SUVs and Civics…

Or… the more mesh you can download at a time, the less other stuff you can download at the same time…

So what you’re setting here is priority… do I want my Mesh, or my Prims, or my animations, to come in first and most…?

Or… well… do I want my textures… and this one is the real issue:


- The secret killer for people on newer settings. This one says on the wiki:

“Maximum number of HTTP connections used for texture fetches”
Defaults to 0.

Wait, what? 0? Um… Oops? Does that matter?

When does it get used?

Well, current viewers default to turning on HTTP textures. And it seems this setting comes into play when you turn on… HTTP Textures… This is your setting for ‘how many yellow cars can be on the bridge at once?’

And apparently the cops here really like stopping yellow cars, cause they’ve set it at 0.

Now I could be just as wrong this time as I was last time… but in my own testing I’ve found a major impact from tweaking this.

First, up until recently I always avoided using HTTP Textures. I had noticed that if I ever turned it on, nothing would EVER rez fully… textures would just freeze to how they were before I’d flipped it on, or worse, blur out…

It looks like when it is at 0, textures START to download, then the setting kicks in on the next ‘pass’ to see what we should be downloading and says “oh hey, not those,” and so stops (my non-techy guess at least). Before I changed this off of 0, whenever I had HTTP Texture on, SL looked like a webpage used to back in 1996 and dialup – lots of half loaded blurry images reminding me to call my ISP and ask for the 56k option… :)

After finding “TextureFetchConcurrency” and trying out a modest setting of ’8′… Its was like a Emeril moment: Bam! Everything suddenly started rendering. I just sort of watched in my viewer as it felt like I’d finally found the ‘unpause’ button on the VCR, and the world becamse crystal clear. It looked even better than it had before using HTTP Textures.

Now I’m an HTTP Texture junkie…


Remember that all these settings work in tandem (together, unlike Congress, or perhaps…)

If you dial up TextureFetchConcurrency to 5 million, all you get is yellow cars on that freeway…

Somebody tell me where I can buy a yellow Prius? Oh wait, you can’t…
(I used red cars at first in my bit above, but yeah: apparently they DO sell Prius in red. :) Who Knew?)
EDIT: Oh… they make them yellow too. and every other color I tried for this analogy… Oh well. A ‘color of unspecified variety’ prius. :P

In other words, the higher you go with TextureFetchConcurrency, the more it fights with MeshMaxConcurrentRequests. You can’t max them both.

Max TextureFetchConcurrency and you will get all your Yellow, but not the car. Max MeshMaxConcurrentRequests, and you’ll get a bunch of unpainted cars.

Except you can actually set it higher than even the total cars: you can tell it to make 125 out of every 100 of the cars Prius, thereby not only losing all other cars, but also losing 1/5th of your Priuses… (setting it too high can be very bad), and leaving the rest unpainted…

Like Congress… they fight over who gets to get their way, and if you given any one set of them too much sway, you end up with a shutdown of your SL…

And remember that bandwidth setting? If you let too many cars in the bridge at once, you get a traffic jam. Bandwidth doesn’t give you more lanes on the bridge… to do that you need to call your internet company and hand them more money… (little secret: we ALL get super ultra fast Cable or DSL, but then the company throttles it on that modem they rent to us, and charges us to dial back the throttle in steps – if a speed is available at all in your area, you’re actually already getting it, but software on your account is holding you back until you pay to have it unblocked).

This mess is not LLs fault. Well… the wording of those debug settings is… and setting the texture one to 0 is…

But giving us the ability to pick priorities is not so bad…

The smart money is likely on leaving the mesh one at its default of 32, and setting the texture one, TextureFetchConcurrency, to 32 as well. Then see how each performs and adjust them in small steps up or down. It might not even be bad to lower BOTH to 8 to 16… if not on super fast internet.

If you just up them all, and let your internet sort it out, some of those “cars” will drive right off the side of your bridge…

As in, items will get lost, and never download at all, when the clutter overtakes the speed of your internet.

So having it lower means you let just a few cars at a time race across the bridge on near empty lanes – everybody gets over, and after a moment of blur or pause, your SL renders beautifully.

Wonderful right?

Maybe… it gets worse…

In your graphics, hardware settings, there is a slider for how much of your graphics card memory to use… if this setting is too low, items that were downloaded will ‘undownload’ and start downloading again…

Just to make sure people would be aware of this, for Mac users LLs set a flag to make sure it could only use half your graphics memory…


They had a reason for that, but the issue is a rare one. However the issue of seeing the entire world of SL constantly flicker as everything re-downloads constantly, clogs up graphics memory with multiple copies in various states of download, and so starts again, clogging up even more…
- That is a very common issue caused by this flag.

Basically, to avoid a giant monster attack on the bridge, they decided to only build half a parking lot on the side we’re driving too… and failed to realize that meant that a lot of cars would have nowhere to park and so would just drive right into the water, taking your view of SL with them… or just as bad, any time a new arrived, the attendants would just toss one of the parked cars into the bay to make room… again taking your view of SL with it.

Some have called this “texture trashing” – I’m not sure if that’s a common term or just how I’ve seen it referred to.

The solution is ANOTHER debug setting:


Defaults to 0.5

Set it to 1, and then you can dial your graphics setting up as high as you want.

For me, on my Mac, with a Cable internet connection of 30mbps down, 12mbps up, I’ve current got these setting like this:

HTTP Textures on
RenderTextureMemoryMultiple 1.0
TextureFetchConcurrency 16
MeshMaxConcurrentRequests 8

Memory slider on my Graphics -> Hardware dial up to max, which for some reason is around 380-something and not 512mb…

But with these settings I get clean fast renders, with no thrashing.

Sometimes I tweak the TextureFetch and MeshMax around a bit. I’m still playing with them to find out what’s ideal for how I use SL – which is to exist in a heavy mesh build with all mesh clothing but a lot more detailed textures than I should have… :)


The numbers I originally had here were actually WAY TOO HIGH. I’ve edited above to my new ’8′ for Mesh. Kept textures at ’16′ and might still lower it. See down in the comments. A ’1′ does not mean 1 object, but one pipeline of objects. So… imagine you have a big plastic pipe going from ‘the box outside’ to ‘your computer’, and the ‘internet guy’ puts 1 wire in it. That’s a sort of kinda of way like a ’1′ on this. But hear this in that Dr. Who voice where he will often say “yeah, time travel paradox, its kinda like a mouse with cheese, only not at all.” In that… I am no techie and I’m assuming my readers aren’t either – so this is the analogy I’ve got… :)
- So you dial that number up to 2, and now there are 2 wires in that pipe… Not two objects moving on it, but 2 wires. How many wires will fit in the pipe until the thing bursts and you’ve got electricity sparking out the side and frying random passing pigeons… but not giving you your ‘interwebz’?

I don’t know… but obviously the pipe isn’t getting bigger, so don’t put too many wires in it.

I’m going to be playing with putting both my numbers at 8 and seeing what happens, then comparing it to 4, and 16… Why? Cause those are easy to remember. I’m like a Congressperson balancing a budget here: I go for the dumb numbers that just sound good on TV. :)

About these ads

12 Comments (+add yours?)

  1. Trackback: MeshMaxConcurrentRequests, TextureFetchConcurre...
  2. Trackback: The Sun, The Dust & HTTP Texture Settings in Second Life | Honour's Post Menopausal View (of Second Life)
  3. Inara Pey
    Oct 18, 2013 @ 13:40:19

    Testure thrashing is a common terms, and relates to the VRAM on a graphics card being filled-up. I’ve got an explanation here:

    Couple of points on MeshMaxConcurrentRequests.

    First is, setting it high is not a good idea; all that leads to is the connection between the viewer and the server / the user’s router getting hammered, leading to issues. 50 is a reasonable value, but the highest most should consider setting it to is perhaps 64.

    The second is that as a debug, it will be vanaishing over the course of the next few months. The Lab is currently working on HTTP connectivity, trying to make it more robust, less wearing on old routers, etc. This work started with the introduction of HTTP texture fetching in 2012, and has now turned to re-working mesh (which has always used HTTP, but very inefficiently – Monty Linden, who is leading the work, describes mesh as “shotgunning” the network in the way it handles connections).

    As the new HTTP capabilities are deployed viewer-side, MeshMaxConcurrentRequests will be replaced by “Mesh2MaxCocurrentRequests” (note the 2). Two important points in this is that the default is even lower – 8 rather than the current 32 -, and the capability to which the setting relates will be capped server-side.

    The reason for lowering the default is because under the new HTTP service, everything is more efficient and has much improved “fail-over” than is currently the case. The reason for capping the setting is to prevent inordinately high viewer-side settings causing the kind of problems they do today.

    As there will be a transitional period where both the existing capability (using MeshMaxConcurrentRequests) and the new capability (using Mesh2MaxCocurrentRequests) will be operating side-by-side (until all viewers have incorporated the new code), MeshMaxConcurrentRequests is also likely to be capped by the Lab server-side – if indeed, it hasn’t been already.

    In the future, mesh and textures will actually be combined over the same channel as the Lab introduces HTTP pipelining.


    • Pussycat Catnap
      Oct 18, 2013 @ 15:12:59

      This is good to know. Yeah back in April I read ‘concurrent’ as max that could exist at once – which would mean “dial it up baby, as mesh is everywhere” and it seemed nuts to even have a limit. But as a bandwidth dial – how much of what you download at once can be mesh is not exact but close… (in that everything in bandwidth is a trade between items all competing for the same space), and a more modest setting is ideal

      If they set it to 8, that would mean 8 items at a time, and would necessitate those 8 downloading fast enough that you’re not noticing any wait for the 9th thing that pops into your view. But a careful observer will notice this is generally already the case.

      For me the much bigger discover was the texturefetchconcurrency one – as it was set at 0 by default, and just a slight notch up changed everything about how my SL looked. But that helped me to see that I had to balance the two settings against each other. At least at present.

      Its the sort of thing that should just be handled more dynamically on their end based on what kind of content I am encountering. And if I read you right, the combined note, that’s where they’re headed.


  4. Inara Pey
    Oct 18, 2013 @ 15:27:18

    The mistake is thinking “8″ refers to objects. It’s not. It’s the number of actual connections made between viewer and servers, each of which can handle multiple packets of data.

    While more channels may seem better, it’s not. All it means is that rather than arriving in a reasonable stream hardware (router and / or graphics card) can handle, “more” of everything arrives “at once”, and problems result as the hardware struggles to handle it all.

    With the TextureFetch, some TPVs flip this up to 1.0 by default. It seems to work reasonably well.


  5. Miss D Ember
    Oct 18, 2013 @ 16:09:20

    Reblogged this on Caledon: possessed of character and commented:
    Gents, Ladies, a few minutes of your time. Please review this post and good luck with improving your SL.


  6. Uccello
    Oct 19, 2013 @ 10:38:33

    Brilliant post. Thank you. I am trying your suggestions and will tweak away, but I haven’t crashed yet so life is still a bowl of cream so far. I found that like rendervolumeLODFactor, the RenderTextureMemoryMultiple will reset to default when graphics levels are changed. As someone who often bounces between High and Ultra I’ll have to keep an eye on this.


  7. Pussycat Catnap
    Oct 19, 2013 @ 13:45:06

    Apologies if I’m slow on approving comments. My blog doesn’t usually get a lot of attention from anyone but spammers. I long ago turned on comment moderation to stop the random posts about buying fancy shoes from a Kenyan businessman needing help getting his money out of a Russian bank to buy a bride from Turkey in order to invest in Canadian chicken sweaters… :P

    While new I check my blog often, but once this post has been around for a while I might forget to log in daily again. :)

    /goes to buy some chicken sweaters.


  8. Tika.Market
    Oct 22, 2013 @ 13:09:52

    Oh wow. I finally managed to log in – takes 10 minutes sometimes. Set both of the first two settings to 20 on my pc and logged out. When I tried to log back in, it logged me in immediately. Once I recovered from the shock, I began to wander to places I’ve taken pictures of recently.

    Um – oh my! The things I had missed. It wasn’t just the rapid loading of the sim – I had not seen them in such detail, even with my graphics turned up to high. And rapid – my head fair spinned at the speed with which I could begin picking out a photo op.

    And that nasty waiting for region handshake?
    That is the reason log in takes for ever lately.
    Unless the random problem decided to trick me and hide, this setting has helped my log in speed to. Time will tell about it but THANKS!

    This helped so much.


  9. Trackback: Getting Started in Second Life | Pussycat Catnap's thoughts
  10. Lilah Munster
    Nov 29, 2013 @ 03:31:16

    Thank you. The constant rezzing and re-rezzing of textures was driving me nuts. I found this post by Googling, and changing the TextureFetchConcurrency seems to have fixed that.


  11. Trackback: MeshMaxConcurrentRequests – The new RenderVolumeLOD that’s killing what SL looks like for some | Pussycat Catnap's thoughts

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s


Get every new post delivered to your Inbox.

Join 63 other followers

%d bloggers like this: