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.
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.
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
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.