DivideConcept.net

le blog de divide.

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

Dans cette dernière partie consacrée au displacement mapping, nous allons aborder les pistes de recherches actuelles.

Comme expliqué dans la partie 2, les pistes les plus prometteuses sont rendus possibles grâce au développement des vertex et pixel shaders : sans reellement créer de géometrie supplémentaire, mais en "creusant" des polygones simples grâce à des algorithmes, il est possible de recréer du displacement mapping (en évitant ainsi une surcharge mémoire et processeur).

Où il est question de précision et d’efficacité

Le principale problème du parallax mapping (outre l’effet "silhouette" qui sera abordé un peu plus bas) est son manque évident de précision. Pour obtenir un résultat plus réaliste il faut un algorithme qui soit capable de prendre en charge n’importe quelle displacement map sous n’importe quel angle, avec un minimum d’imprécision.

Ceci implique le développement d’algorithmes plus complexes, et donc forcément plus coûteux en terme de consommation mémoire et processeur que l’algorithme du parallax mapping.
Le grand problème est alors de trouver la méthode qui consommera le moins en calculant le mieux !

Sans rentrer dans le détail de toute les pistes de recherches actuelles, je donnerai comme exemple la méthode de Fabio Policarpo qui a l’avantage d’être simple à comprendre :

Il subdivise en 15 étapes le trajet entre l’entrée "dans" le polygone et le "fond" du polygone (relief minimum possible - concept déja abordé dans l’article 2).
Puis une fois qu’une intersection a été detectée, il resubdivise l’espace avant et après l’intersection en 5 étape, pour avoir une meilleur précision.
Il lui faut donc une vingtaine d’échantillonnages pour fournir un résultat acceptable.

Avantages : pas de précalcul nécessaire au niveau de la map de displacement, de meilleurs résultats que l’algorithme du parallax.

Inconvénients : nécessite beaucoup d’échantillonnage.
De plus, si il existe un pic de relief entre 2 échantillons, il ne sera pas détecté.

Cela peut donner lieu à des artefacts assez génant :

William Donnelly a réduit cet échantillonnage à 10 étapes grâce à un précalcul, et sa méthode est plus précise (elle ne rate aucun obstacle).
Inconvénient : La consommation mémoire pour chaque map de displacement est 16 fois supérieure !
Ceci est du à l’utilisation de textures 3d pour stocker des valeurs complémentaires, à la manière dont la technique du normal map détourne les composantes RVB pour coder des vecteurs (voir article 1).

Entre consommation processeur et consommation mémoire, il y a donc un délicat compromis à trouver.
Il est peu probable que l’année 2005 voit la standardisation d’un algorithme dans ce domaine, chaqu’un y allant de ses expérimentations.

Mais cela suffit-il à faire un displacement mapping correct ?
Et bien, non ! Il existe également un autre problème, couramment désigné comme effet "silhouette" (ou effet "de bord").

L’effet silhouette

Prenons l’exemple le plus simple possible, un triangle.
Le bon sens voudrait qu’on obtienne ceci :

Mais il n’en est rien ! En réalité, les algorithmes que nous venons de voir nous produiront cela :

Que s’est-il passé ?

L’algorithme, incapable de détecter les bords du volume de displacement réservé au triangle, a continué en considérant que l’espace intérieur est infini !

Il faut donc développer une méthode efficace de détection des bords.
Sans rentrer dans le détail des algorithmes, 3 techniques sont experimentés actuellements:
-extrapolation de la courbure équivalente générée par les triangles voisins (mais les résultats sont limités)
-décomposition du volume de displacement en tétraèdres et détection algébrique du bord de ces tétraèdres (mais grosse consommation processeur)
-détection des bords sans décomposition (méthodes en cours d’expérimentation)

Note personelle

J’arrive pour l’instant à des résultats assez satisfaisant avec mes propres algorithmes, puisque j’obtient des résultats similaires à ceux de William Donnelly sans augmenter la consommation mémoire !
Ma méthode de détection des bords (du 3em type) commence à se montrer également efficace.

Pour conclure, voici une liste de thread opengl.org en rapport avec le sujet :

Le thread à l’origine de la généralisation du Parallax mapping
L’algorithme de Fabio Policarpo (FPO)
Les résultats de la méthode d’extrapolation par courbure sur l’algorithme de FPO

Le displacement mapping est à la géométrie ce que la texture est à la couleur
Autrement dit, une bonne technique de displacement mapping permettra d’atteindre le niveau de géométrie ultime !

Cet article clôt la série sur le displacement mapping.
La prochaine fois, nous aborderons un autre aspect du développement 3d.

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

  1. Xfennec dit :

    Clair. Merci.
    T’es-t’il possible de nous en dire plus sur les méthodes que tu utilises ? (même en gros)
    PS: les deux derniers liens sont les mêmes.

  2. divide dit :

    Oups ! rectifié ;)

    En très gros, je fais un precalcul de la map de displacement, et pour chaque pixel je stock 3 valeurs supplémentaires qui me donnent des informations sur la map de displacement, et donc me permet d’avancer plus vite dans la détection d’éventuelles collisions entre les rayons venant de la caméra et le relief.. Comme toute les textures dans la mémoire de la carte 3d sont stockées sous la forme RVBA, je ne consomme rien de plus en assignant le relief à la couleur Rouge et en utilisant VBA pour stocker mes valeurs supplémentaires.
    mais je prefere ne pas en dire plus sur la nature de ces valeurs :)

  3. Ceacy dit :

    Félicitations, c’est clair, précis, et ‘chement impressionnant.
    Je crois que je vais t’élever un autel dans ma chambre.

  4. chaugnar-faugn dit :

    A toi les jeunes vierges sacrifiées. Tu peux remercier Ceacy.

  5. chaugnar-faugn dit :

    D’ailleurs, je plussoie avec force et moult conviction pour qu’une sélection d’article de blog soit présent en première page de NF.

  6. Cesco dit :

    un modder a reussi a ecrire (copier) un shader de diplacement mapping un vrai, dans le cryengine de far cry , il est apparement issue d’un shader pour le unreal3 lui aussi ecris en directx . Il n’attendrait que le futur sdk pour le compiler.
    se shader (dont je ne sais rien de plus que se qu’il y a marqué en dessous en anglais ) pourra t’il etre utiliser dans le cryengine ou sera t’il trop consomateur de ressources pour pouvoir etre veritablement exploité ? en quoi l’unreal3 serait t’il plus à même (moins consomateur de ressource) de supporter se shader que le cryengine ?

    ChainsawBunny say:
    "
    Using the directx sdk I have developed (ermmm copied from a disclosed source) and active displacement mapping shader (like unreal 3 virtual displacement, but better).

    But it needs compiling into the Facry engine using C++, which we are still waiting for! "

  7. divide dit :

    "un vrai" : faut relativiser.. ca m’etonnerait que le gars ai pu faire du vrai displacement mapping, si il s’est contenté de copier un algorithme "like unreal 3 virtual displacement, but better". En fait il a certainement copié l’algorithme de fpo qui est facilement compréhensible, mais qui n’est pas capable de faire du vrai displacement mapping (notamment à cause de l’effet silhouette évoqué dans l’article 3).
    Ni le cryengine ni l’unreal engine 3 ne traitent l’effet silhouette, donc ni l’un ni l’autre ne sont capables de reproduire du "vrai" displacement mapping.
    Mais je pourrai répondre mieux à tes questions si tu me donne la source de ce que tu cites, voire si tu as les coordonnées du gars.

    edit: source trouvée (thanks to google), je me renseigne.

  8. monster dit :

    tres interressant,surtout les exemples concret en image qui montre le genre d’artefact que peuvent créer les aproximations du parallax ou des autres algos plus complexe, n’hesite pas a mettre toujours + d’exemple en image, c’est ca qu’on aime je pense! (j’aimerais bien voir en mouvement et donc en video les artifacts causés par le parallax mapping car j’ai du mal a imaginer ce que ca donne vraiment en mouvement ce genre de deformation chaotique de la texture, je sais je suis trop gourmand)

    par contre j’ai une question au sujet du "vrai" displacement mapping, tu dis entre autre que ca consomme enormement de memoire alors que j’etais persuader que la subdivision et le diplacement pouvait se faire a la voler au fur et a mesure que sont balancé les polygones au rasterizer sans avoir a stocker le model subdivisé en memoire, car effectivement pour moi le displacement est avant tout une sorte de super algo de compression de la geometrie mais si il faut stocker en memoire les models subdivisés avant de les displacer alors ca n’a effectivement plus d’interet pour le temps reel, je pense plus particulierement au console de jeux dont la puissance augmente bien plus rapidement que la quantité de memoire qui est toujours tres limité en quantité et que donc la priorité dans la course a la complexité du rendu est plutot de trouver des solutions economique en quantité de data a stocker + qu’en puissance de traitement, le vrai displacement map n’a donc aucun avenir pour les jeux?

    et selon toi les algos de parallax ameliorer dont tu parle (ou celui que tu devellope) ne sont il pas trop gourmand pour etre vraiment exploitable dans des jeux de console next-generation par exemple? ne sera ton pas condamné au mieux a du simple parallax dans les jeux console next-gen? quelle est ton avis sur ce qu’on peut esperer voir en terme de displacement mapping dans les jeux console next-gen
    merci d’avance et continu comme ca

  9. LeGreg dit :

    Sur le bouquin GPU gems 2, il y a une méthode qui gère un peu mieux l’occlusion que le parallax
    et améliore la résolution de la solution de Policarpio:

    http://download.nvidia.com/developer/GPU_Gems_2/GPU_Gems2_ch08.pdf

    Elle a aussi été utilisé dans la démo Luna pour le launch de la 7800 gtx.

    Pour l’utilisation du parallax, dans les jeux c’est déjà utilisé (Splinter Cell, Far cry) et le sera encore plus
    parce que c’est vraiment pas cher et les artefacts ne sont pas si distrayants que ça si les artistes sont bien
    éduqués sur les limitations (mais ce n’est qu’une étape).

    LeGreg

  10. divide dit :

    Oui je connais cette méthode, j’ai parlé avec le canadien qui en est à l’origine; mais en fait cette méthode est inapplicable industriellement car elle consomme enormement de mémoire (j’en ai d’ailleurs parlé avec le lead programmer de Quantic Dream); on doit pas pouvoir utiliser plus de 5 ou 6 textures tellement les besoins memoires sont conséquents.

    Je suis également convaincu que le parallax sera La technique des moteurs 3d qui verront le jour en 2005/2006.. mais je programme pour 2007 ;)

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>