Auteur
thellier
thellier
Forum » » Création-Développement » » Oui on peut faire du bump mapping avec Warp3D/Os4
Posté : 24-11-2012 21:14 
Désolé d'avoir été si incompréhensible: je réalise que ce que j'ai écris est assez décousu : mais j'étais tellement excité de voir ce truc de bump-mapping (enfin) marcher sur AmigaOS4 qu'il fallait absolument que je l'écrive
Bon on va prendre le truc à la base:
En 3D un objet est constitué de faces (généralement des triangles mais des faces quelconques ce serait pareil)
Ces faces sont orientées dans une direction appelée "Normale de face"
Qu'est ce une Normal de face ? : imaginez juste une fleche perpendiculaire à la surface de la face
Les normales de face servent à l'éclairage de l'objet
Regardez cet objet avec ces normales de face
http://flylib.com/books/4/423/1/html/2/images/08_125.jpg
si la lampe est à la place de l'observateur alors on comprends aisement que c'est les normales qui regardent vers nous (cad vers la lampe) qui seront eclairées
Ce raisonnement s'étend pour une lampe qui regarde dans dans une autre direction = seront éclairées les faces dans la direction de la lampe
Il s'ensuit que l'éclairage de base revient à dire si angle(direction lampe,direction normale) est faible alors éclairé sinon pas éclairé
Or justement le dotproduct(direction1,direction2) est une formule mathématique qui renvoie une valeur
qui varie avec cette angle
Donc un modele simple d'éclairage fera
pour chaque face
eclairage=dotproduct(Normal de face,direction de la lampe)
RGB[0]=faceRGB[0]*eclairage;
RGB[1]=faceRGB[1]*eclairage;
RGB[2]=faceRGB[2]*eclairage;
tracer face de cette couleur RGB
Voilà
Mais là les faces sont plates de couleur unie = c nul
Donc on va faire du gouraud et là il nous faut les vertex-normals (normale de sommet)
Regarder cette image il y a 4 normales de faces a b c d
http://www.mactech.com/articles/mactech/Vol.14/14.11/PoorMansBryce PartII/fig03.gif
On comprend aisement que N la vertex-normal (normale de sommet) est la moyenne des 4 normales de face a b c d qui sont autour = on calcule tout ça (ou on demande à Blender de le faire...)
On se retrouve donc avec autant de vertex-normals que de points donc 3 ou 4 par Face (triangle ou quad)
http://flylib.com/books/4/423/1/html/2/images/08_121.jpg
C mieux car avec ça on peut calculer plusieurs valeurs d'éclairage aux 4 coins de la face
Donc on peut calculer la valeur de couleur avec éclairage aux 4 coins
Un coin sera rouge, un autre rouge plus sombre, etc...
Que fait Gouraud ? il interpole juste entre ces valeurs de couleurs : genre si on a dix pixels à tracer qui passent de noir (codée 0) à rouge (codée 255) alors on aura un "pas" de 25 entre chaque pixel = c l'interpolation linéaire
Gouraud permet donc des dégradés uniforme de couleur sur une face
Et le bump mapping ?
L'idée c'est de plus rendre le dégradé uniforme pour simuler un mini relief de la face (rides,grains,fissures,etc..) au niveau du pixel
Admettons que l'on veille juste modifier un pixel au milieu de la face = un mini trou en somme.
Si ce pixel rouge est mis plus sombre on se dira c un trou et plus clair on se dira c une mini bosse
On peut imaginer (multitexturing) tracer une nouvelle texture avec ce(s) point(s) plus sombre plus clair par dessus notre face déjà tracée = ça marcherait = on appelle ça une lightmap et c'est juste une image en niveau de gris appliquée sur une face = on en a dans Blitzquake
Le probleme des lightmaps c'est quelle bougent pas : c'est pas grave pour une lampe fixe mais c un problème pour celles qui bougent : imaginez une voiture sur une route mouillée, le bitume sera d'un gris plus ou moins dégradé uniforme (gouraud) et on verra les aspérités(=bump) du bitume QUAND elle passsent dans la direction des phares
Bref on se dit la ligtmap c'est bien mais il faudrait que cela donne du blanc quand c'est dans la direction de la lampe et sinon en gris ou noir
Vous vous dites "mais c'est un dotproduct() au niveau du pixel !!!"
OUI
et justement le multitexturing de Warp3D OS4 cad la V5 sait faire ça = je sais c'est peu connu que Warp3D sache faire ce genre de truc (même Crisot l'ignorais la semaine dernière ;-P même Alain Thellier en doutais ;-P )
Là on se dit oui mais je connais pas "la normale de chaque pixel" ?
Comment les obtenir à partir d'une lightmap ?
Continuons avec notre example de dix pixels avec un mini trou (noir) au milieu
admettons que cette ligne de dix pixels de lightmap soit ainsi avec 1=blanc 0=noir
1111101111
qui represente ce relief avec un trou
---------_------
si on soustrait chaque point au suivant
0 0 0 0 0 -1 1000
on voit apparaitre la pente en x par pixel
On fait pareil pour toutes les lignes horizontales de la lightmap
de même on obtient les pentes en y avec les lignes verticales de la lightmap
Nous avons donc une pente en x et une pente en y par pixel donc on a presque la direction où regarde le pixel (= normale du pixel) on met juste la pente en z à 1.0 et ça y est on obtient une normale par pixel dans notre lightmap = cela devient donc une "normale map"
Bon là dans mon exemple je triche un peu
normalement je devrais lancer Warp3D pour qu'il fasse
un dotproduct(normale du pixel,direction de la lampe) au niveau du pixel et obtienne donc
une lightmap en temps réel
Petite triche1: Mais je connais pas la "direction de la lampe vu de chaque face" (*) alors j'utilise les vertex normale de la face que je connais
Petite triche2: Comme le multitexturing ne traite que des couleurs et des textures alors je prends comme
paramétres de mon W3D_COMBINE_DOT3RGB (= Warp3D qui fait le dotproduct(A,B) ) :
A une texure =la normale map
Bune couleur =la couleur des sommets (**) où je mets en fait mes vertex normales faute de savoir où les mettre
===> donne une lightmap
Après je fais une simple deuxieme passe de multitexturing avec la texture "peau de vache" modulée
par la lightmap précédente
Et voilà
Alain
(*) En fait il faudrait juste tourner toutes les vertex normale dans la direction de la lampe. Si on le fait pas c'est comme si on avait la lampe à la place de l'observateur.
(**) Mais là je perds le gouraud qui était stocké dans la couleur des sommets = à améliorer
Cet article provient de Le site des utilisateurs francophones actuels et futurs d'AmigaOS 4.x
https://amiga-ng.org/viewtopic.php?topic=1414&forum=14