Texture compression

[supertuxkart-sourceforge-migration]

Author: funto66

As samuncle asked me to open a ticket for that, here it is:

STK doesn't use any texture compression. In a quick test I made, AMD CodeXL counted around 300MB of texture memory in Fort Magma. That could be highly reduced by using texture compression. DXT1 has a compression ratio of 6:1 and DXT5 of 4:1 (which one to use depends on the presence of an alpha channel - DXT1 supports up to 1 bit alpha).

Those are the standard compression methods that are supported virtually by all GPUs (but not by all drivers - there are patents issues, so open source driver do not necessarily support those). Maybe ETC2 or other methods (BC6/BC7?) could be interesting, but I think DXTn would be fine.

Benefits of using texture compression are both in memory and speed (as texture cache misses would be minimized).

DDS is the only file format that supports DXTn compression natively, but support for it is quite lacking (the GIMP-dds plugin crashes for me, the original tool for manipulating it is the DirectX Texture Tool, which is obviously Windows-only).

My view on adding texture compression to STK is:

• texture compression should remain optional for compatibility reasons with open source drivers
• we need to modify Irrlicht to add texture compression support (glCompressedTexImage2D instead of glTexImage2D)
• NVTT would be the library of choice for DXTn compression -> http://code.google.com/p/nvidia-texture-tools/
• decompression can be manually written as it's much easier than compression

On developing the feature:

• iteration 0: compress the textures before sending it to the GPU (= modify Irrlicht + use NVTT according to the availability of the feature)
• iteration 1: add a cache of compressed textures to fasten loading times -> problem: we need to be able to detect when e.g grass.png changed so that the changes are reflected in-game (= the cache entry for this texture is re-computed) -> we could use a hash for this, which would be stored in the cache -> that means the hash has to be recomputed every time -> alternative would be to have the user manually re-generate the cache -> I don't like this idea as the average user who wants to modify a texture to have fun modifying STK wouldn't understand why his modifications aren't visible in-game, and that would discourage people from modding STK. Maybe that's not that an issue...(at least it is not for "normal" players) -> the cache shouldn't be part of the download, as it would be much bigger than the JPEG or PNG compressed sources.

Migrated-From: https://sourceforge.net/apps/trac/supertuxkart/ticket/1059

[supertuxkart-sourceforge-migration]

Author: curaga Current irrlicht trunk supports DDS compressed textures fully. It's still work to refresh it though.

Regarding VRAM usage, it should be pointed out that before this summer, the artists had no way of knowing if a texture was suitably sized. Only now with my branch/the mipmap view they can see if a texture is too big or too small.

Using the mipmap debug view to identify too large textures would help everyone, while compressed textures only the blob users. Some examples of too large textures are Sara and the rope of Hacienda.

[supertuxkart-sourceforge-migration]

Author: funto66 Cool, then an update of Irrlicht seems the way to go.

It is right that too large textures should be spotted and reduced, and the mipmap view is a great tool for that. However, texture compression would basically divide everything by a factor of at least 4 and not require any work on the artist's side. Obviously, ideally we should do both :)