Some Assembly Required…

ASTC (Adaptive Scalable Texture Compression) is a very cool and flexible texture compression format but also very complicated. Where the old BC-formats only give you a choice between 4 or 8 bits-per-pixel, you get a wide range of choices with ASTC by varying the block-size:

Partitions in ASTC are a lot more complicated compared to BC7. First of all 1,2,3 or 4 subsets are supported and instead of 128 patterns you have 3072! Also, you have 14 different block sizes instead of just 4×4.

So, 14 * (1024 * 3) = 43008 different patterns! (not counting the patterns used for 3D textures). With that many patterns, storing them in ROM is not feasible so they are instead generated using an algorithm. That algorithm is not perfect and it generates a fair amount of duplicates, and also generates patterns that although not identical are equivalent to others. Like this:

Another problem is that the patterns generated will not always produce a pattern with the requested number of partitions – in that case you should always use the pattern made for the fewer partitions since that has more bits for endpoints etc. You could argue that you should never use these patterns, but maybe that pattern is a perfect fit for the image-block you are trying to encode…

So, if we remove only exact duplicates how many patterns should an encoder look at?

..and when removing duplicates/equivalents including across sets:

A naive encoder would have to look at 3072 patterns for each block. Still, compared to BC7’s 128 patterns this is pretty insane.

Since I was curious about what the generated patterns looked like, I made this visualizer.

Here are some examples: