Thursday, June 17, 2010

Texture compression II

I've made some more progress on the compression code.
I have >6000 128x128 pages, created from Quake 4 textures that I'm using for testing purposes.
Right now the average page size is roughly 2kb.
There's one page of 10kb, and two more that are almost 9kb, other than that none gets higher than 6kb.
I could get more compression out of this, but not without degrading quality beyond where I would like to go.
Average decompression time is 8ms, but I haven't made any attempt at optimizing.
I can compress all the pages combined to 31x their original size.

I'm wondering how id software do their compression though..
According to their latest presentation (id Tech 5 Challenges: From Texture Virtualization to Massive Parallelization) they compress each page to about 2-6kb, but that's diffuse, normal + specular.

But I'm only compressing diffuse here.

I know they're using DCT, they even have some papers published about older versions of their compression routines, but so far I haven't been able to get it down to these sizes without seriously degrading quality.

Perhaps, because of all the real-time lighting etc., it's perfectly fine to really compress textures all the way down to the point where the artefacts are really obvious, simply because they won't be as visible in a scene as it would be in a 2d picture.

Perhaps, I'm nitpicking too much when it comes to quality.

I'm also using SSIM for texture quality assessments now.
It's not perfect, but better than PSNR.


  1. Hi! interesting compression posts.

    Concerning compression artifacts, to my opinion, there is not so much dynamic lighting, lighting in Rage, it seems that they also bake diffuse lighting in the diffuse texture.

    There is a couple of gameplay video around and you can see that no shadow is casted on caracters.

    Also, the videos show the xbox360 version and you can see some nice popping some times :)

    Links to videos:

  2. Hey Sander, great to see some virtual texture related updates, very interesting.

    Can't verify this with a quote (I don't think they'd be advertising this point), but my understanding is that they've abaondoned shipping diffuse+normal+spec in favor of only using diffuse for the environment, and diffuse+normal for dynamic objects (i.e characters, and likely using a lower resolution for the normal maps than diffuse).

    They can get away with this because the lighting is baked per-texel, so while they do use normal maps on everything, once the lighting is baked, only the diffuse needs to be used because it retains all that high frequency detail with the baked lighting.

    When they do have dynamic lights they'll just be using vertex normals for the environment and maybe normal maps on dynamic objects (Can't verify this with observation because the only dynamic lights I've seen are from gunfire which doesn't last long enough to be able to observe with compression artifacts in videos, and in screenshots the light from gunfire seems to be disabled... which would make sense if they were using vertex normals and don't want to show it).

    So I don't think id has a solution for compressing textures better, they're getting the same results as you, just being a bit secretive about what they're actually storing in their megatextures.

    Here's a couple of examples of gunfire in screenshots with lights disabled.
    Also note that nothing has any kind of specular reflection, I guess they designed the look of the game around the limitation of having no specular maps and made everything look dry and rough.

  3. Hmm, just read the paper again, and it does seem to indicate that 2-6kB goes in, 40kB comes out.
    The 40kB would break down to something like two dxt5 and a dxt1
    (16+16+8 = 40)

    This had me a bit confused, but I think what they mean is 2-6kB is the typical size for a page because the typical page only has diffuse, and nothing else, but the output is still 40kB because there's still three full size page buffers for bump and spec and alpha, even if a page doesn't have anything to write to two of them, or just writes default values.

    I think that makes sense..?

  4. Right, that would explain the 2kb to 6kb thing.
    On the other hand, in their (relatively old) presentation they're clearly talking about diffuse, specular and normals ...

  5. The two DXT5 + DXT1 thing makes sense.
    It would imply that they are really storing diffuse, specular, normals and alpha.

    On the other hand they might still bake things into diffuse most of the time and use default values for the other channels.

    I still don't see how you could store all of that in only 6kb without some serious compression.
    That being said, from what I've seen so far, RGB is actually the hardest to compress.
    Perhaps, as I mentioned, with real time lighting artefacts in the RGB channel aren't too visible.
    So that might be heavily compressed.

    And for all the other cases, they're simply baking it into the diffuse channel.


To you spammers out there:
Spam will be deleted before it shows up, so don't bother.