Open wet-dog opened 1 year ago
The -fixbc4x4
switch is a bit of a hack, so it really depends on how the original compressor handles 1x1, 2x1, 1x2, 2x2, etc. size blocks. Most of them do it by pixel replication which is probably what's showing up here.
I'll have to see if there's a good way to 'clear out' the originally unused pixels, but I'm not sure how to do that robustly.
Would it be possible for texconv to pad the images before compression?
DirectXTex compressor uses the same pixel replication pattern as D3DX did for blocks that are less than 4x4 in size, which is where the 'artifact' you are describing comes from.
I'm getting artifact pixels when running
texconv -fixbc4x4 -m 1 -y file.dds
on some files where the top-level width & height are not multiples of 4.Input DDS Output DDS
I'm using the latest January 31, 2023 release of
texconv.exe
.