Taylor Bishop
Taylor Bishop

Reputation: 519

No three-component 8bits-per-channel DXGI texture format in D3D11?

Currently implementing a D3D11 renderer, and the majority of my normal maps are in 3-channel RGB 8bits-per-channel format.

Looking through the DXGI_FORMAT msdn page I've noticed that there's no option for this. What's the reasoning behind this? How would I use this texture format then?

Upvotes: 1

Views: 1431

Answers (1)

galop1n
galop1n

Reputation: 8824

There is no hardware that support a 24bits format texture for a good decade now.

You have different options now :

  • Expand to 32bits. You retain the full quality of the bitmap at the price of an extra memory cost, no extra processing need.
  • Use a compressed format. This is where you should head.

GPU are not the best at reading a lot of uncompressed textures. Of course, if you are only rendering a few models, it won't matter, but if you start pushing a larger amount of data, you have to go to the compressed road.

Your compression options if you support very old hardware:

  • BC1, RGB format with 4bits per pixel, worst quality, use only with giant textures when the saving overcome the quality, or better, never use it.
  • BC3 with Red/Alpha swap, 4bit per pixel, just slightly better.

You should consider these instead :

  • BC5 : 8bits per pixels, 2 channels, you will have to rebuild Z with sqrt(1 - dot(n.xy,n.yx)) or an equivalent tricks.
  • BC7 : 8bits per pixels, 3/4 channels, the best choice if you need to store something else with your normal, like a variance. This format is great but is also very CPU intensive to generate at his best quality.

On a side note, do not forget to generate a mip chains up to an 1x1 size, it is both for performance and visual quality. Do not apply a SRGB conversion like you should have for your albedos ( 0.5 is really 0.5) and you have options with some formats to use an SNORM type to skip the typical 2*n-1 formula but be carreful with the 0 case.

Upvotes: 3

Related Questions