Presupuesto de texturas BC, ASTC y ETC2 en dispositivos reales

Presupuestar la representación que se sube a la GPU

Un archivo de imagen de origen pequeño no implica una asignación pequeña en la GPU. La compresión de bloques para GPU permite acceso aleatorio acotado a grupos de texels; la compresión para distribución y el tamaño del contenedor responden a preguntas distintas. [2][3] Registra el formato que realmente se sube tras importar o transcodificar y después inspecciona su asignación residente en el dispositivo de destino.

Separa en el presupuesto la capacidad de almacenamiento, el tamaño de transferencia, el tiempo del codificador y el coste de muestreo. Un único porcentaje de compresión no puede describir los cuatro.

Ajustar los formatos a los canales admitidos

BC1 almacena un bloque de 4 × 4 en 8 bytes; BC5 y BC7 usan 16 bytes para ese mismo bloque. Sus capacidades de canales difieren, y la compatibilidad en Direct3D depende del formato y del nivel de funciones (feature level). [1]

ASTC mantiene un bloque de 128 bits y varía el número de texels que cubre, lo que permite distintas tasas de bits. [2] La compatibilidad con ETC2/EAC forma parte de OpenGL ES 3.0, mientras que otras API usan sus propios mecanismos para consultar capacidades. La guía de Khronos enumera comprobaciones concretas de formatos y funciones, incluidas las funciones de compresión de Vulkan. [3] Evita deducir la compatibilidad solo a partir de la etiqueta «escritorio» o «móvil».

Calcular el almacenamiento redondeado por bloques

Toma como ejemplo ilustrativo una textura base de 2048 × 2048. BC7 necesita 512 × 512 bloques de 16 bytes, es decir, exactamente 4 MiB. ASTC con bloques de 6 × 6 exige redondear cada dimensión hacia arriba hasta 342 bloques: 342 × 342 × 16 = 1.871.424 bytes, aproximadamente 1,78 MiB.

Son tamaños de carga útil del nivel base, no asignaciones completas ni una equivalencia de calidad. Suma cada nivel de mip con su propio redondeo por bloques, además de las capas de array, las caras de cubemap y cualquier alineación propia de la plataforma. Un fallback que se expande a píxeles sin comprimir vuelve a cambiar el presupuesto. Mantén esta aritmética junto al informe de texturas observado en la compilación.

Comparar los errores donde importan

Crea un conjunto de prueba pequeño con degradados suaves, bordes alfa nítidos, color con ruido y datos de normales. Codifica cada formato aplicable con los ajustes elegidos y luego inspecciona el resultado importado con el shader real. Comprueba las normales con reflejos en movimiento y las máscaras en su uso con umbral; una vista previa RGB agradable puede ocultar errores funcionales.

Varía el esfuerzo del codificador por separado del tamaño de bloque. Registra el tiempo de compilación y comprueba si una mejor codificación elimina el artefacto molesto antes de aumentar la memoria de toda una categoría de recursos.

Definir las excepciones de forma deliberada

Ningún formato con pérdida es ideal para todas las señales. El texto fino, las máscaras binarias y los canales de material especialmente sensibles pueden justificar otro formato u otra resolución. Mantén una regla de excepción clara y verifica que los fallbacks de cada plataforma la implementen.

Entrega la representación probada más pequeña que cumpla el requisito visual en los destinos admitidos. Vuelve a comprobar el formato subido cada vez que cambie el importador, el transcodificador o la plataforma de despliegue.

Fuentes

• [1] Texture Block Compression in Direct3D 11 — Microsoft.
• [2] ASTC Format Overview — Arm.
• [3] KTX Developer Guide — Khronos Group.