« 1 (2)


Re: Dulcis - Démo de RPG sur Unity
OverdOzed
Inscrit:
23/02/2006 18:10
De Alpes-Maritimes
Post(s): 2931
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): 2931
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): 11448
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
Hors Sujet !! les tutos de Moonboots    [1][2][3]...[11] 100 6996 Aujourd'hui 18:33:08
moonboots 
Hors Sujet !! Sappling gen generateur d'arbres - tuto blender 1 55 Hier 13:39:46
debutant 
Moteur de jeu GameBlender et alternatives [WIP] DeadSigns FPS horreur - Version alpha disponible + discord    [1][2][3]...[66] 658 133781 Hier 10:20:51
Hook 
Python & Plugins comment accroître la vitesse par appui continu d'une touche? 1 55 Hier 07:19:33
Redstar 
Questions & Réponses objet suivant chemin en prenant la courbure du chemin 2 82 15/05 21:41:12
neonclignote 
Questions & Réponses Plusieurs object qui avance sur une ligne trajectoire 8 199 15/05 19:22:32
moonboots 
Questions & Réponses Booléen et Nurbs sphere 0 39 15/05 15:26:50
blendinfos 
Questions & Réponses Le linking ne marche pas avec mon n personnage 3 102 15/05 09:28:55
Redstar 
Moteur de jeu GameBlender et alternatives Mes participations aux gamejam :    [1][2] 10 701 14/05 22:42:31
timeman13 
Questions & Réponses [résolu] Mirror ne fonctionne plus bien 8 185 14/05 18:08:35
GFC 
Moteur de jeu GameBlender et alternatives [non résolu] Cs (vaisseau)    [1][2][3]...[54] 534 158471 14/05 09:37:14
Redstar 
Questions & Réponses Occlusion ambiante dans 2.80 et plus avec eevee 2 234 12/05 06:40:35
xorturion 
Questions & Réponses [résolu] Transparence et Dynamic Paint pour un tag 5 733 10/05 10:51:42
CBY 
Questions & Réponses Text comme screen overlay 5 272 10/05 04:02:53
meltingman 
Questions & Réponses [non résolu] Exécuter un script à l'ouverture 0 87 09/05 21:45:09
Melodicpinpon 
Questions & Réponses Lancer un script par défaut/à l'ouverture 0 74 09/05 19:25:33
Melodicpinpon 
The Blender Clan 'tchat Benchmark EEVEE    [1][2][3]...[5] 41 9258 09/05 17:08:59
Keezty 
Questions & Réponses Garder la lumière allumée en local view, et dans toutes les collections 0 265 09/05 16:58:11
Melodicpinpon 
Python & Plugins ardoise 3D en add-on? 2 225 07/05 14:18:47
neonclignote 
Questions & Réponses [non résolu] Dynamic paint + particle 2 205 06/05 18:39:49
Jeanclaude25 

Qui est en ligne
104 utilisateur(s) en ligne (dont 61 sur Forums)

Membre(s): 0
Invité(s): 104


plus...
Nouveaux membres

Nemo
11/3/2021
qingjie 10/3/2021
Kask909 9/3/2021
marie-antoinette 7/3/2021
Bugs 7/3/2021
lolorogli75 4/3/2021
Flagiel 4/3/2021
thedeathclown 1/3/2021
Littlespoon 28/2/2021
luxperpetua 27/2/2021
Dernier Ajout
2020-09-24.jpg

Evènements à venir
Mai 18
Anniversaire Luneo
Jui 30
Anniv des Jedi :-D
Jui 10
BUG de Lyon
plus 256 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