Meilleur format d'image (le plus populaire?) Pour la texturation [fermé]

D'accord, j'utilise donc C ++ avec OpenGL, et je vais créer un chargeur pour charger des textures pour mon jeu 3D. (Mais les textures sont 2D). Je veux l'option de la transparence, même si je décide de ne pas l'utiliser. J'ai besoin d'une qualité décente, même si elle ne doit pas être de premier ordre. Que proposez-vous pour le format (PNG, TGA, etc.). Aussi, peut-être en faire quelque chose de facile à créer pour un chargeur (je ne vais pas en utiliser un déjà créé.). Et aussi, si vous avez des liens / astuces pour aider avec le chargeur, ce serait apprécié.

Je ne comprends pas pourquoi vous ne voudriez pas utiliser un chargeur standard. PNG , par exemple, est un bon choix pour un format, mais il est complexe d'écrire un chargeur à usage général (et ne vaut probablement pas la peine d'en écrire un qui ne charge que le sous-ensemble spécifique de formats PNG dont vous vous souciez).

Compte tenu de cette exigence quelque peu inhabituelle, TGA est probablement votre meilleur pari. TGA 2.0 a un canal alpha et est relativement simple par rapport à PNG.

Le format de texture d'image est également un choix de performances. Je vous recommande d'utiliser autant que possible des textures compressées. Sur les plateformes mobiles, il peut améliorer considérablement les performances (40% voire plus), l'utilisation de la mémoire et le temps de chargement.

Considérons une texture 1024 * 1024:

• RGB ou RGBA (16 bits): 2 Mo (0,5 s à charger sur SGS)
• RGBA (32bits): 4Mo (1s à charger sur SGS)
• PVRT (4bpp): 512ko (.125s à charger sur SGS)
• ETC1 + Alpha: 1,5 Mo (0,4 s à charger sur SGS)

Dans nos jeux, nous avons des atouts (textures) dans de nombreux formats:

• Format DDS pour les textures DXTC (plates-formes de bureau: OS X, Linux, Windows et Tegra)
• Format DDS pour les textures ATC (GPU Andreno)
• Format PVR pour le format PVRT (GPU PowerVR)
• Format PKM pour la texture ETC1 (Tous les appareils OGLES 2.0 sont compatibles)

Enfin, nous utilisons le format brut pour la compatibilité, mais c'est pour la compatibilité ou les éléments GUI

• Format PNG pour la texture brute. C'est pour les textures RGBA 16, 24 ou 32 bits (nous utilisons un chargeur sous licence MIT). Ce sont des textures non compressées.

Les textures ETC1 n'ont pas de canal alpha, nous utilisons donc un shader spécial avec deux textures (texture rgb et texture alpha). Les formats compressés sont très faciles à charger (100 ou 200 loc).

Sur le bureau, DXTC (S3TC) est présent sur de nombreuses cartes. Donc, vous devez l'utiliser.

Textures compressées

Pro

• Taux de remplissage de texture amélioré
• Chargement de texture (4x ou plus)
• Facile à charger

Con

• Non pris en charge sur toutes les plateformes
• artefacts

Les textures sont des collections d'une ou plusieurs images. Cela signifie qu'une texture pourrait être représentée par un TGA ou PNG, mais aucun des deux formats n'est capable de représenter toutes les fonctionnalités possibles des textures. Pourquoi?

Parce que chacun ne peut contenir qu'une seule image. Il n'y a pas de mipmaps. Il n'y a pas de textures 3D possibles. Aucune texture de tableau. Pas de cubemaps. Chacun de ces fichiers n'est qu'une seule image 2D. Ils peuvent faire partie d'une texture, mais à moins que vous n'utilisiez pas de mipmapping (et je vous déconseille fortement de ne pas utiliser de mipmaps sauf si vous avez des besoins spécifiques), un seul fichier image dans ces formats ne peut pas être une texture.

Ce sont des formats d'image fins, mais ils font des formats de texture médiocres .

DDS est le leader des formats de texture car il prend en charge les choses dont les textures ont besoin. Il prend en charge les mipmaps et les cubemaps. Il prend en charge les textures 3D. DDSv10 prend en charge les textures de tableau. Vous pouvez empaqueter une seule texture dans un DDS d'une manière impossible avec PNG ou TGA.

DDS prend en charge les données de texture non compressées et compressées. Tant que le format de texture compressé est l'un des formats de texture DXT / BC.

PKM est utile pour empaqueter des images compressées ETC1, mais comme avec PNG, il ne prend pas en charge les fonctionnalités de texture réelles.

Les fichiers PVR semblent être l'équivalent mobile de DDS (bien que je ne sais pas pourquoi ils ne pouvaient pas simplement utiliser les DDS). Ils prennent en charge diverses techniques de compression, mais ils ne disposent pas de fonctionnalités DDSv10 avancées telles que les textures de tableau, ainsi que la prise en charge des textures 3D.

DDS gagne donc en termes de prise en charge complète des textures.

Le groupe Khronos recommande le format de fichier KTX pour le stockage des textures pour les applications OpenGL et OpenGL ES. Vous pouvez utiliser libktx pour travailler avec ce format.

Fonctionnalités:

• Instancier une texture OpenGL à partir d'un fichier KTX
• Décompressez une image de texture compressée ETC1 lorsque le matériel ne prend pas en charge ETC1.
• Construisez une table de hachage de paires clé-valeur à partir du fichier KTX pendant le chargement de la texture
• Écrivez un fichier KTX à partir d'un tableau d'images source et d'une table de hachage facultative de paires clé-valeur.
• Construisez et remplissez une table de hachage de paires clé-valeur.

Cela ressemble à DDS (DirectDraw Surface) soit le choix le plus populaire pour les textures en ce moment. Il a différents formats de pixels, transparence et compression. Il est pris en charge dans OpenGL via l'extension GL_ARB_texture_compression.

Par exemple, il y a un chargeur OpenGL ici .

Il y a un certain nombre de considérations ici:

1. À quelle vitesse vous pouvez obtenir la texture du disque et dans la mémoire système.
2. À quelle vitesse vous pouvez obtenir la texture de la mémoire système vers le GPU (via glTexImage2D dans votre cas).
3. Combien d'espace disque et de stockage vidéo RAM est dans votre budget.
4. Performance et qualité.

TGA est un bon choix car dans les cas 24 et 32 ​​bits non compressés, vous pouvez lire les données en une seule fois / quoi que ce soit et envoyer le résultat directement via glTexImage2D sans traitement supplémentaire. C'est un mauvais choix car il peut avoir la plus grande taille de fichier et si les E / S disque sont un goulot d'étranglement, alors vos lectures seront lentes.

PNG est un bon choix car il préserve la qualité des images avec une taille de fichier raisonnablement petite. C'est un mauvais choix car les fichiers PNG peuvent être lents à se décompresser - si c'est votre goulot d'étranglement alors - eh bien, vous savez.

JPG est un bon choix car il a généralement la plus petite taille de fichier et sortira du disque très rapidement (doublement bien si vous devez envoyer le fichier sur un réseau). C'est un mauvais choix en raison des étapes de décompression logicielles intermédiaires et de la perte de qualité (bien que vous puissiez régler les paramètres de qualité pour atténuer cela). Pas de canal alpha non plus.

Les DDS (ou autres formats compressés) sont de bons choix en raison de la plus petite taille de fichier et de la possibilité d'inclure une chaîne mipmap précompilée. Si c'est un format qui est nativement pris en charge par le matériel (et DDS est nativement pris en charge sur la plupart des matériels PC grand public - depuis longtemps aussi), vous obtenez le même avantage que TGA - une frayeur, un peu de piquer dans l'en-tête pour comprendre certaines propriétés de l'image, puis envoyez les données directement sans étapes intermédiaires. Les textures compressées rendront également votre programme plus rapide et utiliseront moins de RAM vidéo. Ce sont de mauvais choix car ils utilisent une compression avec perte (qui peut parfois être vraiment perceptible) et peuvent ne pas être pris en charge sur tout le matériel.

Si c'était moi, je développerais la prise en charge de ces 4 formats (TGA et DDS sont assez triviaux pour écrire des chargeurs, avec JPG et PNG j'utiliserais une bibliothèque d'images) afin que les créateurs de contenu puissent choisir le format le plus approprié sur une base par texture.

Et bien sûr, vous pouvez toujours utiliser l'ancien BMP 32 bits qui est vraiment facile à charger (surtout si la taille est une puissance de 2 (en fait, un multiple de 8 octets IIRC)).

Sinon, il semble étrange que vous ne vouliez qu'un seul format, jpg est vraiment cool pour de belles textures haute résolution du monde réel (jpeg fait des merveilles avec l'espace disque et les temps de chargement (bas)), png pour la transparence et le BMP occasionnel de 32 bits pour les textures de contrôle (facile à créer à partir d'un script ou d'un outil «rapide et sale»).