how fast can you switch between textures?

Would like to know how fast you can switch between 2 or more textures on a flat prim. Im sure the bigger they are, the slower the refresh time.

Geuis

There's a built in .2 sec delay

ok so max 5 frames per second. Cool. Thanks.

You should also keep in mind, that the .2 second delay doesn't account for time of loading or rezzing the texture..

I have an object that uses three textures on eight flat 10x10 squares.. it only sets the textures on one side for each cube.. even when gong from one texture to the next adn directly back to the first, I find i have to wait a moment for the texture to reload.

MUCH faster than I can see it! Bandwidth and machine speed are limiting factors for some of us. [...and this is just for the updates, not including downloading the images themselves.]I doubt it has much affect on the refresh time, but it is certainly true that the larger the texture, the larger the NetLag waiting for them to download into the cache.

Oh, and if they`re too big, they WILL overflow the video RAM, and cause VRAM-lag.

Please, don`t take this as a complaint as much as an advisory: Some people do avoid places that do too much of this.

It depends how you go about it. llSetTextureAnim() can be a good way of maybe not exactly switching between textures, but rather for changing focus on a smaller subset of single image.... but if you happen to combine your textures into single picture the end effect is the same, plus there isn't no load and texture change delay. Potential drawback is lower resolution per image, but in regular situations it's not much of issue.

If you just want to flip back and forth between two textures, myou should construct a texture with two frames and use llSetTextureAnim. That can flip back and forth pretty much only limited by client framerate.

my 2 cents

yes use texture animation if you can ... 1 download for the user and no grey time between images

no size doesnt really matter that much on download times, jpg2k compression that SL uses cushes the files quite well... a large (not obnoxiously large) image will come out to a handfull of kb which would take litterly seconds to transfer, even over dial up

but PLEASE do not use large images for everything, once they hit the clients computer they deflate which kills video ram and gpu power, work out a balance between the min detail you NEED with the smallest canvas size possible for all the images to fit in

[book]

in "the day" yes you could see a noticable difference when waiting for images, a 16x16 would load "almost instantly" but nowdays, with the increased overall load on the servers, its quite often the case you end up waiting for the server itself

at this point it becomes a dice roll, will that 16x16 image load up before this 1024x1024? sometimes yes sometimes no, which goes back to the suggested texture animiation post(s),

its only 1 image that has to be requested, qued, found, sent, read, and rendered per user (4 256x256 images is the same client stress as a 512x512 image, why wait 4x as long for the 4 images)

llSetTextureAnimation has different effects and combinations, along with a much faster speed limit ... i usually stop noticing the speed increases around 16-20 fps (with sl running 30ish fps)

theres also llOffsetTexture and llScaleTexture, which is slower, and is not good for animation... this way is simulator side, which basicly means each time these functions are ran it adds a blip of sim usage, texture animation is client sided, once its on its basicly a flag for the client to deal with.

the advantages are, its easier to deal with, (texture animation is ALOT more fun) and you can have a bit more control with it, ie a game where you need everyone to see the next image at the same time (texture animation is totally depenant on the client, and at high speed you could see it on frame 8, and jane av behind you sees it on frame 16)

[/book]

Anyway, i have and could go on forever this is a subject i really enjoy