Compression formats

JackDCaron

In the UDK docs (https://udn.epicgames.com/Three/NormalMapFormats.html), BC5 and DXT5 both clamp to 8 bits, but BC5 tosses 2 channels, can anyone explain why the file sizes do not reflect the difference?

Uasset files in UE4 are very similar as well. Seems like we should be saving in file size for sacrificing 2 channels, no?

Thanks

wes.sau

BC5 is using the same memory footprint, just a different method for compression which instead of spreading the precision of the data representation across 4 channels, the algorithm focuses precision on just the X and Y resulting in higher quality representation of typical tangent normals data. In short, less data sets represented but at a higher precision.

My non-programmer assumption is that if it were to only use half the precision of data representation for X and Y (half the memory footprint for the compressed data storage), then the resulting normals map would look just as chunky as DXT5, therefore useless.

Here's more techy stuff:
http://en.wikipedia.org/wiki/3Dc

This ATI paper states the memory savings, presumably vs uncompressed normal maps:
http://www.hardwaresecrets.com/datasheets/3Dc_White_Paper.pdf

JackDCaron

Thanks wes. From what I've read, that makes sense. 2 channels at better compression.

One thing I haven't concluded is whether the Uasset file size is representative of performance gain, as far as changing the compression is concerned. The asset has a source path to the original texture, but it is only there as a way to fast update (re-import) any change, correct? So the asset contains the texture.

Trying to weigh the performance options of stuffing a mask into the alpha of a normal (if the file sizes end up being the same size in either BC5-no alpha or DXT5-with alpha), OR keeping the normal without alpha, compressing at DXT1 (halving file size), especially if I have secondary tiling detail normals blending in to get fine detail, and creating a separate mask file (compressed to one channel grayscale) at a lower resolution (512, 256, etc).

Basically, less draw calls + bigger file size OR extra draw call and significantly smaller files sizes. Thoughts?

referencing this discussion:
http://www.gamedev.net/topic/582176-compressed-texture-formats-dxt1-dxt3-dxt5-etc/

More:
https://udn.epicgames.com/Three/NormalMapFormats.html
http://en.wikipedia.org/wiki/S3_Texture_Compression

wes.sau

The Uasset stores an uncompressed and unmodified version of the source bitmap, so it can be modified in UE4 without requiring a reimport each time. If in UE4 editor, you look at Window>Statistics, and choose "TextureStats", I believe the "fully loaded" size is the total asset cost in the game, without the uncompressed source copy. You can also Refresh the list after trying out some different offsets and compression types to see the footprint change.

If you are concerned about runtime game memory of the textures, remember there is also texture streaming. If it is file size on disk that you are concerned most with then you'll need to look at packaging your game content and benchmarking the cooked assets.

I wonder if you are confusing draw calls for texture lookups. Adding an additional texture to a material does not affect draw calls, afaik. Additional texture lookups usually are risky for mobile games but rarely an issue for DX11 based desktop hardware and consoles.

If you're using UE4 my advice is to stick with BC5 for normal maps (for desktop games) and get extra channels from a secondary texture. The quality gain for BC5 over DXT normal maps is huge in my experience. Epic seems to use BC5 normal and a separate texture for additional masks, and generally I find that when I do what they do in their engine I run into less headaches down the road

JackDCaron

Great. Confirmed, BC5 and DXT5 share the same memory size. The quality of BC5 is noticeably better. DXT1's quality is not much less than DXT5, but at half the memory size. It would stand to keep the quality of BC5 while creating a RGBA mask file separately, even lowering the resolution a bit. (Makes sense to throw the mask, roughness, spec, etc into one file).


Thanks again