{"id":237,"date":"2009-08-03T16:26:03","date_gmt":"2009-08-03T15:26:03","guid":{"rendered":"http:\/\/www.ozone3d.net\/blogs\/lab\/?p=237"},"modified":"2011-09-07T20:54:05","modified_gmt":"2011-09-07T19:54:05","slug":"geexlab-bump-mapping-et-self-shadow","status":"publish","type":"post","link":"https:\/\/www.ozone3d.net\/blogs\/lab\/20090803\/geexlab-bump-mapping-et-self-shadow\/","title":{"rendered":"(GeeXLab) Bump Mapping et Self Shadow"},"content":{"rendered":"

<\/p>\n

\"GeeXLab
Bump mapping – front face<\/p>\n

<\/center>
\n
\nCa faisait une \u00e9ternit\u00e9 que j’avais lu un petit article sur la fa\u00e7on d’am\u00e9liorer le bump mapping et j’ai enfin pris le temps de le tester. C’est pas une technique r\u00e9volutionnaire, c’est juste une am\u00e9lioration de l’ombre propre (ou self shadow) d’un objet rendu avec du bump mapping. Avec un shader de bump mapping classique, l’ombre propre ressemble \u00e0 \u00e7a:
\n

<\/p>\n

\"GeeXLab
Bump mapping – back face<\/p>\n

\"GeeXLab
Bump mapping back face – d\u00e9tail de la surface – bugs dans l’ombre propre<\/p>\n

<\/center>
\nCertaines zones sont \u00e9clair\u00e9es alors qu’elles ne le devraient pas. Ce bug visuel est du \u00e0 la normal map qui, pour certaines zones de la surface de l’objet, poss\u00e8de des vecteurs normaux qui font face \u00e0 la lumi\u00e8re. La normal map repr\u00e9sente les micro d\u00e9tails de la surface (ou, encore mieux, contr\u00f4le l’ombre propre \u00e0 petite \u00e9chelle) et dans certains cas ces micro d\u00e9tails sont si accentu\u00e9s que le vecteur normal perturb\u00e9 (bump) qui repr\u00e9sente l’orientation donne un DOT(bump,L)>0 alors que globalement ces micro d\u00e9tails sont dans l’ombre de l’objet. La solution \u00e0 ce petit probl\u00e8me fait intervenir le vecteur normal non perturb\u00e9 qui repr\u00e9sente l’orientation globale de l’objet (ou permet de contr\u00f4ler l’ombre propre \u00e0 l’echelle de l’objet). En gros si DOT(N, L) est plus petit que 0 (N est vecteur normal non perturb\u00e9 – gl_Normal dans un shader de Phong) alors tous les calculs qui suivent se font dans l’ombre. Mais il y a une petite ruse qui permet de rapidement savoir si un pixel est dans l’ombre sans devoir utiliser gl_Normal. Comme nous sommes dans un shader de bump mapping, nous travaillons dans l’espace tangent ou TBN. Et dans cet espace au niveau d’un pixel shader, si la composante z du vecteur lumi\u00e8re (vLight) est plus petite que 0 alors nous sommes dans l’ombre propre globale de l’objet:<\/p>\n

<\/p>\n

\"GeeXLab
Bump mapping – back face – avec ombre propre correcte <\/p>\n

<\/center><\/p>\n

Je d\u00e9taillerai prochainement le code du shader avec un petite d\u00e9mo GeeXLab.<\/p>\n","protected":false},"excerpt":{"rendered":"

Bump mapping – front face<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9,408,8,469],"tags":[372,348,170,637,373],"class_list":["post-237","post","type-post","status-publish","format-standard","hentry","category-opengl","category-pixel-hacking-2","category-programming","category-tools-de-jegx","tag-bump-mapping","tag-geexlab","tag-normal-map","tag-programming","tag-self-shadow"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t