« 1 (2)


Re: Dulcis - Démo de RPG sur Unity
OverdOzed
Inscrit:
23/02/2006 18:10
De Alpes-Maritimes
Post(s): 3084
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.

  0   1   2   3   4   5   6   7   8   9
 10  11  12  13  14  15  16  17  18  19
 20  21  22  23  24  25  26  27  28  29
...
100 101 102 103 104 105 106 107 108 109
...


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.
        0        1
       10       11
      100      101       110       111
     1000     1001      1010      1011     1111
...


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

Contribution le : 16/01 12:05:52
Créer un fichier PDF de la contribution Imprimer


Re: Dulcis - Démo de RPG sur Unity
OverdOzed
Inscrit:
23/02/2006 18:10
De Alpes-Maritimes
Post(s): 3084
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.

Contribution le : 16/01 12:12:24
Créer un fichier PDF de la contribution Imprimer


Re: Dulcis - Démo de RPG sur Unity
RegulatorZ
Inscrit:
01/07/2005 17:05
De Guyane francaise dans la jungeul
Post(s): 11551
Oh ok oui j'ai confondu bipmap et mipmap on dirait .
Ok, donc la piste ne donne rien .
Merci pour le pavé :Lool:


Contribution le : 16/01 12:51:47
_________________
Mon site : https://www.melting3d.org - Ma chaîne de tutos master
Créer un fichier PDF de la contribution Imprimer



 Haut   Précédent   Suivant
« 1 (2)




Enregistrer votre réponse
Compte*
Nom   Mot de passe   Authentification
Message:*



[Recherche avancée]



Sujets récemment répondus
Forums Sujets Réponses Lus Dernières contributions
Questions & Réponses Contraindre les valeurs de Shape Key d'un Lattice 2 40 Aujourd'hui 00:18:32
Horemheb 
[WIP] et travaux terminés Nature - Court-métrage    [1][2][3] 22 3895 Hier 22:10:14
Bibi09 
Questions & Réponses Raccourcis clavier qui ne marchent plus v 2.93.4 3 247 04/12 21:21:41
sapajou 
Graphisme alternatif Choix des couleurs 0 56 04/12 20:23:42
BlendSkill 
Le coin des geeks win10 - avoir visuel d'un fichier blend ? 3 83 04/12 18:32:22
Rimpotche 
Questions & Réponses Placer un objet par rapport à un autre objet 7 174 04/12 14:29:56
BlendProblem 
The Blender Clan 'tchat Blender 2.8x : Actus, tests, feedback..    [1][2][3]...[10] 97 53870 04/12 09:47:10
Bibi09 
The Blender Clan 'tchat le topic de l'impression 3D    [1][2][3]...[125] 1248 394457 04/12 09:01:12
Redstar 
Moteur de jeu GameBlender et alternatives [WIP] Godot Engine - Projet Arsenal    [1][2][3] 23 2525 03/12 17:18:28
Redstar 
Questions & Réponses [non résolu] Addon Mb-Lab 3 136 03/12 14:05:26
Guiu 
Questions & Réponses Récupérer la couleur en sortie de shader    [1][2] 12 438 03/12 10:51:49
Horemheb 
Questions & Réponses Sapling tree gen, comment le récupérer 0 73 02/12 20:30:18
Lylo 
Questions & Réponses [résolu] X-Ray uniquement en mode Solid 3 196 02/12 20:05:12
Horemheb 
The Blender Clan 'tchat Folle souris 3 175 02/12 12:43:22
Rimpotche 
Hors Sujet !! les tutos de Moonboots    [1][2][3]...[25] 241 25802 01/12 21:56:30
moonboots 
Questions & Réponses [résolu] Ngons 6 219 01/12 19:00:13
Rimpotche 
Questions & Réponses [WIP] animatique vers projet réél : comment concilier les fichiers ? 4 148304 30/11 21:38:43
doudoulolita 
Questions & Réponses debutant- engrenage en pointe    [1][2] 10 531 30/11 19:19:47
CBY 
Questions & Réponses [résolu] Fusion 360 - recherche d'un connaisseur 1 243 30/11 16:31:30
Redstar 
Questions & Réponses Solution rendu saccade    [1][2] 17 582 30/11 08:08:02
CBY 

Qui est en ligne
130 utilisateur(s) en ligne (dont 69 sur Forums)

Membre(s): 2
Invité(s): 128


MichalNobl, MaryanneRu, plus...
Nouveaux membres
Ashton07N6 5/12/2021
LesleyMart 5/12/2021
MilagrosSh 5/12/2021
DHBBurton5 5/12/2021
LatashaBra 5/12/2021
AdrianaSco 5/12/2021
ArdisHoar 5/12/2021
ChadSimpki 5/12/2021
LindsayMas 5/12/2021
ViolaClint 5/12/2021
Dernier Ajout
2020-09-24.jpg

Evènements à venir
Dec 29
Anniversaire d'ebrain
Jan 8
BUG de Lyon
Fev 15
Anniversaire de Dany
plus 246 plus d'élément(s)
 Par Mickaël Guédon [ebrain] © 2003-2021 The Blender Clan - hébergé par TuxFamily - Site déclaré à la CNIL sous le numéro 1155445