Sommaire:
Les maps mental ray

Comme vous le savez, la raison d'être d'une .map de mental ray est d'être lu directement depuis le disque, sans avoir à être chargé dans la mémoire. cette méthode permet d'une part de libérer de la mémoire et d'autre part, d'obtenir des images de taille quasi illimitée.

:sauteJoie:
Soucis de sampling

Seulement voila, si les map mental ray nous libèrent de la contrainte de la taille, utiliser de grosses maps pose un autre problème:

Dans le cas où vous voulez afficher une texture qui est en très haute résolution sur une petite surface (dans l'écran), vous vous retrouvez avec un grand nombre d'information possible par pixel et mental ray, suivant votre sampling, va devoir faire un choix. Si votre sampling est 0-2, et que votre texture est très contrasté et/ou granuleuse, il attendra sa valeur maximum ("2") soit 16 rayons lancés par pixel (ce qui est déjà énorme). Si la résolution de la texture est un peu trop élevé et contrasté, cela peut se révéler insuffisant.

Je pense que des images parlent d'elles même:

sampling_001.png

  • Les barres rouges sont les limites entre chaque pixel
  • Les points rouges sont les rayons lancé dans le pixel (samples)
  • Et derrière, un plan avec notre texture

Afin de bien illustrer mes propos, j'ai choisi d'afficher les pixel de la texture "sans filtre". Maya peut (et le fait par défaut) appliquer un filtre sur chacune des textures mais ça ne change pas grand chose sachant que la texture est en haute résolution, les variations de couleurs au sein même du pixel, restent importantes (on y reviendra, l'idée ici est de montrer ce qui ce passe :sourit: ).

Il est important de bien considérer l'échelle: Un carré = Un pixel. Donc, même si la résolution de ma texture est (volontairement) faible (environs 32*20), le nombre de couleur présent dans le pixel est important (environ 20*20 pixels) :zinzin: . Oui, je sais je ne l'explique pas très bien mais en gros, j'essaie de dire qu'il y a pleins de couleurs dans un notre seul pixel et que mental ray va "piocher" parmi ces valeurs.

Si on prend la valeur de chaque rayon, nous voyons que mental ray récupère ça:

sampling_002.png

C'est à partir de ses 16 couleurs et de votre filtre que mental ray va évaluer la couleur total du pixel. Dans le cas d'un filtre de type "box" à 1 pixel il calcul la moyenne des couleur de chaque pixel, indépendamment des pixels aux alentours.

Bon, je comprend qu'on ne puisse pas directement voir ou se situe le problème (ormis une image granuleuse mais sur une image fixe on s'en rend pas compte).

Là ou c'est vraiment problématique c'est dans le cas d'une animation, démonstration:

sampling_003.png

Ici, j'ai déplacé très (très) légèrement l'objet (rappeler vous de l'échelle: Nous regardons ce qui ce passe dans un seul pixel). Voici le résultat pour chaque sample:

sampling_004.png

Si nous comparons avec l'image précédente, nous voyons que, bien que nous ayons bougé le plan d'un chouilla, les valeurs récupéré sont assez différentes de l'image du dessus. Le pixel qui sera calculé ici sera donc teinté différemment de l'ancien.

Si on réfléchie au fait que le phénomène que l'on vient d'observer s'applique à chaque pixel de l'image (et pour chaque image de l'animation), vous l'aurez compris, ça "flick" ou "granule" dès qu'on bouge un peu... :gne2:

Des techniques de jeux vidéo

En jeux vidéo le problème est encore plus présent dans la mesure où, dans la plupart des cas, un pixel n'est calculé qu'une fois (oui je sais, depuis quelques années on peut sampler mais malgrès les avancés impressionnantes dans le sampling temps réel, ce procédé reste assez lourd et, de toute façon, est beaucoup moins précis qu'un sampling de précal).

Voici une image (méchamment prise de tom's hardware guide) qui je pense, montre bien le problème (ne regardez que l'image de gauche):

mipmapping-egz_1_.png

Chaque pixel renvoit la couleur exact qui est dans son axe. Maintenant regardez celle de droite et hop je rebondis vers ce sur quoi je voulais venir: Le mipmap! :hehe:

Le mipmaping

Le principe est le suivant: Puisqu'il y a trop d'informations dans un pixel, nous allons flouter la map (en fait on lui diminue ça taille) de façon à ce que, quel que soit la couleur que on décide d'afficher, elle sera "dans la moyenne" des pixels voisins.

C'est exactement le principe d'une réduction: Vous récupérer un certain nombre de pixel que vous groupez entre eux pour en obtenir un nouveau qui est la "moyenne" (suivant l'algorithme utilisé) de couleurs des pixels qu'il est sensé contenir.

Pour le cas d'une mipmap, une texture contient plusieurs textures, la siennes (taille normal) plus des version redimensionné (divisé par deux à chaque itérations).

Concrètement ça donne ça:

pic03_1_.jpg

Le tout empaqueté dans un seul fichier: le .map.

Dans notre cas:

sampling_005.png

La texture de base, haute def

sampling_006.png

Voila, vous avez ce que mental ray voit! Si on reprend le cas de tout à l'heure et qu'on lance 16 pixels sur la seconde map, même si on la bouge, on aura un résultat quasi identique.

Pas si extra ordinaire que ça...

Bon, ça vous le saviez si vous avez lu mes billets précédents sur les .map:

Mais il y a une chose que je n'ai pas abordé. :siffle:

Le choix

Maintenant, le problème c'est le choix. Mental ray connait la coordonné UV de l'information de couleur qu'il cherche à obtenir. Le problème est de savoir sur quel résolution (ou map) se caler pour récupérer le pixel... Le niveau 0 (taille max), 1, 2, 3? etc...

Laissez moi vous montrer une image et vous expliquer:

pic02_1_.jpg

Ici, nous voyons les différents niveaux, chacun affiché par une couleur différente:

  • Le niveau 0 est de couleur normal
  • Le niveau 1 est rouge
  • Le niveau 2 est vert
  • Le niveau 3 est bleu
  • etc...

Ceci permet d'avoir un retour "visuel" de quel niveau le moteur choisit d'utiliser.

Le filtrage est de type linéaire. Avec d'autres type de filtrage vous aurez un dégradé plus atténué (mais qui demande plus de calcul):

pic11_1_.jpg

Et Maya

Et bien c'est exactement comme ça que nous allons savoir comment Maya se comporte avec les .map que nous lui donnons. :hehe:

Nous allons utilisé une map spéciale (sorte de "map de debug") qui nous affichera plus ou moins ce que vous avez pu voir sur les images de jeux vidéo.

Mais je n'en dis pas plus pour l'instant! Vous verrez ça dans la seconde partie!

Je pense que déjà, avec ça dans la tête vous avez une bonne base sur le fonctionnement des mipmaps.

N'hésitez pas à réagir si vous avez des questions/suggestions ou si je suis resté un peu trop flou sur certains points.

A très bientôt!

Dorian

:marioCours:

Liens intéressants: