search

richgel999 / bc7enc_rdo

State of the art RDO BC1-7 GPU texture encoders
Other
180 stars 32 forks source link

Constant alpha = 255 and/or color is not reproduced using BC7 transparency modes #15

Open alecazam opened 2 years ago

alecazam commented 2 years ago

This is releated to this issue that still remains on BC7enc. I updated to BC7enc_rdo. This affects BC7 encoded textures. https://github.com/richgel999/bc7enc/issues/3

When pbit = 0 is chosen in the following call, the alpha reconstruct can only go to 254. This doesn't match the fully opaque textures that we are processing. We don't have this issue with ETC/ASTC encoder. For now, we'll workaround at the shader level and assume 254/255.0 is opaque when BC7enc is used.

I tried forcing use of pbit = 1 for opaque textures. This results in correct fully opaque textures, but on a red-black checkerboard, the pbit of 1 results in 255,1,1,255 as the final color, when it should be 255,0,0,255. This transparent mode that is chosen seems to be incapable of reproducing the original texture accurately. The pbit limits the reproduced rgba components - even pbit results in even, and odd pbit results in odd values. So bc7enc probably needs to support one of the opaque mode, where the color bits don't affect the alpha. 

static uint64_t find_optimal_solution(uint32_t mode, vec4F xl, vec4F xh, const color_cell_compressor_params *pParams, color_cell_compressor_results *pResults)
{
....
      for (int p = pParams->m_has_alpha ? 0 : 1; p < 2; p++)
castano commented 2 years ago

Alec, you may want to look at the changes in this branch: https://github.com/CoriolisStorm/bc7enc_rdo/commit/d651cfdd16c1ef26ca9298ef0e3eb0bc7e29bdf9 I think this does the "force pbit to 1" solution you suggest, but as you point out introduces error in other channels.

richgel999 commented 2 years ago

Got it - it's clear I need to revisit this problem.