[TEXTURE] BC7

BC7 isn't really a he so much as it is a inanimate and gender neutral it. BC7 can't represent HDR, so for that you will want BC6H. BC7 isn't ideal for normal maps, so for that you will want BC5. If you have multiple uncorrelated single channel textures combining them in a BC7 texture would introduce cross talk, so for that you will want BC4. Not all textures need the highest quality possible. For some textures BC7 will be too large, so for that you will want BC1.

No one format is good at everything, that is until ASTC is implemented on desktop GPUs, then you will be able to replace all of those formats with one.

BC7 is pretty great and is incredibly versatile, and is probably the best choice in a wide variety of situations (Chris_F points out the exceptions well, but I'd just emphasize that when Chris_F says that "For some textures BC7 will be too large, so for that you will want BC1", he's not just talking about the amount of memory available, there's a very real performance benefit from reducing the amount of texture data that has to be thrown around, so I don't think BC1 will disappear too quick).

However, you touched upon it's main disadvantage in your original question, BC7s versatility is largely down to the fact you can choose from 8 different encoding schemes at a per block level, and many of these encoding schemes have many different partition tables and other options. This means an exhaustive BC7 encoder has to do similar work to a BC1 encoder but do it many hundreds of times. The result is that the time required to generate a decent quality BC7 compressed version of a texture is huge, it's very slow even with a compute shader to do the heavy lifting.

That said, I have no doubt though that those developing exclusively for hardware that supports BC7 (not very many people on PC yet!), will end up with the majority of their textures as BC7, especially if someone can put together a faster encoder with some clever heuristics to reduce the search space.

I'm going to take a second to shamelessly plug FasTC if you'd like a (reasonably) fast BC7 compressor. If you want a really fast one that doesn't require a GPU, you can take a look at Intel's ISPC based compressor.

http://gamma.cs.unc.edu/FasTC

http://software.intel.com/en-us/articles/fast-ispc-texture-compressor

BC7 isn't ideal for normal maps, so for that you will want BC5.

BC7 and BC5 have the same bitrate, so the only argument that BC5 is better for normal maps is that it's tailored for 2-channel data, but you can actually get pretty good BC7 encoded normal maps too with a few bit tricks. In modern day games, textures are packed so that color channels end up being uncorrelated, so you really will end up only using whatever the best format is for your game.

That said, I have no doubt though that those developing exclusively for hardware that supports BC7 (not very many people on PC yet!), will end up with the majority of their textures as BC7, especially if someone can put together a faster encoder with some clever heuristics to reduce the search space.

Doubling your memory usage is a tough pill to swallow for most console games, where RAM is always a precious resource. I'm sure BC1 will be in use for quite a long time because of that. The encoding time is also a major issue given the number and size of textures being thrown around on PS4/XB1 games.

BC7 isn't ideal for normal maps, so for that you will want BC5.

Using BC5 you have to compute the vector from the normal map like that for each pixel :

float3 MakeNormalHemisphere(float2 xy)
{
    float3 n;
    n.x = xy.x;
    n.y = xy.y;
    n.z = 1.0f - saturate(dot(n.xy, n.xy);
    return normalize( n );
}

Using BC7 you don't have to do that but the alpha channel is stored for nothing.

Doubling your memory usage is a tough pill to swallow for most console games, where RAM is always a precious resource. I'm sure BC1 will be in use for quite a long time because of that. The encoding time is also a major issue given the number and size of textures being thrown around on PS4/XB1 games.

Does that mean BC7 can't be used because of that or it's a particular case where BC7 should not be used ?

Using BC5 you have to compute the vector from the normal map like that for each pixel

A fairly trivial calculation by today's standard. The advantage is that the R and G channels are completely uncorrelated, and you have 8bpp divided between just two channels instead of 3. If anyone happens to know of a in depth comparison of BC5 and BC7 specifically for normal maps, I'd be interested to see it.

Does that mean BC7 can't be used because of that or it's a particular case where BC7 should not be used ?

I would say to use BC1 over BC7 whenever you can get away with it, e.g. whenever the quality difference will not be noticeable.

BC7 isn't ideal for normal maps, so for that you will want BC5.

Using BC5 you have to compute the vector from the normal map like that for each pixel :

float3 MakeNormalHemisphere(float2 xy)
{
    float3 n;
    n.x = xy.x;
    n.y = xy.y;
    n.z = 1.0f - saturate(dot(n.xy, n.xy);
    return normalize( n );
}

Using BC7 you don't have to do that but the alpha channel is stored for nothing.

Doubling your memory usage is a tough pill to swallow for most console games, where RAM is always a precious resource. I'm sure BC1 will be in use for quite a long time because of that. The encoding time is also a major issue given the number and size of textures being thrown around on PS4/XB1 games.

Does that mean BC7 can't be used because of that or it's a particular case where BC7 should not be used ?

I meant that those issues will most likely serve as a barrier that prevents BC7 from being used on "a majority of textures", as C0lumbo suggested. Currently in our toolset we default to BC1 for textures with no alpha data, and only use BC7 when artists specifically enable it for a particular texture.

Using BC7 you don't have to do that but the alpha channel is stored for nothing.

BC7 has many block modes, and alpha is optional. You can have higher precision without alpha if that's what you want to do.

BC7 has many block modes, and alpha is optional. You can have higher precision without alpha if that's what you want to do.

Using BC7 you don't have to do that but the alpha channel is stored for nothing.

BC7 has many block modes, and alpha is optional. You can have higher precision without alpha if that's what you want to do.

At the end BC7 can be used for everything, so only the problem to not use it always is the memory, it's bad to listen that.

Using BC5 you have to compute the vector from the normal map like that for each pixel

There's many different schemes to pack normals into two channels. Partial derivitive normal maps (storing n.xy/n.z, reconstructing with normalize(vec3(tex.xy, 1)) are pretty handy too, because they allow you to combine many layers by simply adding or lerping them together before the reconstruction step -- good for detail-normal-maps, wrinkle-maps, decals, etc...

On previous-gen games, it was common to actually store normal-maps in just the G and A channels of a DXT5 texture (wasting the B/R channels), because RGB-data and A-data is compressed separately, so there's no cross-channel compression artifacts introduced. BC5 (aka ATI2n) solves the issue of the wasted channels here.

At the end BC7 can be used for everything, so only the problem to not use it always is the memory, it's bad to listen that.

What's "it's bad to listen to that" mean?
What if you've got a specific memory limit for your game to use, and you're exceeding that limit? In that case, you have to listen if you want to ship your game...

What's "it's bad to listen to that" mean?

That mean we always have limits to have the best, we are in 2014 and we again have limits.