Texture Compression Questions

Started by
5 comments, last by Adam_42 10 years, 4 months ago

There's a suprising lack of documentation on loading DXT compressed data into DX11. Here are a few questions:

1. Is creating a compressed texture resource as simple as passing in the BC compressed data like normal texture data, but with the DXGI_FORMAT_BC--- flags as the format?

2. How do I create mip maps of BC compressed data? I assume I should create mip maps with the uncompressed textures, and then compress them afterwards. Which leads me to..

3. How do I compute mip map offsets for compressed textures, so I can create/load them in properly? I want to compress a 2D texture array and generate mip maps before game start, but I'm not quite sure how to load them all up on resource creation.

4. Do BC formats need to be sampled in some special way, or does DX11 take care of it?

Advertisement

1. Yes. Which also answers question 3 - creating resource from compressed textures are not different than any other resource creation.

2,3.Create the textures as you normally would, then compress and generate mip-maps offline using something like DirectX Texture Tool. No need to do anything at runtime.

4. DX11 takes care of it.

3. How do I compute mip map offsets for compressed textures, so I can create/load them in properly? I want to compress a 2D texture array and generate mip maps before game start, but I'm not quite sure how to load them all up on resource creation.

The documentation explains how to calculate the sizes of blocks based on the format type, then how to use that to calculate the total size of a single mipmap within the .DDS file.
Each mipmap stored inside a .DDS file (or whatever extension you want) is directly packed following the previous, starting from the largest down. There is no padding between them.

In order to send the data to Direct3D, you simply copy each mipmap in order sequentially as they appear in memory.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

Ah, I guess I didn't realize what I was looking for when I found http://msdn.microsoft.com/en-us/library/windows/desktop/bb694531(v=vs.85).aspx#Using_Block_Compression earlier!

I understand the layout of the format, and that you have to pad texture dimensions out to be a multiple of 4 to get the correct memory offsets.

I'm still a bit unsure about what happens to mip map levels smaller than 4x4 though. Do you still allocate the full 4x4 memory for the smallest mipmap levels?


Do you still allocate the full 4x4 memory for the smallest mipmap levels?

Yes. See the section about virtual vs physical size.

It's good to understand what BC formats are, but you really shouldn't care about the gory details unless you are planning to write an encoder(not so simple) or decoder(pretty straightforward) yourself.

For encoding just use existing tools which will also create the entire mip-chain for you. Decoding is done automatically by the HW.

For encoding just use existing tools which will also create the entire mip-chain for you.

Any recommendations?

And for my last question! Are the DXT blocks from the textures organized top->bottom, left->right? I'm looking at Squish, but it only compresses singular 4x4 blocks and I'm not sure what the order of the blocks should be.

Blocks are indeed top->bottom and left->right.

For compression there's squish: https://code.google.com/p/libsquish/

You might also want to try using http://directxtex.codeplex.com/ which does a bit more than just compress textures.

For texture loading at runtime there's http://directxtk.codeplex.com/ which includes some other useful stuff too like text rendering.

This topic is closed to new replies.

Advertisement