"Cache"

I would like to poropose that we have an area on the hard drive of our computers set aside for the textures we download as we move through Second Life.

This "cache" (as it would be called), would save up to one or two gigabytes of texture files, scripts etc. so that we would not have to load them "on the fly" as we move around.

Possibly some algorithms could even be introduced so that things like our home sim (or at least our own homes) and the faces and clothes of the friends standing around us could be identified as textures we frequently access and thus stored more reliably. I know in my home sim, almost everything in it including all textures should be possible to store in a "cache" of under a gigabyte or so.

I found out from reading the documentation on my web browser, that "cacheing" as it's called is used all the time in other applications and I think Second Life would be a great type of applicatoin to try applying this technology to.

Think of the speed improvement!

SL has a cache. You can set the size under preferences->Network then click 1G size.

So why does it reload the textures and scripts every time i go out of my home sim? Not a very good caching system if when after i fly around 3 neighbouring sims, i return to find myself facing a home sim that's 90% missing and the rest nothing more than grey squares.

Danm! That's a clever idea Dianne.

I did some research too and found it IS on the 'to do' list for SL.
Unfortunately it's been assigned a lower priority than 'Havok2', 'SpeedTree', HTML on a prim', etc.

So in the meantime you'll just have to make do with loading every single texture from scratch every time your viewpoint alters. Don't knock the developers though - a LOT of effort went into developing GreyLife™...

It would be especially nice if you could go to a location and choose "Save cache" and it would create a special cache folder for that area which is only cleared if you've been inactive for a while. It could do your home by default, and let you choose one or two additional places (or any number, hey it's your hard-drive!).

An advanced, efficient caching system IMO should be LL's HIGHEST priority, as it would cut down lag by a huge amount.

Basically just anything that YOU frequently load should be kept for much longer than stuff that you whizz past. Textures in your inventory (excluding snapshots perhaps) should be kept by default as well. My home is made entirely from my own textures, which I have on my hard-drive anyway, yet I have to load it all almost every time I visit!

I've got 80gb of free HD space, I really shouldn't need to load things all the time

I've been looking into this problem alot, what i've seen so far it seems to be a memory/image list problem more than a cache issue

Basically theres only so much ram on a graphics card and when that gets full the image list has to drop images off the end of its list or reduce their quality, this seems to be taking a time before it fetches the closer image from the cache, this is not helped by some cards not having all the memory being made available (i think)

The work around for now try and see if reducing your draw distance helps as this reduces the number of textures loaded far away and concentrates them closer.

Good thinking Nathan! How about 16 colours @ 640x480? Even better - text only.

We aren't getting what we pay for.

Surely you know that app requires a 32bit dsiplay and the screensize doesnt reflect the scene thats being displayed so why would that affect it?

Maybe next time i keep my mouth shut and dont post what i found out as a paying customer too, hows that?

Apperantly you didn't do your research enough. If you look at what textures are being processed by SL (ctrl+shift+3 I believe) you'll see how much of your card's video memory is being used. Out of my 256mb ram on my GeForceFX 5500, only 64 seems to be used. For some its a little more for others a little less. But SL seems to never use all your videocard's memory. Then again SL barely uses any of your videocard's capabilities and relies soley on your CPU & system ram for just about everything except ripple water. Makes me wonder why LL even bothered adding graphics accelerator support in the first place if they're not even using 1/4 of their full capabilities. Besides coding direct GPU instructions into graphics plugins for ATI and nVidia cards would to add Hardware T&L support wich offsets some of the workload from system to the videocard. Just about every card now a days has Hardware T&L and just about every game on the market uses T&L as well because it does it job that well. Yesterday I made a proposal to add HW T&L support, I hope everyone votes.

http://secondlife.com/vote/index.php?get_id=812

Actually i have done the relevant research posted earlier in a different forum, although you seem to be quoting results that show texture memory use only (from the texture console), my results were gained from overall object use. Please see this thread in the technical issues forum for more details

/111/fd/78085/1.html

I have 3GB of RAM, I've never seen SL use more than 480MB, but I've seen lots of slow texture loading.

The client does seem to be able to use ram to hold textures but it has a bigggg framerate hit probably due having to keep swapping them across the system bus.

I have a second pc here with a ati9700 with 64Mb i have added the -noprobe option to the command line startup and am currently running sl with the 256Mb graphics option, that card is also stuck at this magical 160Mb GL limit with 133Mb of textures in view

Well I also have 256MB of video RAM, and anyway, while the system bus may be slower than the internal video memory bus, I find it very hard to understand how it could possibly take 10's of seconds to a few minutes to load textures from anywhere except the server. There is no floppy disk (or punched tape) available on my system.

I regularly edit multi-megabyte images which load from the disk in less than a second, and once cached are repainted instantaneously.

There is something very broken with the client side caching.

Something specific I've noticed: ground terrain textures are slow to load. Sometimes I'll go to an area, it takes a few minutes for the ground to load (after a lot of other things have loaded), and it finally shows up. Then, I'll explore around for awhile, and then TP to another place that uses the EXACT same ground textures. And... they have to load again.

Has anyone else noticed this too?

Well the feature request was *slightly* tongue in cheek, but smarter an dmore knowledgeable people than me have pretty much proven that the local cache is simlpy *not* working. There is no reason why walking around the corner from your house should make all the textures have to reload when you walk back around the same corner mintues later.

Also in my case my house is a geodesic dome and uses only *2* textures for the dome part, each is 128 by 128. Aas far as I can see, they should be on m graphics card or in the cache, but they have to beloaded every time. I mean its my house, it should never *not* be cached. certainly not when the whole thing takes up less than 1 meg of space. My web browser out performs that by a country mile.

Because its setup not to use that system memory (it is extremely slow when it does, like 1-2fps), so when it reaches the limit in the video card the client has to decide what images in the distance to unload or reduce their detailing before it can load more images into view, so even if the images are in the cache the client wont load them until the image list has free'd up some available memory.

As far as terrain goes it may be the same reasons, combined with their complexivity, terrains are made up of 8 images per sim 4 x 128x128 24bit tga's and 4 x 512x512 24bit tgas

It's not the cache doesn't work, it's that the code to download assets is borked. (the cache already does store textures, images, sounds, animations, clothing) textures aren't being properly requested. The rendering engine looks good but it's been given a lobotomy.

Same here - 4Gb and SL only uses about 500Mb. Having said that, I've never seen more than just over 2Gb used no matter what I'm running, so I think it's a Windoze issue as much as a SL issue.

Wish I'd known about it before I got the RAM though...

It's pretty obvious that the order in which textures are loaded has changed Torley. Previously GreyLife™ loaded land textures first, currently it doesn't, so, instead of the sim loading and being scattered with grey rectangles you now get the grey and white grid for a while, with some object textures loaded.

Rumour has it there werre many hours of high level confrences deciding on the precise order in which things would load (sadly this left no time to figure out how to load them quickly - but that's (corporate) life).

Interestingly the other day I landed in my sim and watched while the area I was standing in slowly loaded three inappropriate ground textures in sucession, before finding the correct one... I thought this was very odd behaviour!

I have noticed something really interesting. I find that textures seem to take longer and longer to load, until finally I can have a whole sl session in one place without all the textures having loaded.

So when I come in and it seems that the texture loading has come to a standstill, I clear my cache, and then relog. When I do that and log in, the textures appear instantaneously, even though they hadn't loaded before. For a while after that texture loading is quicker than before, but then it slows down again.

I've seen the exact same behaviour - almost as if once the cache (1GB in my case) is full it's unable to actually replace files that it's downloaded.

The fact that we have to restart SL to clear the cache would indicate to me that either the texture files are locked while SL is running and it cannot therefore delete them; or the client has problems identifying textures that it's not currently using and removing them, therefore LL has made it so that we have to remove them all (and we therefore restart so it can download it's current textures again).

Interesting - I'm sure I saw somewhere that the cache file IS locked while SL is running.

Um, maybe SL can write to the cache while it's running, but CAN'T delete unwanted items from it?
Could this be why it's necessary to reboot to do a 'preferences' cache clear?

This seems like a permissions problem with the client. Ouch!

Why do I sometimes get this 'two steps forward, 1 pace back' feeling about SL development?
It's immensely frustrating.
It also makes me wonder, is it the developers fault? Or is the entire SL server/client system now so patchwork that it's not possible to do much with it without breaking something(s)?

Files often get locked while in use, its to stop you deleting them while the application is in use, which would cause the application to panic if its expecting to find a cache file there.