Salut meltingman !
Allez, on joue à "Une question, un pavé" !

Ici l'image pour la texture c'est du PNG, donc il y a pas de dégradation de l'image. Par contre, non, Unity ne va pas enregistrer de JPEG à la place, voilà l'explication (accroche-toi, ça va secouer !).

En fait, il faut voir que tout logiciel au monde, de Blender à Unity en passage par un navigateur web, va décompresser une image et l'envoyer au GPU pour l'affichage.
Ce qui signifie qu'au contraire de dégrader l'image en la compressant, le moteur graphique va plutôt la décompresser. C'est exactement comme quand on t'envoie un fichier ZIP et que tu veux voir son contenu : tu dois le décompresser et tu retrouves des fichiers que ton éditeur de texte pourra lire. La décompression n'occasionne aucune perte, c'est la compression qui peut dégrader (pour du JPEG par exemple).

Cela signifie donc qu'un programme n'a aucune raison de vouloir optimiser un format. Il faut voir qu'en fait, quand tu enregistres un PNG ou un JPG, ce que tu optimises c'est l'espace occupé par cette image sur ton disque, ou quand tu navigues pour la recevoir plus rapidement. Mais cette taille compressée n'est pas du tout, mais vraiment pas du tout, celle qu'elle occupe sur le GPU.

Je vais prendre l'exemple de l'image en JPEG du post #7.
Ce fichier lui-même fait 170ko. C'est très raisonnable pour une image de 1920x1040 pixels.
Le GPU par contre, lui ne sait pas lire du JPEG car c'est compressé. Comme toi avec le ZIP, tu as besoin de le dézipper pour voir son contenu. Donc il faut décompresser l'image avant de lui transmettre cette image. Or, pour calculer le poids d'une image décompressée c'est simple, c'est la taille totale de tous les pixels de l'image : largeur x hauteur x taille d'un pixel (désolé pour les maths !).

La taille d'un pixel dépendra du nombre de canaux (RGB, RGBA, noir et blanc...). Ça dépendra aussi du format des données mais on va dire que chaque canal utilise 8 bits (soit 1 octet). Une pixel RGB comme pour un JPEG
occupera donc 24 bits, soit 3 octets.
Ce qui nous donne pour mon exemple : 1920 x 1040 x 3 = 5 990 400 octets.
Donc sur le GPU, mon JPEG n'occupe plus que 170ko mais bel et bien près de 6Mo. Voilà pourquoi il faut optimiser la taille de ses textures pour économiser de la mémoire vidéo... et plus encore quand on bosse sur du PBR qui nécessite 3-4 textures minimum par matériau !

Si tu veux savoir combien de mémoire occupe une image, c'est très facile. Tu enregistres ton image au format BMP et tu as, à quelques octets près, sa taille en mémoire. Le BMP est un format sans compression.


Après il y a le mipmap qui est quelque chose d'autre mais qui n'a pas d'impact sur la qualité de la texture elle-même. C'est un procédé qui consiste à dupliquer, en mémoire, l'image tout en divisant progressivement sa taille par 2. Si on devait représenter comment est une une image avec les mipmaps dans la mémoire du GPU, ça donnerait ça :


Si tu connais le principe du LoD pour les meshs 3D éloignés, le mipmapping est l'équivalent en texture. Cependant, l'intérêt des mipmaps, c'est pas tant les performances (au contraire, ça consomme légèrement plus de mémoire) mais plutôt la qualité de l'image, bizarrement. Le but c'est de réduire la résolution de la texture au fur et à mesure qu'un objet 3D est loin de la caméra. Cela évite d'avoir des pixels qui "clignotent" au loin à cause de textures trop détaillées.
Voici une vidéo qui montre avec (gauche) et sans mipmap (droite) qui sera beaucoup plus claire pour comprendre :
https://youtu.be/D1TmyioQzhc?t=10

A noter qu'on utilise aussi des filtres trilinéaire ou anisotropiques, plus chers en calcul, pour améliorer le rendu car les mipmaps tendent à flouter un peu trop quand même.

Les mipmaps peuvent donc être activés ou désactivés selon la texture utilisée. Certaines textures peuvent par exemple être utilisées comme une donnée et non en tant qu'image. Dans ce cas, les mipmaps sont très gênants. On peut aussi, si on le souhaite, définir ses propres mipmaps au lieu de ceux générés automatiquement par le GPU.


_______________________________
* Les nombres que nous utilisons tous les jours sont exprimés en base 10 (sauf l'heure exprimée aussi en base 12). Bon je vais pas faire un cours de maths mais en gros, on a des chiffres de 0 à 9 et ensuite, on ajoute un 1 et on recolle un chiffre de 0 à 9 derrière. Ainsi de suite, on passe aux centaines, aux milliers, ... chaque fois en ajoutant un chiffre au début.



Les nombres sont codés dans un ordinateur en base binaire. C'est à dire qu'il ne connaît que 0 et 1, et pour représenter une valeur plus grande, il ajoute un 1 devant, ainsi de suite.


Ainsi 0 = 0 ; 1 = 1
Puis 10 = 2 ; 11 = 3
Et 100 = 4 ; 101 = 5 ; 110 = 6 ; 111 = 7
...

Là je vous ai parlé uniquement des nombres entiers. Ceux qui n'ont pas de virgule et les plus simples à convertir. Les CPU sont extrêmement rapides sur les calculs des nombres entiers.
Chaque 0 et 1 dans un nombre est un bit. Les ordinateurs groupent les bits par paquets de 8, ce qu'on appelle un octet. Les plus petites valeurs sont donc exprimées sur 8 bits sur les processeurs de PC modernes. Avec 8 bits, on peut compter jusqu'à 256 valeurs différentes (vous pouvez faire le test !). Si on utilise 2 octets (16 bits), on compte 65536 valeurs. On n'utilise pas de valeurs sur 3 octets car on n'utilise que des puissances de 2 (1, 2, 4, 8 16, 32, 64, ...), on passe donc directement à 4 octets. Ici, on dépasse les 4 milliards de valeurs différentes (vous pouvez ne pas tester !). Enfin, les fameux 64 bits, le maximum de ce qu'un processeur actuel peut gérer matériellement, et avec lesquels on peut compter jusqu'à 18.5 milliards de milliards de valeurs différentes. On peut aller au-delà en émulation logicielle mais ça sera peut performant en comparaison.

Il existe évidemment des nombres à virgule et je ne vais pas rentrer dans les détails. Eux aussi sont exprimés en valeur binaire mais ils sont codés de telle façon que notre cerveau n'est pas capable de les lire, à moins d'être un expert complètement fou pour se faire autant de mal !

Les GPU grand public sont essentiellement optimisés pour les calculs dits en virgule flottante 32 bits. Autrement dit, le nombre est codé sur 32 bits. En gros des nombres à virgule comme Pi, 2/3 ou 5,2.
Il y a aussi des calculs pouvant se faire sur des nombres 64 bits sur GPU, beaucoup plus précis, mais pour du loisir ça n'a pas d'importance. Le nombre d'opérations sur des nombres à virgule sont exprimées en FLOPS (Floating-point Operations per Second). Ensuite, on greffe un Giga si ça atteint le milliard d'opérations, etc.
Si on prend l'exemple de la RTX 3080, elle dépasse les 29 TFLOPS en 32 bits mais ne fait que 465 GFLOPS en 64 bits.

https://www.techpowerup.com/gpu-specs/geforce-rtx-3080.c3621

Ah je me rends compte qu'après modification de mon pavé en cours de route, le blabla sur les représentations de nombres n'a plus lieu d'être...

Bon je le laisse si ça intéresse des gens.

Oh ok oui j'ai confondu bipmap et mipmap on dirait .
Ok, donc la piste ne donne rien .
Merci pour le pavé :Lool: