El mejor formato de imagen (¿el más popular?) Para texturizar [cerrado]

Bien, entonces estoy usando C ++ con OpenGL, y voy a crear un cargador para cargar texturas para mi juego 3D. (Pero las texturas son 2D). Quiero la opción de transparencia, incluso si decido no usarla. Necesito una calidad decente, aunque no tiene que ser de primera categoría. ¿Qué sugieren para el formato (PNG, TGA, etc.)? Además, quizás sea algo para lo que sea fácil crear un cargador (no voy a usar uno ya creado). Y también, si tiene algún enlace / consejo para ayudar con el cargador, se lo agradeceríamos.

No entiendo por qué no querrías usar un cargador estándar. PNG , por ejemplo, es una buena opción para un formato, pero es complejo escribir un cargador de propósito general (y probablemente no valga la pena escribir uno que solo cargue el subconjunto específico de formatos PNG que le interesan).

Dado ese requisito algo inusual, TGA es probablemente su mejor apuesta. TGA 2.0 tiene un canal alfa y es relativamente simple en comparación con PNG.

El formato de textura de imagen también es una opción de rendimiento. Te recomiendo usar texturas comprimidas tanto como sea posible. En plataformas móviles, puede mejorar enormemente el rendimiento (40% o incluso más), el uso de memoria y la carga de tiempo.

Considere una textura 1024 * 1024:

• RGB o RGBA (16bits): 2Mo (.5s para cargar en SGS)
• RGBA (32 bits): 4Mo (1s para cargar en SGS)
• PVRT (4bpp): 512ko (.125s para cargar en SGS)
• ETC1 + Alpha: 1.5Mo (.4s para cargar en SGS)

En nuestros juegos, tenemos activos (texturas) en muchos formatos:

• Formato DDS para texturas DXTC (plataformas de escritorio: OS X, Linux, Windows y Tegra)
• Formato DDS para texturas ATC (GPU Andreno)
• Formato PVR para formato PVRT (GPU PowerVR)
• Formato PKM para textura ETC1 (Todos los dispositivos OGLES 2.0 compatibles)

Por fin, utilizamos el formato sin formato para compatibilidad, pero eso es para compatibilidad o elementos de GUI

• Formato PNG para textura cruda. Es para texturas RGBA de 16, 24 o 32 bits (utilizamos un cargador con licencia MIT). Es texturas sin comprimir.

Las texturas ETC1 no tienen canal alfa, por lo que utilizamos un sombreador especial con dos texturas (textura rgb y textura alfa). El formato comprimido es muy fácil de cargar (100 o 200 loc).

En el escritorio, DXTC (S3TC) está presente en muchas tarjetas. Entonces, deberías usarlo.

Texturas comprimidas

Pro

• Textura de relleno mejorada
• Carga de textura (4x o más)
• Fácil de cargar

Estafa

• No es compatible con todas las plataformas
• artefactos

Las texturas son colecciones de una o más imágenes. Esto significa que una textura podría estar representada por un TGA o PNG, pero ninguno de los formatos es capaz de representar todas las características posibles de las texturas. ¿Por qué?

Porque cada uno solo puede contener un solo imagen. No hay mapas MIP. No hay texturas 3D posibles. Sin texturas de matriz. No hay mapas de cubos. Cada uno de esos archivos es solo una imagen 2D. Pueden ser parte de una textura, pero a menos que no esté usando mipmapping (y le recomiendo no usar mipmaps a menos que tenga necesidades específicas), un solo archivo de imagen en estos formatos no puede ser una textura.

Son formatos de imagen finos, pero tienen formatos de textura deficientes .

DDS es el favorito de los formatos de textura porque en realidad es compatible con las necesidades de texturas. Es compatible con mipmaps y cubemaps. Es compatible con texturas 3D. DDSv10 admite texturas de matriz. Puede empaquetar una sola textura dentro de un DDS de una manera que no podría con PNG o TGA.

DDS admite datos de textura sin comprimir y comprimidos. Siempre que el formato de textura comprimido sea uno de los formatos de textura DXT / BC.

PKM es útil para empaquetar imágenes comprimidas con ETC1, pero al igual que con PNG, no admite características de textura reales.

Los archivos PVR parecen ser el equivalente móvil de DDS (aunque no sé por qué no podían simplemente usar DDS). Admiten varias técnicas de compresión, pero carecen de funciones avanzadas de DDSv10 como texturas de matriz, así como compatibilidad con texturas 3D.

Entonces DDS gana en términos de soporte integral de texturas.

El Grupo Khronos recomienda el formato de archivo KTX para almacenar texturas para aplicaciones OpenGL y OpenGL ES. Puede usar libktx para trabajar con este formato.

caracteristicas:

• Instanciar una textura OpenGL desde un archivo KTX
• Descomprima una imagen de textura comprimida ETC1 cuando el hardware no tiene soporte ETC1.
• Construya una tabla hash de pares clave-valor a partir del archivo KTX a medida que se carga la textura
• Escriba un archivo KTX a partir de una matriz de imágenes de origen y una tabla hash opcional de pares clave-valor.
• Construya y complete una tabla hash de pares clave-valor.

Parece DDS (DirectDraw Surface) es la opción más popular para texturas en este momento. Tiene diferentes formatos de píxeles, transparencia y compresión. Es compatible con OpenGL a través de la extensión GL_ARB_texture_compression.

Por ejemplo, hay un cargador OpenGL aquí .

Hay una serie de consideraciones aquí:

1. Qué tan rápido puede obtener la textura del disco y en la memoria del sistema.
2. Qué tan rápido puede obtener la textura de la memoria del sistema a la GPU (a través de glTexImage2D en su caso).
3. Cuánto espacio en disco y almacenamiento de RAM de video tiene en su presupuesto.
4. Rendimiento y calidad.

TGA es una buena opción porque en los casos sin comprimir de 24 y 32 bits puede leer los datos en un solo fread / lo que sea y enviar el resultado directamente a través de glTexImage2D sin más procesamiento. Es una mala elección porque puede tener el tamaño de archivo más grande y si la E / S de disco es un cuello de botella, entonces sus lecturas serán lentas.

PNG es una buena opción porque conserva la calidad de las imágenes con un tamaño de archivo razonablemente pequeño. Es una mala elección porque los PNG pueden descomprimirse lentamente, si ese es su cuello de botella, bueno, ya sabes.

JPG es una buena opción porque generalmente tiene el tamaño de archivo más pequeño y saldrá del disco muy rápido (doblemente bueno si necesita enviar el archivo a través de una red). Es una mala elección debido a los pasos intermedios de descompresión del software y la pérdida de calidad (aunque puede ajustar la configuración de calidad para mitigar esto). No hay canal alfa tampoco.

DDS (u otros formatos comprimidos) son buenas opciones debido al tamaño de archivo más pequeño y la capacidad de incluir una cadena mipmap preconstruida. Si es un formato compatible de forma nativa en hardware (y DDS es compatible de forma nativa en la mayoría del hardware de PC de consumo, también lo ha sido durante mucho tiempo), obtendrá el mismo beneficio que TGA: un fread, un poco de hurgar en el encabezado para descubrir algunas propiedades de la imagen, luego envíe los datos directamente sin pasos intermedios. Las texturas comprimidas también harán que su programa se ejecute más rápido y use menos RAM de video. Son malas elecciones porque usan compresión con pérdida (que a veces puede ser realmente notable) y pueden no ser compatibles con todo el hardware.

Si fuera yo, crearía soporte para los 4 de estos formatos (TGA y DDS son bastante triviales para escribir cargadores, con JPG y PNG usaría una biblioteca de imágenes) para que los creadores de contenido puedan elegir el formato más adecuado en una base por textura.

Y, por supuesto, siempre puede usar el viejo BMP de 32 bits que es realmente fácil de cargar (especialmente si el tamaño es una potencia de 2 (en realidad, un múltiplo de 8 bytes IIRC)).

De lo contrario, parece extraño que solo desee un formato, jpg es realmente genial para texturas de alta resolución agradables del mundo real (jpeg hace maravillas con el espacio en disco y los tiempos de carga (inactivos), png para transparencia y el BMP ocasional de 32 bits para texturas controladas (fácil de crear desde un script o una herramienta 'rápida y sucia').