Issue with BC4 Compression + OptimizeAlpha about directxtex HOT 5 CLOSED

Follow up : some troubles were on my end (I was writing back the indice field even though it's the data field that hold the incices... fml)

However, I did have to adjust a few things. I noticed that when decompressing the original texture, 99% of the blocks were coded with 8 values even if a lot of them had "0" as an endpoint. I changed to condition for bUsing4BlockCodec to only include 1f. I also adjusted other little things but I don't think they would matter much for you and this issue. It now works perfectly! I hope this was useful to you.

Cheers!

from directxtex.

Can you provide a code snippet of the minimal changes to address your concern?

from directxtex.

Sorry, had a little trouble with formatting on here. This was easier :
https://docs.google.com/document/d/1QsBMxPyZj9_lzJrnpqvJKkXbFfhw9CznZXGU2CePiG0/edit?usp=sharing

This is the code I use in my app (translated to C#)
Changes (other than pure C# translations) are highligthed.

I tested it with the texture provided above and none of the pixels have a difference of more than one shade of red with their original value as a byte (I.E. original : 87 red, new value = 86)

I also tested by enlarging the texture by 200% and re-importing to simulate changes and the import worked perfectly as well.

from directxtex.

In the C++ code, the bug I see for BC4 is that in FindEndPointsBC4U, the iStart, iEnd variables should be uint8_t and not int8_t. That said, it looks like the compiler ignores the sign difference here and fails to mess it up.

The name bUsing4BlockCodec is a little confusing. It refers to the "4 interpolated color values" rather than the "6 interpolated color values" as described in Block Compression on MSDN. The code does need a bit more extra commenting here to make that clear.

Your 'exact comparison' in FindClosestUNORM is an optimization which in theory shouldn't matter since fabsf should find the zero, but floating numbers aren't real numbers so that might be worth adding as well to short-cut the loop.

Note that your C# code is not forcing the use of the 4-interpolated color values case if the block contains 0, which you want to do to avoid generating transparent rather invisible alpha values. The BC4/BC5 compressors use the same logic as the original DXT2-5 (BC2/BC3) does for the alpha channel which is if alpha is 0 or 1 exactly, it uses the '4 interpolated values' mode rather than the '6 interpolated values' mode.

from directxtex.

I'm unable to repro your original issue with the texconv release from December 2016. The RGBA32 -> BC4U compression looks correct to me even with the code "as is". Did you get the repro originally using your C# code?

Note that the D3DX DXTn/BC2/BC3/BC4/BC5 compression code for alpha uses the heuristic of choosing the 4 vs. 6 case based on the min/max values hitting the boundary. Other compressors sometimes compress a given block both ways and chooses the one with the least error.

from directxtex.