Cet article porte sur une demo ayant eu lieu a londres. L´auteur y rapporte la création d´une technique permettant d´avoir des textures beaucoup plus petite en taille sans avoir de perte de qualité.
Quelqu´un sait il comment cela marche ?

http://www.bit-tech.net/news/2006/10/04/Game_file_sizes_could_soon_be_70_smaller/

Tres intéressant. hélas, l´article ne rentre pas dans le détail technique, et le forum en lien est peuplé de gamers qui ne parlent pas de technique non plus...
Je suis curieux de voir comment ils font.
Je sais que pas mal de cartes graphiques permettent une compression RLE des textures, ce qui reduit la place en VRAM, mais bon, ça peut perdre en vitesse de rendu aussi...
Je me demande si cette technique garde les memes bench avec ou sans compression sur une meme carte graphique (normalement non, mais faudrait savoir le ratio de bench entre les deux)
Et il peut etre intéressant de savoir quelle compression est utilisée ? Forcément un truc rapide et qui se cable (donc pas la DCT du JPG déja...), difficilement du LZW aussi, du fait qu´il doive allouer de la mémoire pour dictionnaire de décompression...
Je ne vois qu´un RLE... Mais bon, faudrait voir...

Je suis intéressé par la technique !

En fait ca a l´air d´etre un genre de "format vectoriel".
Comme la plupart des textures sont généré par des procédures chargé dans photoshop( ou autre) puis exporter en BMP.
L´idée est de stocker sur le support que les procédure, et de faire faire le travail de décompression a la volée.

Si c´est vectoriel, c´est vrai que déja, ils ne perdent pas lorsque la résolution de la texture gonfle.
Cependant, je me demande comment ils font pour calculer un point i,j sur la texture pour le rasteriser.

Avec une image matricielle (bitmap), 2 divisions suffisent pour un i,j donné pour savoir sur quel pixel tu es.
Mais sur une image vectorielle, c´est la mouise pour savoir quel couleur afficher pour un i,j donné...
Imagine ne serais ce qu´un pintagone dessiné (5 segments) et colorié en vert, et a l´extérieur corlorié en jaune.
Pour un pixel i,j donné, comment - sans trop de calcul - tu sais si tu es sur un pixel jaune ou vert ? (sans sortir la grosse artillerie, car il faudra le faire des millions de fois par seconde)

Ou alors faut bosser en amont différemment, faut pas rasteriser en allant taper des coordonnées i,j de textures, ....

Il est nullement mentionné que les textures prennent moins de place en memoire, mais ca se passe plutot au niveau du stockage.

Le hardware des machines ne supporte que des formats de textures trés figés. Pas de bidouilles possible la dessus.

Par contre au niveau du stockage et de la generation, beaucoup de choses sont possible.

Apres relecture, l´article parle en fait de textures procedurales ou comment generer des textures a partir de 3 fois rien.
Ca existe depuis longtemps.
Pour ceux que ca interresse regarder le FPS "Kriegger" qui fait 96Ko (le jeu est complet), c´est l´extreme de ce qu´on peut faire en autogeneration (par contre le temps de generation au depart est assez long).

http://theprodukkt.com/kkrieger

Merci modérateur d´éclairer nos lanternes!

J´ai peur que ce style de technique ne soit pas très efficace dans les cas ou un artiste passerait beaucoup de temps a retoucher ses textures. Ce n´est pas ce qui est généralement fait dans les jeux ? (enfin, je dis ca mais je n´y connais rien)

Vivent les fractales

"J´ai peur que ce style de technique ne soit pas très efficace"

Ca marche bien pour certaines textures et pas d´autres.

Dans l´article ils citent "roboblitz" qui est un jeu futuriste dont les decors ressemble a Metroid. Ces textures sont assez geometriques donc peuvent etre creer avec des primitives, filtres et combinaisons d´effets.

"J´ai peur que ce style de technique ne soit pas très efficace dans les cas ou un artiste passerait beaucoup de temps a retoucher ses textures."

En effet, c´est pas des techniques adaptées pour les artistes, c´est surtout bien pour les programmeurs.