Blaze, using 256x256 without compression is not as good as 512x512 with compression. A good driver should be able to get almost no difference in image quality by using compression at most textures. It’s like if you take a 24bit picture and reduces it to 8bit palettized picture in a good paint programs you’ll see very little difference in image quality, and s3tc compression is better that palettized textures since it’s not limited to 256 colors.
For some images S3TC works worse then 8bit with palette.
> …s3tc compression is better that palettized textures since it’s not limited to 256 colors.
But S3TC is limited to 4 not arbitrary colors for each 4x4 block - 2 base colors and 2 colors interpolated between them.
It means, that there can not be, for example, red, green and blue pixels in the same block.
This may lead to wrong colors and blocky appearence.
Yes, that’s right, but for most textures the color spectrum is rather uniform. If a certain texture has very high frequency color spectrum it might not be suitable to use texture compression. Increasing the texture resolution helps avoiding some of the problems that occur with texture compression. A 512x512 compressed texture is usually better looking than a 256x256 uncompressed, but not always. The reason that texture compression looks crap in Quake 3 is that it doesn’t use larger textures when it uses texture compression.
[This message has been edited by Humus (edited 06-03-2000).]
Yes i can see that the artifacts get less noticable in 512x512, but still. Limiting the colors to 16bit and demanding that a 4x4 area only has 4colors. That has to damage the textures.
I hope i got this right, is the 4x4 block 2x16bit + 16pixels2bit=64bit=8byte instead of 16pixels32bit=512bit=64byte?
Yes, you’ve gotten it right, so a 512x512 compressed texture is the half the size of an 256x256 uncompressed texture.
If you want to use texture compression you should always increase the size, otherwise compression is rather pointless. Anyone who’s seen a screenshot taken at a Savage2000 in UT with these huuuuge textures? It surely looks awesome!
[This message has been edited by Humus (edited 06-03-2000).]
hehe, i was just writing a reply to correct it 
but i was too late
A couple of points
- High-frequency textures (the ones that look bad compressed) are horrible looking anyways. You almost never use them.
- S3TC makes things run faster (well, on S3 cards with the HW decoder, anyway) because it reduces memory access.
- S3TC makes almost no difference in image quality. If you want proof, I’ll take some screenshots with it on and off, and you guess which is which. You can’t, with a 32 bit color buffer, at least.
Hi All,
You can find a white paper on GL_ARB_texture_compression as well as GL_EXT_texture_compression_s3tc at
http://www.nvidia.com/Marketing/Developer/DevRel.nsf/WhitepapersFrame?OpenPage
and look for “Using texture compression in OpenGL”
Source code is available with the document.
In order to be able to run the demo app., you will need the Detonator 2 drivers (5.22) available on the Web site as well!
Hope this help,
Sébastien
Originally posted by Kaeto:
(snip)
3) S3TC makes almost no difference in image quality. If you want proof, I’ll take some screenshots with it on and off, and you guess which is which. You can’t, with a 32 bit color buffer, at least.
I just tried switching S3TC on and although some textures look fine, some look absolutely terrible. The problem is not detail, it’s that it looks like everything’s been crunched down to 8bit colour. All my lightmaps are horrifically banded, as is my sky-dome.
Ironically, the textures that work best are the high-contrast ones, since they don’t contain the smooth gradients that show banding. Its a shame, since lightmaps are where I would have spent the additional texture-memory.
Mike F
Are you using an S3 card or an Nvidia card?
Originally posted by Kaeto:
Are you using an S3 card or an Nvidia card?
I’m using a GeForce, Win2k, latest drivers.
I took a look at the s3tc spec and it doesn’t say with how much precision the interpolated colours are calculated - if they’re limited to 16bit colours then I suppose that would account for the banding. Does anyone know if that’s what’s happening?
Mike
Does this 16bit format include alpha, which would then be a RGBA4444?
No. In s3tc, the two colours in each block are always either 565 or 5551.
Mike F