Friendly texture sizes?

I'm just getting started into construction, and I'm at the point where I need to make decisions on uploaded textures. Since these are going to be on a furry AV, I already have to be careful about how much there is to rez. I want to make sure I'm not overdoing the image size, but still conserve tiny details like hair texturing. I *could* get creative with wrapping and use the same texture for multiple parts, but I don't have enough redundant prims to get very far like that.

Since everything is converted to jpg2000- Does SL apply enough compression that squeezing the color count would make a difference in load times? Any experiments done with this by tailors in the past? The compression and body stretching will fudge on fine lines anyway, so an extremely sparse palette might not be glaringly obvious.

After spending two weeks cursing the slow rez in shopping areas, I want to make sure I optimize my own junk effectively. So far it seems like 512x512 is adequate, but would it be more neighborly to push them even smaller?

512x512 is the standard cutoff point for SL textures, you could use 256x256 on those small prims and not loose visual details

as far as using lower color counts, its not really needed

Sl uses (like you said) jpg 2k compression that requires a min of 24 bit color, back in the day if an image naturally contains less color the jpg2k redo would be smaller and load a second or 2 faster (than one with more colors)

Nowdays with the increased land mass and population theres such a drag on the asset server it doesnt make any difference, this kinda goes along in texture size, your not really gonna gain any speed when the asset server takes a few min to find the texture then transfer the image to you (yea its not uncommon to see a 16x16 take as long as a 1024x1024) course the main advantage to smaller textures is the lower client side stress ...

last thing, if you go out of your way to reduce color count (say by reducing to 32k color 24 bit ) the effect is simmilar to uploading a jpg image, it just gets more messed up and actually takes longer than a normal 16million color image

Ok, that does make sense that the asset server is a limiting factor, and it also explains why the bandwidth meter sits flat while waiting so long.

As for the colors, I don't mean reducing the color depth, I meant actually squeezing down to fewer colors used. I wasn't thinking in bit depth, I was looking at using 16 *colors* total, even if the final image uses a standard palette it'd help the compression. That's probably still worth doing for bigger textures, but I guess it's not critical.

doesnt really matter, you cant send an image with 16 colors, so you atuomaticly loose alot of the benifit right there, and again with jpg2k it would save a second or 2, in perfect situations, but it doesnt save any stress once it hits your video card which just reads it raw 16million color format

with SL's jpg 2k compression im guessing its around 70% quality (just a eyeball guess) the textures sent over the internet from LLto you are quite small in the age of broadband

just becuase i had some time to kill before heading to bed i did a little test .. a1024x1024 image saved in normal ol kinda stinky jpg format @ 70% quality still looks nice unless you zoom way in just like SL heh ... and anyways it only weighs in as a 26.6kb file, which isnt alot vs the 3mb bitmap file but it adds up, this is all due to rez, colors is a minor point

Forget about file size and worry about the amount of graphics memory needed for an uncompressed version of the texture; that's the big performance hit. A 1024x1024 32bit textures used 4MB of video ram, and if you can fit everything in your video card's RAM there is a lot of performance loss due to swapping and use of the main system RAM instead.

Use of texture sheeting (a single texture with a different offset/scale on different faces) can be a big help. For example, using a new 512x64 tetxure for a support beam is worse than re-using a 512x512 that is already in the build and setting repeats to 1x8 so only a thin strip is displayed.

And don't forget the joy of optimizing all your textures and having some idiot set up a vendor next door using a dozen 1024x1024 pics on every page. Grrr....

aye agreed in the end its the client performance, which is about wisely using resolution to your advantage if you can cram it all in 1 larger texture its the same hit and theres less request to the asset server