DDS 텍스처 검사기

기록하는 도구마다 값이 제각각이고, Direct3D 자체도 이 값을 믿지 않고 다시 계산하기 때문입니다. 원래는 비압축이면 한 행의 바이트 수, 블록 압축이면 최상위 레벨 전체 크기를 넣어야 하지만 다르게 쓰는 내보내기 도구가 많습니다. 예를 들어 Pillow는 블록 압축 파일마다 (너비+3)×4를 넣어서, 데이터가 128바이트인 16×16 DXT1 파일에 76을 적습니다. 그래도 아무 문제가 없는 이유는 로더가 어차피 너비·높이·포맷으로 배치를 다시 구하기 때문입니다. 이 페이지도 같은 방식을 쓰고 선언값을 계산값 옆에 보여 주므로, 어긋남을 그대로 물려받는 대신 눈으로 확인할 수 있습니다.

블록 압축 포맷은 4×4 블록보다 작은 단위를 저장하지 않습니다. 1×1, 2×2, 3×3 레벨도 블록 하나를 통째로 차지하며 BC1과 BC4는 8바이트, BC2·BC3·BC5·BC6H·BC7은 16바이트이고, 남는 텍셀은 디코딩할 때 그냥 버립니다. 2의 거듭제곱이 아닌 크기에서도 같은 패딩이 붙습니다. 13×7 표면은 ceil(13/4)×ceil(7/4)=4×2, 즉 픽셀 91개에 블록 8개입니다. 블록 수를 세지 않고 너비×높이×픽셀당 바이트로 계산하면 모든 레벨이 작게 나오고, 레벨이 헤더 없이 이어 붙어 있으니 크기 하나만 틀려도 그 뒤 전부가 어긋납니다.

원래 픽셀 포맷 블록은 네 글자 코드나 채널 마스크로만 포맷을 지정할 수 있고, 텍스처 배열이나 새 블록 포맷을 적을 자리가 없습니다. DDS_HEADER_DXT10은 숫자로 된 DXGI 포맷 열거값(BC7_UNORM은 98, R8G8B8A8_UNORM은 28)과 리소스 차원, 0x4 비트로 큐브 맵을 표시하는 기타 플래그, 배열 크기, 그리고 색이 스트레이트인지 프리멀티플라이드인지 기록하는 알파 모드를 담습니다. 128바이트 헤더와 픽셀 데이터 사이에 들어가므로 이런 파일은 데이터 시작 위치가 148이 됩니다. 128이라고 가정하는 리더는 헤더를 픽셀로 잘못 읽습니다.

BC7은 파티션 표와 엔드포인트 정밀도, 인덱스 배치가 제각각인 블록 모드가 여덟 가지이고, BC6H는 하프 플로트 HDR 포맷이라 일반 디스플레이에 보이려면 톤 매핑이 먼저 필요합니다. 둘 다 원리상 디코딩할 수 있지만, 구현이 조금만 틀려도 눈에 띄는 오류 대신 그럴듯한 쓰레기 그림이 나옵니다. 그래서 이 페이지는 포맷과 밉 체인과 헤더 전체를 보여 주되 픽셀은 디코딩하지 않는다고 분명히 밝힙니다. 실제로 보려면 texconv나 Compressonator로 변환하거나 블록을 GPU에 넘기는 뷰어로 여세요.

거의 확실히 아닙니다. BC5는 정확히 두 채널만 저장하며, 각각 BC3의 알파 블록과 같은 8비트 보간 블록입니다. 노멀 맵을 일부러 그렇게 저장합니다. X와 Y만 두고 Z는 셰이더에서 sqrt(1 − X² − Y²)로 복원하는데, 단위 벡터의 자유도가 둘뿐이기 때문입니다. 빠진 것은 없습니다. 한 채널만 두는 BC4도 마찬가지로 러프니스나 하이트, 앰비언트 오클루전 마스크에 쓰이며, 채널 하나에는 고유한 색이 없으므로 여기서는 회색조로 보여 줍니다.

큐브 맵은 면마다 완전한 밉 체인을 하나씩 갖고 +X, −X, +Y, −Y, +Z, −Z 순서로 구분자 없이 이어 붙습니다. caps2 필드에 0x200 큐브 맵 비트와 면별 비트가 하나씩 들어 있습니다. 16×16 BC1을 전체 체인으로 여섯 면 담으면 표면 데이터가 184바이트가 아니라 1104바이트입니다. 면은 실제로 빠질 수 있습니다. 규격이 어떤 부분집합이든 허용하고 파일에는 비트가 켜진 면만 들어가므로, 여기서도 여섯 면을 가정하지 않고 비트에서 예상 크기를 계산합니다. 비트가 주장하는 면 수를 파일이 담지 못하면 배치 블록에서 부족분으로 드러납니다.