Garbage on decompressed BC7 textures
Closed this issue · 10 comments
Hello.
You're doing very useful project. I have a project where I have texture decompression functionality. For years I used NVidia Texture Tools library, but it is very outdated and has no support for modern and mobile texture formats. So I tried to replace it with your "detex" library. However I have some problems with BC7 format decompression (I tried your library for BC7 and ETC formats - ETC1 works well, ETC2 decompression is completely wrong - but that's another issue ...)
I have code which loads BC7 textures using OpenGL, and it works well. Here you may see a screenshot of correct texture (I found a very simple one):
By the way, if I'll disable this OpenGL functionality, texture looks different - it has some color spots:
The same happens with nearly all BC7 textures. Probably I'm doing something wrong and decompressor requires some additional settings?
I can provide sample files (but I'll need to understand how to save them either in DDS or KTX format).
I hope for your support.
Thanks,
Konstantin
Hi,
Thanks for your feedback.
It looks like there is a bug in the BC7 decompression of a certain mode (BC7 has eight different block modes) that causes blocks compressed using that mode to be wrong. I will investigate this issue.
I would be interested in a sample file, but I will also look on the internet for more sample files.
One thing I have been planning to do is to add an OpenGL validation program to detex to test the compression algorithms in a reliable way. That should help catch more bugs and eliminate them.
I'll keep you posted on this issue.
Hi,
Thank you for the prompt response. I can provide you a sample file, but it is stored in binary form - so I have image data block and some information which should be filled into headers. Is there a quick way to combine them into a form of DDS or KTX?
NVTexTools has DDS saving function, but it is unaware of BC7 format.
I can handle a raw binary file. Combining them into a raw DDS file requires a little work, it would be possible using the detexSaveDDSFile function in detex. Something like:
detexTexture texture;
texture.width = 128;
texture.height = 128;
texture.width_in_blocks = 32;
texture.height_in_blocks = 32;
texture.format = DETEX_TEXTURE_FORMAT_BPTC; // BPTC is same as BC7
texture.data = LoadFileIntoBuffer("texture_file.raw");
detexSaveDDSFIle(&texture, "texture_file.dds");
I tested some BC7 files generated using the new AMDCompressCLI utility in Windows (available from amd.com), and they seem to decompress correctly using detex (tested with detex-view). Maybe it doesn't use the compression mode that gives problems in your texture files.
I've produced DDS file with your instructions, but I have no tool which could display BC7 DDS contents for verification. So I've included "raw" version as well.
The file is here (GitHub doesn't allow to attach it)
http://www.gildor.org/down/39/temp/texture.zip
Thanks, I will investigate the problem. I can trace which BC7 modes cause the problem, which should point to the right direction.
OK, it looks like BPTC mode 5 (out of 0 to 7) is causing the problem. This should be fixable.
Thanks a lot for looking at this problem!
There was indeed a bug in the handling of mode 5. The code assumed certain bitfields used for mode 5 do not cross a 64-bit boundary, but they do. It should be fixed now.
Thank you very much! It works well now.
Sorry, I mentioned before that ETC2 format doesn't work. I was wrong: I've re-checked data and found that data I thought are in ETC2 format really stored uncompressed.