Meilleur format d'image pour les textures non compressées?

Question

Je suis en train de sélectionner un format d'image qui sera utilisé comme format de stockage pour toutes les textures internes. Le format sera utilisé comme format source à partir duquel les textures compressées pour différentes plateformes et configurations seront générées, et doit donc couvrir tous les types de texture possibles (2D, cube, volymétrique, nombre variable de mip-maps, pixels flottants) , etc.) et être complètement sans perte. En outre, le format doit pouvoir conserver un peu de métadonnées.

Actuellement, un format personnalisé est utilisé pour cela, mais un format communément disponible sera plus facile à utiliser pour les artistes depuis son affichage dans la plupart des éditeurs d'image.

J'ai pensé à utiliser DDS, mais ce format ne prend pas en charge les métadonnées autant que je peux le voir.

Toutes les suggestions ont été appréciées!

Answer 1

Avec vos besoins, vous devez rester avec votre selfmade format. Je ne connais pas de format d'image autre que DDS qui supporte les textures volumétriques et cubiques. Malheureusement, DDS ne supporte pas les méta-données.

La chose la plus proche que vous pouvez trouver est TIFF. Il ne supporte pas directement les cubes-maps ou les textures volumétriques, mais il supporte n'importe quel nombre de sous-images. De cette façon, vous pouvez réutiliser les sous-images comme des tranches ou des cubes.

TIFF a également un très bon support pour les métadonnées personnalisées. La librairie de lecture/écriture d'images libtiff fonctionne plutôt bien. Il semble un peu archaïque si vous venez d'un côté OO, mais il fait son travail.

Nils

Answer 2

Avez-vous essayé le format PNG? http://java.sun.com/javase/6/docs/api/javax/imageio/metadata/doc-files/png_metadata.html

Answer 3

Lorsque jeter un oeil à l'intérieur des ressources de divers jeux j'ai découvert que la plupart d'entre eux textures magasin (je ne sais pas s'ils sont compressés ou non) dans TGA

Answer 4

TIFF serait probablement votre pari le plus proche pour un format qui prend en charge les méta-données arbitraires et plusieurs cadres, mais je pense que vous êtes mieux garder les actifs (dans ce cas, les images) séparer de la façon dont ils sont convertis et utilisés dans votre moteur. Conserver les images au format PNG 32 bits et mettre les informations de type et méta en XML. Cela permet à vos données de rester visibles, lisibles et modifiables. Les formats personnalisés obscurs sont pour les moteurs, pas pour les personnes.

Answer 5

Stick avec tout ce que vos artistes travaillent avec.

• Si vous êtes windows/mac et en utilisant photoshop bâton avec .psd
• Si vous êtes un magasin unix et utilisez gimp bâton avec .XCF

Ces formats stockera couches et tout ce dont vos artistes ont besoin et sont habitués. Étant donné que vos artistes créeront des tas de ressources pour leur faciliter la vie, même si cela signifie écrire du code supplémentaire.

Placez les métadonnées (quel qu'elles soient) quelque part "le long" des images si le format natif (psd/xcf) ne le supporte pas.Pour les choses comme les cartes de cubes, les mipmaps (si elles ne sont pas générées par le convertisseur) s'en tiennent à des guides de dénomination ou à des directives sur la façon de les mettre dans un seul fichier.

Selon l'outil que vous utilisez pour créer la substance volumétrique, il suffit de coller avec ce format natif outils.

Tout en écrivant des formats personnalisés pour la cible est généralement une bonne idée, écrire des formats personnalisés pour les artistes résultats dans Mayhem ...

Answer 6

Mon expérience avec DDS est qu'il est un format mal documenté et difficile à travailler avec et offre quelques avantages. Il est généralement plus simple de stocker un fichier maître pour chaque classe d'image qui contient des références aux images source qui le composent (6 faces pour une carte de cube, un nombre arbitraire de tranches pour une texture de volume) ainsi que tout autre méta-données. Ce sera toujours une bonne idée de garder les méta-données dans un fichier séparé (ou dans une base de données) car vous ne voulez pas charger un grand nombre d'images lorsque vous effectuez des recherches, peupler des navigateurs, etc. pour séparer votre format d'image source (tiff, tga, jpeg, dds ...) de votre "méta-format" (cube, volume ...) car vous pourriez bien trouver que vous avez besoin d'utiliser la compression avec perte pour supporter les formats HDR ou très grandes données de volume source.

Answer 7

Comme une solution alternative, peut-être passer du temps à écrire un plugin pour un Free Image Editor pour votre format de fichier? Je ne l'ai jamais fait auparavant, donc je ne connais pas le travail, mais il y a beaucoup de code exemple pour vous.