DivideConcept.net

le blog de divide.

De l’apport du displacement mapping (2/3)

Dans l’article précédent les techniques les plus couramment utilisés pour simuler une complexité géométrique ont été abordés.
Nous allons maintenant voir le cas particulier du displacement mapping, qui reste à l’heure actuel un domaine encore hautement expérimental.

Tout d’abord, un exemple concret de ce qu’est censé générer géométriquement une map de displacement :

La première des approches pour arriver à ce résultat consiste tout simplement à subdiviser les polygones sur lesquels on souhaite appliquer la map de displacement en autant micro-polygones (termes employés fréquements dans les logiciels de 3d) que la map contient de texels (nombre de pixels sur une texture) et à déplacer ces micro-polygones pour épouser le relief virtuel définit par la map de displacement.
Cette approche a le mérite de la simplicité, mais elle a l’inconvénient majeur d’exploser la consommation mémoire et processeur.

Elle reste cependant la plus utilisée dans les logiciels de 3d tels que 3dsmax, maya, etc..
Ceux qui ont l’habitude d’utiliser ces logiciels et qui ont déjà expérimenté l’utilisation du displacement mapping savent de quoi je parle !

Bien que tentée dans une ancienne carte matrox (la g400), cette approche n’est pas viable pour le temps réel et à vrai dire, peu élégante.

Comment éviter cette surconsommation ?
En trouvant d’autres approches qui ne nécessitent pas de subdivisions de la géométrie.
Les cartes graphiques modernes mettent justement à notre disposition un outil formidable, les vertex et pixel shaders.

Mais késako ?

Si ces termes sont fréquemment employés, peu savent en revanche à quoi ils correspondent réellement.

Voici le schéma (simplifié et arbitraire) du pipeline graphique tel qu’il était dans les anciennes cartes graphiques (avant la geforce 3 -exception faite de la gf4mx- et avant la radeon 9500) :

Les vertex et pixel shaders se sont intercallés sur la carte graphique dans le processus entre la réception des polygones et le rendu final.

Oui mais c’est quoi ?

Les vertex et pixel shaders offrent la possibilité au développeur d’inserer des programmes plus ou moins complexes sur la carte graphique qui modifient le traitement des polygones qu’elle reçoit et de leur rendu !

Les vertex shaders recoivent en entrée comme leur nom l’indique un sommet (3 sommets définissant une face) et eventuellement quelques attributs propres à ce sommet, leur font subir un traitement définit par le développeur, et redonnent en sortie un sommet (avec le même nombre d’attribut).
Ils servent généralement a établir les calculs préliminaires pour les pixels shaders.

Les pixel shaders recoivent le résultat de la rasterization (interpolation pixel par pixel effectuée par le gpu entre les 3 sommets composant une face), c’est à dire un pixel en entrée, avec des attributs qui dépendent des attributs donnés en sortie par le vertex shader (coordonnées de textures, couleur, vecteurs divers..).
Ils fournissent en sortie, selon le programme définit par le développeur et tenant compte de tout les attributs donnés en entrée, une couleur (RVBA) en sortie et éventuellement une profondeur (si celle-ci est différente de celle calculée automatiquement par interpolation).

Devant la puissance de calcul parallèle et la rapidité de plus en plus croissante des processeurs graphiques, l’avantage ne se discute plus !

Après cette parenthèse, retour au displacement mapping.

La première des approches exploitant la puissance du GPU pour simuler du displacement mapping est le maintenant bien connu Parallax mapping aka Offset bump mapping aka Virtual displacement mapping.
Cette technique est utilisée dans l’Unreal Engine 3 et le futur Morrowind (Elder Scroll IV).
Mais attention ! Il ne s’agit que d’une simulation qui n’a rien de correct mathématiquement.

Voici comment elle fonctionne :

On considère un polygone dans lequel on va "creuser" le relief définit par la map de displacement.
Cette approche est commune à toute les nouvelles technique expérimentale per-pixel visant à reproduire du displacement mapping.

La particularité de chaque algorithme est la méthode de recherche de la première intersection entre chaque rayon émanent de la caméra et le relief définit virtuellement.
L’algorithme utilisé par le parallax mapping est assez simpliste : il fait l’assomption qu’en allant jusqu’au bout du parcours du rayon (donc en touchant le fond du volume global définit par la map de displacement) il obtiendra une valeur de hauteur qu’il peut generaliser pour l’ensemble de la zone dans laquelle il se trouve.
Le schéma suivant illustre plus clairement ceci :

Avantage : un calcul rapide à effectuer, un résultat qui donne l’illusion de relief.

Inconvénient : beaucoup trop approximatif ! Si la map de displacement définit des variations de relief trop marqués, ou si la caméra fait un angle trop aigu avec le polygone, le calcul devient complétement faux et l’illusion disparait (en générant un magma informe).

De plus, cet algorithme ne prend pas en compte les effets de bord (nous y reviendront en détail dans le prochain article).
Cette méthode a cependant le mérite de pouvoir fonctionner sur des cartes ne permettant pas l’exécution de pixels shaders complexes, en offrant un rapport illusion/consommation intéressant.

Dans le prochain article nous aborderons le futur du displacement mapping : les pistes de recherche et les résultats obtenus.

16 commentaires pour “De l’apport du displacement mapping (2/3)”

  1. knolan dit :

    Tiens, Un Blog interressant, et ou la personne ne raconte pas ses histoires d’amour ratées de jeunesse … Bizarre, bizarre …
    Je ne comprend pas tout (en particulier les histoire de vertex et pixel shading) mais je crois me rapprocher (un otut petit peu) de Dieu. Etant Game Designer pour une grosse boite, et complètement nul en technique, je suis assez satisfait de ma lecture ….

  2. Aquineas dit :

    Claire net et concis. J’aime beaucoup, continue comme ça , ça me fera une p’tite lecture quotidienne ;)

  3. Napalm dit :

    J’attends également la suite, merci !
    C’est marrant de voir qu’on en est à la 3eme génération de cartes videos qui "gèrent" direct X9, et qu’elles n’ont pas encore la puissance necessaire pour toutes ses fonctions.

  4. crocopower dit :

    Vraiment très intéressant, on a hate de voir des exemples dans nos jeux de tous les jours. Je dis peut etre une connerie, mais si ces fonctions ne sont pas encore exploitées, c’est la faute au manque de mémoire dans nos cartes graphiques, car elles demandent un nombre de texture supplémentaire conséquent.

    Sinon, la version définitive de ces articles sera publiée dans NoFrag ?

  5. divide dit :

    @Napalm : Oui en fait on est juste au tout début de la programmabilité des cartes 3d, les années qui viennent promettent énormément !

    @crocopower : Oui et non. Mais ca sera détaillé dans le prochain article ;o)

    Concernant la publication sur NoFrag, je n’y vois pas d’inconvénient, ca dépend juste des admins;
    d’autant que je compte faire plusieurs séries d’articles sur les techniques du jeu video.

  6. Kara dit :

    C’est très intéressant, très compliqué et très surprenant (au vu des autres blogs), et même si je n’ai pas tout compris je te remercie de m’avoir transmis un peu de ta culture. Maintenant je pourrais faire le fier en reconnaissant un parallax mapping (de près et en biais mais c’est déjà ça)

  7. Aquineas dit :

    Ya t’il plusieur méthodes pour le parallax mapping? Car les travaux qu’on peut voir sur certains sites ne donnent pas de résultats aussi dégueux que sur ton test de parallax? ou bien ces sites mettent ils leur travaux sous un angle avantageux?

  8. divide dit :

    Il n’existe qu’une seule méthode pour le parallax mapping, et c’est ce qui fait son nom. Plusieurs manières d’y arriver, mais toujours selon le même principe.
    L’image de comparaison parallax mapping/calcul exact est tout à fait représentative : j’ai utilisé un algorithme de parallax, sans aucune altération, et testé avec une map plus générale qu’un simple motif de brique (qui est l’exemple le plus courant pour démontrer les effets du parallax mapping) : et bien comme on peut le voir, le résultat est tout à fait dégueulasse.
    On peut donc en conclure qu’au dela de motifs simples (dont l’exactitude géométrique est difficilement criticable) le parallax mapping ne peut guère produire de résultats probants.

  9. Aquineas dit :

    Mais oki kwa \o/

  10. dpjtmille dit :

    Je me joins aux nombreux admirateurs pour t’encourager à continuer.
    Je suis aussi avide d’exemples pas à pas: partant d’un modele, comment on passe à un modele "low poly", comment on fait une map, comment on fait le rendu de l’ensemble, etc..
    Lache toi et raconte nous :))

  11. Cesco dit :

    Moi aussi je bois tes paroles , continue comme sa .

    j’attend avec impatiente que tu nous parles de ton algorythme pemrettant un displacement sans subdivision de poly , mais je croit me souvenir que tu voulais pas trop en parler pour pas te faire piquer cette idée…

    quel est l’interet du displacement si le model n’est plus un low poly mais un high poly ( subdivision) (dans des rendu temps réel comme les jeux) ? Les faces non deformée peuvent t’elle se regrouper pour alleger le nombres de face ?

    ton explication du normal mapping est clair et j’ai enfin compris se que c’etait comme quoi un shema vaux mieu qu’un grand discours … je comprend maintenant comment marche le tools melody de nvidia , mais je comprend moins comment marche le normal map filter de nvidia , un plugin qui permet de creer une normal map a partir de n’importe quel texture . A quoi correspond ses normals si il n’y a pas de "model high poly" pour connaitre quel relief ajouter?

    Sinon si tu pouvait contacter konami , ton displacement permettrait d’avoir enfin des supporters en 3d et non plus les sempiternel sprites tous moches qui levent les bras .

  12. divide dit :

    Merci à tous, ça m’encourage à continuer ;)

    @Cesco : Je ne parlerai pas de mon algorithme, mais je donne quelques exemples de recherches actuelles dans le dernier article pour donner une idée de la démarche.

    L’interet du displacement mapping avec des techniques "per-pixels" c’est à dire calculé par pixel shader, c’est que tu n’envois toujours qu’un modèle low poly à la carte 3d ! Et grace à la map de displacement qu’elle a deja en memoire et l’algorithme contenu dans le pixel shader, elle est capable de reconstituer l’aspect d’un modèle high poly, mais en beaucoup moins de calcul et en utilisant beaucoup moins de mémoire !

    Dans les méthodes de subdivision en micro polygones (donc sans utilisation de pixel shader, première partie de l’article 2) il y a souvent des tentatives pour alleger la subdivision en regroupant les faces non déformées.. mais ca reste toujours beaucoup moins élégant/rapide/efficace qu’un algorithme per-pixel.

    Pour le normal map filter, si tu fait reference à cet article la :
    http://66.70.170.53/Ryan/nrmphoto/nrmphoto.html
    Alors prend en compte le fait qu’il ne s’agit pas d’une seule texture à la base, mais d’un vrai modèle 3D qui a été éclairé selon 4 axes différent, les 4 textures sont donc révélatrices d’un relief 3d lorsqu’on recoupent leurs informations.
    En plus c’est quasiment juste mathématiquement, mais ça necessiterai un article complet pour expliquer comment. Peut être plus tard ;)

    Et ouai à mort les sprites ! \o/

  13. Cesco dit :

    En fait je parlais d’une simple textures rvb( de mur de brique par exmple) que l’on faisait passer dans le normal map filter avec l’option average RGB cocher (au lieu de normalyze only dans l’article ), he bien le resultat sur certaines textures est presque le mèmes que les normals maps utiliser par exemple dans hl2 . j’ai creer avec se plugin la meme textures qu’utiliser ( et donc creer pour le jeu) ils n’ont donc apparement pas utiliser de model high poly de mur en brique pour simuler les creux , mais on seuelemnt passer la textures par se filtre .
    Ma question etait donc Qu’a fait le filtre pour donner cette impression de creux entre les briques a une textures parfaitement plate ( comme toutes les textures) dont les seul information etait que les creux etait plus clair que les brique qui elles sont rouges.Qu’elle est l’ interet a creer des normal map a partir de textures rvb de diffusion , pourquoi le rendu est amelioré quand on utilise ses map alors qu’elle ne sont tirer que de la textures de diffusion d’origine (question con puisque les textures speculaire et de bump peuvent aussi etre issue de la textures de diffusion et le rendu est effectivement ameliorer mais dans ses deux cas je comprend pourquoi.)

  14. divide dit :

    héhé c’est la qu’on voit que la notion d’ "améliorée" est toute relative.
    En fait, dans ce cas la, c’est autant amélioré que du reverb sur une voix : ça parait plus beau, mais aucune information extérieure n’est apportée.
    Je ne sais pas trop comment nvidia procede avec son logiciel, ne l’ayant jamais testé, mais je supposent qu’ils se basent sur les contrastes au sein de la texture (fort contraste entre 2 pixels: différence de niveau - teinte homogene : meme niveau) et de ces différences de niveaux il déduisent des pentes (donc des vecteurs) qu’ils codent finalement sous forme d’une normal map.
    Donc pas besoin de "reconstruire" un modele 3d dans sa globalité, en se basant uniquement sur les differences lumineuse ont peut imaginer des pentes. Je dis "imaginer" car rien ne prouve mathématiquement qu’il y a corrélation entre le relief déduit et le relief que l’homme interprète.

  15. M0rb dit :

    Mathématiquement l’artiste (l’homme qui interprète le relief là) ne vaut rien, mais théoriquement savoir dessiner c’est transmettre directement de l’oeuil à la main. A mes amis ingénieur j’explique ça en terme de signal. Le signal lumineux passe de l’oeuil à la main : un dessinateur c’est comme un ampli, le meilleur est celui qui altère le moins le signal.

    Tout ça pour dire : dessiner une map de cailloux, c’est en dessiner la lumière. Ca se fait donc en fonction de deux choses : la surface et la lumière.
    Si je dessine une surface ‘A’ avec une lumière ‘L’ de direction ‘D’ et que je dis à mon ordi : voilà ‘L’ et voilà ‘D’. Il devrait effectivement pouvoir me trouver ‘A’.

    Pour l’algorythme qui fait le boulot, je vous laisse faire le plus marrant !

  16. Sot_Viet dit :

    Impressionant.

Laisser un commentaire

Si vous avez un compte sur WeFrag, connectez-vous pour publier un commentaire.

Vous pouvez, entre autres, utiliser les tags XHTML suivant :
<a href="" title="">...</a>,<b>...</b>,<blockquote cite="">...</blockquote>,<code>...</code>,<i>...</i>