11-20-08 - Pointless

I keep thinking about pointless things and I have to remind myself to stop.

One is texture compression, as I just mentioned. As long as the hardware needs DXTC, there's really not much I can or *should* do. I'd have to decompress then recompress to DXTC which is just pointless. Stop thinking about it.

Another is antialiased rasterization. Particularly in LRB I think you could do a pretty sweet exact antialiased rasterizer. But it's pretty pointless for 3d. It might be nice for 2d, for fonts and vector graphics and such, but in 3d the bad aliasing isn't even because of edges. The bad aliasing comes from various things - mainly failing to filter textures well when they aren't plain color textures (eg. mip-mapping normal maps), or aliasing due to lighting, and especially reflections (BTW specular is a type of reflection). Fresnel specular reflections are the worst because they're strong right at edges where you have very little precision, so they sparkle like crazy. To really handle these cases you need something like adaptive super-sampling (putting more samples where you need more detail). And to really do that right you need your shaders to return frequency information or at least derivatives.

... but I'm not thinking about that any more because it's pointless.

Oh and I should mention some other things about texture compression while they're in my head.

1. While the fixed block size is really bad for RMSE, it's not quite so bad for perceptual error. What it means is that you put "too many" bits in flat areas and send them almost perfectly. In noisy areas you don't have enough bits and send them very badly. But that's sort of what you want perceptually anyway. It's not actually ideal, but it's also not horrible.

2. One thing that none of these formats do is take advantage of mips. Assuming you always have a full mip chain, and you're doing trilinear filtering - then any time you need mip M the hardware already have mip M-1. Obviously you could do very good delta compression using the previous mip. For something like paging the situation is a little different, but you could certainly require that you have the 16x16 mip always in memory and at least use that for conditioning. I haven't really thought about this in detail, but obviously sending a whole mip chain without using the information between them is very wasteful.


Autodidactic Asphyxiation said...

What do you think about texture-space lighting? That could help with the aliasing issues even if trilinear filtering normal maps is wrong.

Ivan-Assen said...

What do you think about direct-decompress-to-DDS algorithms? There's still redundancy in DXTn; our DDS files used to zlib about 2:1. With artists getting better at packing and making the textures interesting, it is slowly going down, but it's still an overall win, and something that knows about the structure of DXTn should perform quite a bit better than raw zlib.

cbloom said...

"What do you think about direct-decompress-to-DDS algorithms?"

I think it's a good way to go. In the short term it seems like the best option is to have DXT1 textures in memory, and some kind of DXT1-recompressed textures on disk.

I've been trying to find prior art on recompressing DXTC but I can't find anything. I guess this is what "MCT" is on Xenon but they seem to be keeping the details secret.

I can't really see the win from the "id style" approach of using a heavy lossy compressor on disk and then decompressing and recompressing it to DXT1 or DXT5 in memory.

old rants