Quick question about texture cache

[Thrayce Lanley]

Alright, I've been asked this question twice in the last week, and as much as I've looked, I can't figure it out, so for better or worse, here goes.

Is the Texture Cache portable from one installation to the next?

For example, I personally have a 15GB partition on my 2nd hard drive which is dedicated to the SL cache.  After a while, it gets as high as 5GB.  Now, suppose I make a backup of that cache (the whole partition with the file-structure intact), and then I reinstall the viewer.  I point the setup to the partition (which of course clears it), and re-plant the 5GB of cache from the backup into the partition.

Will the reinstalled viewer use the cache, or will it simply re-download the necessary textures, overwriting what's there?

I can go into more detail if this didn't make much sense.

Thanx.

 

 

[Alicia Sautereau]

Should work fine as they are saved by uuid

[Thrayce Lanley]

Fair enough; I suspected as much.  However, there's still another angle to this question and it has more to do with the way the viewer checks the cache to see whether the texture in question is already on the local computer or needs to be downloaded.

That is, does the viewer check all of the files in the '\cache' folder for the texture in question, or is there a list of already-downloaded textures that is kept on the local system, and updated on the fly?

If there were a 'checsum' file, I can only imagine that it would also be necessary.

Thanx. 

[Peggy Paperdoll]

As Alicia said it should work just fine.   However, for the life of me, I can't understand why people are so attached to their caches (any cache for that matter).  In Second Life the texture cache is changing constantly......everytime you enter an area that you've never been to or maybe the area you were just in a few minutes ago and somthing changed (a new object what built or added with a whole new set of textures for you viewer to cache.  The viewer is going to check the cache first for the texture(s) then either produce the texture to your monitor from the cache (quicker) or download it from the servers (placing in the cache at the same time).  In most cases you are talking about tiny fractions of a second.....to what end?  A 5 GB cache probably takes as long for your viewer to search as it does to just download the texture again from the servers.  Initially, upon entering the area, you'll take a second or two longer for everything to rezz..from that point on you're as quick as you get get with your system.  Caches get corrupted fairly easily............there's is a lot of checking, pulling stuff from, adding to the cache, and over writting data already there.  An empty cache actually helps in the long run.  A cache is meant to be temporary.......why treat it as valuable data?

[Thrayce Lanley]

Well, I suppose that settles it then.

It's not so much a matter of the cache being 'precious' to me or anything. My current setup has things tweaked for maximum R/W performance to/from the SL cache, such as the dedicated-cache partition being the first partition on a second drive (closest to the heads), on a second SATA channel (simultaneous R/W), and is defragged every day.

When the question was put to me, it occurred to me that with all the iterations of Niran's lately (sometimes two per week), it may save me a little bandwidth by recycling the cache.

Believe me, I know it's overkill; just the way I manage my system. I suppose I spent too long tweaking other people's systems and unwittingly became **bleep** about my own...lol.

Anyhow, thanx for the answers. Happy SL'ing!

[Jenni Darkwatch]

SL uses index files to know what file(s) it has already cached.

The cache contains of three subsections:

1) Sound files: WAV audio, 16bits/sec, 44.1kHz) in the root directory of the cache, simply renamed from .wav to .dsf. These sound files are always loaded fully, there's no partial loading going on.

2) Texture files: Stored in the texturecache subdirectory. JPEG2000 format, multiples of 2 in x/y size, ending renamed from .jp2 to .texture. These textures are loaded in fragments, the client queries them in chunks. Unfortunately the cache index sometimes thinks it has the full texture when it really doesn't. In that case you have a texture that never loads.

3) Geometry files: I'm a bit hazy on these, has been a while since I took them apart. They're stored as .slc in the object cache directory.

Caching helps things load faster. A lot faster, not just a few milliseconds faster. It's a shame that SLs texture caching (including TPVs) is so horribly broken. Caching isn't rocket science. Web proxys do it. Operating systems do it. Databases do it. Just SL can't get that pile of dung LL claims is a cache to work right. When LL announced HTTP texture fetch I had high hopes it'd allow using a web proxy. Except LL in their infinitesimal wisdom borked it so that no unmodified proxy will cache SL textures properly, thus negating just about any benefit HTTP texture fetching _could_ have had.

<steps off soapbox>

[Thrayce Lanley]

"SL uses index files to know what file(s) it has already cached."

This is what I figured, just wasn't sure if all of the necessary files for 'transplanting' an existing cache were in the 'Cache' folder.

From what you've said here, I assume that TEXTURE.CACHE and TEXTURE.ENTRIES are the checksum files for an existing cache.

Thanx for the enlightenment.  I learned a bit here. 

[Nalates Urriah]

When LL added indexing they also increased the max size of the cache. You can set it from the minimum to the max. I have started using the max in several viewers and a much smaller cache in others. I use separate caches for each viewer. I can't see a noticeable difference.

My large SL Viewer cache has grown to 1.2gb with 18 folders and 6,000+ files.

With the addition of mesh there are object files. They too are cached. There are way less of them.

You can use Ctrl-Shift-3 (texture console)  to see how the cache is working and whether the copied cache is accepted. 

For some time I thought the cache was a total fail. It takes so long for textures to rez, I thought they were downloading again. Before that worked on the cache that was pretty much true. But, you can watch for cache its and misses in the console. All the time is burned up decompressing the textures.

The cached files are the compressed versions. The idea is supposedly that it offers some protection for IP. The downside is every time the texture is dropped from video ram it has to be decompressed again... and again... and again.