[algo] Gouraud et phong

Recherche :

Dernière réponse
Sujet : [algo] Gouraud et phong
rufo	ok, je crois que j'ai saisi l'essentiel, mais de toute manière, pour mon exposé, on se place dans le contexte d'objets en 3D situés dans un environnement 3D, donc la correction pour passer en 2D ne me concerne pas. Cela dit, j'en avais déjà entendu parlé de cette correction... Merci en tout cas pour toutes ces précisions :)

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

rufo

ok, je crois que j'ai saisi l'essentiel, mais de toute manière, pour mon exposé, on se place dans le contexte d'objets en 3D situés dans un environnement 3D, donc la correction pour passer en 2D ne me concerne pas. Cela dit, j'en avais déjà entendu parlé de cette correction... Merci en tout cas pour toutes ces précisions :)

bjone

par exemple le lien que tu as trouvé est graphiquement faux mais tolérable (les 3/4 des jeux/démos dos ont utilisés ça), le
http://perso.libertysurf.fr/chris.jav/gouraud.html

en effet il utilse une interpolation linéaire pour la couleur, alors qu'il devrait pour chaque sommet s1,s2,s3 de profondeur z1,z2,z3 avec leur grandeurs g1,g2,g3 (textures u,v coefs lumière diffu/spéculaire) , faire un truc du style:

Dans le triangle setup avant de le traçer ligne par ligne:
zg1=g1/z1
zg2=g2/z2
zg3=g3/z3

iz1=1/z1
iz2=1/z2
iz3=1/z3

puis dans le traçage ligne/ligne et pixel/ligne

interpoler gt,izt depuis zg1,zg2,zg3 et iz1,iz2,iz3

vrai_z=1/izt (utilisable pour le z-buffer)
vrai_g=gt * vrai_z

et là tu as dans vrai_g ta grandeur (coordonnée, coef de couleur) correct d'un point de vue perspective.

tes points en 2d sont issus par une division par la profondeur, tu peux faire une interpolation, mais par rapport à 1/z.

vu la lourdeur et lenteur du truc par rapport à une approche linéaire, tu apprendras que wolfenstein et doom, fesaient un traçage par lignes verticales pour les murs et par lignes horizontales pour le plafond et le sol, pourquoi ? passke graphiquement c'est correct de faire un traçage par ligne verticale pour un mur qui reste vertical (un ligne verticale de mur vertical a toujours le même z, ne necessitant pas alors la correcttion de perspective), symétriquement pareil pour le plafond et le sol.

c pour ça que wolf3d et doom ne te laissaient pas te pencher sur les cotés, heretic/dukenukem3d utilisaient pour lever/baisser la tête un translation en y des vertex lié à la profondeur z et l'angle (les arrêtes restent verticales), et dukenukem faisait une deuxième passe de traitement pour se pencher sur les cotés (rotation de l'image après rendu 3d).

quake 1 et le rendu soft de quake 2,font une correction de perspective tous les 8 ou 16 pixels, et font une interpolation linéaire entre chaque correction de perspective...

vala pour une explication j'espère claire (et correcte :??:) de la correction de perspective.

bjone

vi (enfin je penses), mais fo po oublier, que les vecteurs, fo les normalisers (j'entends si les normales aux vertex sont normalisés, le vecteur normal par pixel issu par interpolation des normales à chaque vertex, ne sera pas forcément normalisé).
pi attention si tu résonnes dans l'espace (en 3d, pour du raytracing), c'est bien une interpolation, si tu résonnes dans l'espace écran (2d), fo interpoler avec une correction de perspective (à savoir une fois en 2d, les grandeurs du triangles sont proportionnelles à 1/z).

[edtdd]--Message édité par bjone--[/edtdd]

rufo

bjone a écrit a écrit :

bin pour du gouraud qui utilise l'équation de phong par vertex, si t'as le gouraud en pseudo-code, tu rajoute le lumière spéculaire....
pis pour le vrai phong avec interpolation du vecteur normal et calcul de la lumière diffuse & spéculaire par pixel, tu mets les équation dans la boucle de ligne (vu que je sais pas ce qu'est ton pseudo code, mais je suppose qu'il traçe le polygone/triangle, ligne par ligne)

donc en rajoutant les équations de la lumière diffuse et spéculaire dans ta fct en pseudo-code qui trace une ligne, j'ai l'algo de phong (en prenant en compte le vecteur normal du pixel en court de traitement)?

rufo

DarkOli a écrit a écrit :

un vertex est un point.

merci :)

darkoli

rufo a écrit a écrit :

juste une dernière question : c'est quoi exactement des vertex? est ce que ce sont les vecteurs qui définissent les contours d'une facette ou les points des sommets d'une facette? merci

un vertex est un point.

LeGreg

bjone a écrit a écrit :

enfin apparement t'est plus avancé que moa (alors catmutt-roll ou je sais plus quoi ça avance bieng ?)

catmull-rom ? Catmull-clark? je vois pas de quoi tu veux parler..
En ce moment je fais un petit moteur de jeu
avec DirectX 8 pendant mon temps libre
pas de quoi casser des pattes a un canard.

A+
LEGREG

rufo	juste une dernière question : c'est quoi exactement des vertex? est ce que ce sont les vecteurs qui définissent les contours d'une facette ou les points des sommets d'une facette? merci

rufo

merci de ton aide :) bonne continuation

bjone

bin pour du gouraud qui utilise l'équation de phong par vertex, si t'as le gouraud en pseudo-code, tu rajoute le lumière spéculaire....
pis pour le vrai phong avec interpolation du vecteur normal et calcul de la lumière diffuse & spéculaire par pixel, tu mets les équation dans la boucle de ligne (vu que je sais pas ce qu'est ton pseudo code, mais je suppose qu'il traçe le polygone/triangle, ligne par ligne)

rufo

bjone a écrit a écrit :

enfin, il me semble legreg, sinon c'est ptet qu'on se plaçe pas dans le même contexte.... (donc dialogue de sourd :D)
enfin apparement t'est plus avancé que moa (alors catmutt-roll ou je sais plus quoi ça avance bieng ?)

au fait, est ce que par hasard, t'aurais l'équivalent pour phong en ce qui concerne la présentation de l'algo en pseudo-code? Merci. :)

rufo

bjone a écrit a écrit :

rufo >> tiens le phong en image:
http://www.comp.leeds.ac.uk/cuddle [...] html#phong

en fait le vecteur halfway sert à savoir rapidement si le phong est à effectuer, mais maintenant c'est plus rapide de le calculer directement (surtout si il est fait par vertex) que de tester avec le halfway je pense.

merci pour tes explications :) Le site pour voir le phong en action, je l'avais déjà trouvé...

bjone

enfin, il me semble legreg, sinon c'est ptet qu'on se plaçe pas dans le même contexte.... (donc dialogue de sourd :D)
enfin apparement t'est plus avancé que moa (alors catmutt-roll ou je sais plus quoi ça avance bieng ?)

bjone

rufo >> tiens le phong en image:
http://www.comp.leeds.ac.uk/cuddle [...] html#phong

en fait le vecteur halfway sert à savoir rapidement si le phong est à effectuer, mais maintenant c'est plus rapide de le calculer directement (surtout si il est fait par vertex) que de tester avec le halfway je pense.

[edtdd]--Message édité par bjone--[/edtdd]

LeGreg

oui peut-etre que mes infos ne sont plus a jour ;)

A+
LEGREG

bjone

oui mais, attends par passe, les cartes savent interpoler 8 grandeurs (au moins) avec correction de perspective je crois (coordoonées textures, coef diffuse & spéculaire)...
je parle que même sans aucunes textures, tes coefs de lumière diffuse & spéculaire, sont interpolés séparément...

LeGreg

bjone a écrit a écrit :

par contre, là ou je suis po d'accord, c'est pour la somme diffuse+spéculaire faite par défaut avec les cartes 3d à chaque.
quand tu fais des shaders en dx8 ou tu que tu mets tes stages, donc même sans approche par pixelshader, tu as clairement la possiblité de faire diffuse*texture+specular.

oui bien sur tu peux faire plusieurs passes, comme tu peux utiliser des textures pour faire de l'environment mapping,
mais pour Gouraud classique depuis les premiers temps d'Opengl
les interpolations se font en une seule fois. (si tu commences a faire plusieurs passes, rien ne t'interdit de faire du bump mapping simple aussi ou d'utiliser des lightmaps)

A+
LEGREG

bjone

hormis pour un moteur de terrain, on est d'accord :D

oups j'ai dis une connerie pour la lumière spéculaire je crois, avec le vecteur halfway :(

[edtdd]--Message édité par bjone--[/edtdd]

bjone

de toutes façon les 3/4 du temps, pour les jeux, les normales sont issues d'un soft comme 3dsmax.

bjone

je suis d'accord et po d'accord :D

oui, enfin je lui expliquais le principe, ça sert à rien de rentrer dans mon explication ;) je me suis quand même fait chier à lui faire une page d'explication pour qu'il comprenne.

pour les arrêtes vives/cube je suis d'accord, c'est pour ça que je parles d'angle limite. et j'ai bien précisé:

Citation :

bin le lien qui a été donné plus haut, c'est que quand tu n'a que les vertexs et les facettes utilisants les vertexs

on est d'accord ;)

quand je parles du gouraud, avec juste la lumire diffuse, c'est par rapport aux premier jeux/démos en gouraud à l'époque dos+486/pentium :D

par contre, là ou je suis po d'accord, c'est pour la somme diffuse+spéculaire faite par défaut avec les cartes 3d à chaque.
quand tu fais des shaders en dx8 ou tu que tu mets tes stages, donc même sans approche par pixelshader, tu as clairement la possiblité de faire diffuse*texture+specular.
ce qui veux bien dire que les coefs de lumière diffuse et spéculaire sont interpolés séparément par le rasterizer (c bo comme terme :D) de la carte 3d, et ce n'est donc pas la somme des deux qui est interpolée nuance.

[edtdd]--Message édité par bjone--[/edtdd]

LeGreg

Citation :

tu peux attribuer un vecteur normal "moyen" à chaque vertex (le vecteur normal de chaque vertex est la somme des vecteurs normaux des facettes utilisant le vertex, sous reserve qu'ils soyent dans un angle limite).

Ce n'est tout de meme pas la situation ideale
de calculer la normale moyenne (moyenne selon quels criteres en plus?). Meme si c'est souvent fait sur des modeles
low polys parce qu'on n'a pas de modele implicite des surfaces et qu'on a perdu les donnees de normales parce qu'on s'est ch.. dessus. (ou alors il faudrait rentrer les normales a la main).

L'ideal c'est quand le maillage est issu de la tesselation
d'une surface implicite (style une sphere, une surface de bezier, un nurbs, une subdivision surface) et ou les valeurs des normales peuvent etre calculees de maniere exacte.

Exemple: un cube, si tu appliques ta methode ton eclairage
sera foireux. OR sur un modele low poly, il y a souvent des aretes vives et il n'y a pas beaucoup de moyen de differencier une arete vive d'une arete issu de la tesselation d'une courbe.
Donc la seule solution c'est d'exporter les donnees de normales
depuis le modeleur qui est le seul a savoir comment le maillage a ete cree (s'il est bien fait).

Citation :

en gouraud-gouraud, tu as une équation appliquée par vertex, du style:
coef_lum=produit_scalaire(vecteur_normal_vertex,ve
cteur_lumiere->vertex)

C'est faux:
Le lissage de gouraud ne fixe aucunement la maniere dont
est calcule la valeur d'eclairement sur les vertices.
En opengl et DirectX, tu specifies
tes lumieres et tes materiaux avec le terme
de diffusion, le terme ambiant, et le terme speculaire.
Mais rien ne t'empeche de fournir ta fonction d'eclairement
perso (pour des effets anisotropiques par exemple).
Dans ce cas, tu te passes des fonctions de transform and lighting acceleres.
(ou tu utilises les fonctions de transform and lighting accelerees programmables also known as Vertex Shaders).

Citation :

faire l'addition diffuse+spéculaire au niveau du vertex et interpoler après la somme serait faux

Et bien les cartes 3D utilisent cette methode fausse en standard.
Tu calcules une valeur d'eclairement par vertex
et tu interpoles sur ton triangle.

Citation :

le phong-phong: plus supporté en hard dans les cartes 3d par magouille je pense:

Le phong en lui meme est deja une magouille:
simuler un eclairage de surface non plane sur une
surface plane (idem pour bump mapping qui est un deplacement
de normale par pixel)

quelques infos sur le perpixel lighting avec les nouveaux shaders:
http://developer.nvidia.com/view.a [...] l_lighting

A+
LEGREG

bjone

bin le lien qui a été donné plus haut, c'est que quand tu n'a que les vertexs et les facettes utilisants les vertexs. avec le produit vectoriel tu obtiens le vecteur normal de la facette, une fois que as tu as chaque vecteur normal de chaque facette, tu peux attribuer un vecteur normal "moyen" à chaque vertex (le vecteur normal de chaque vertex est la somme des vecteurs normaux des facettes utilisant le vertex, sous reserve qu'ils soyent dans un angle limite).

ça c'est la partie préparation, faite dans le modeleur par exemple.

dans la partie temps réel, vient le gouraud ou le phong (moins temps réel tout de suite), en gouraud tu fais ton calcul d'éclairage par vertex, via le vecteur normal au vertex, en phong, l'éclairage est fait par pixel, en interpolant le vecteur normal.

en fait il a souvent confusion entre le gouraud-phong et le phong-phong (je me comprends :D)

en gouraud-gouraud, tu as une équation appliquée par vertex, du style:
coef_lum=produit_scalaire(vecteur_normal_vertex,vecteur_lumiere->vertex)

et les coefs de chaque sommets sont interpolés le long du triangle.

en gouraud-phong , tu as l'équation diffuse+spéculaire, par vertex, du style: (si je dis pas de conneries)

diffuse=p_scalaire(vecteur_normal_vertex,vecteur_l

umiere->vertex)

spéculaire=p_scalaire(vecteur_vertex->camera, vecteur_lumière_réfléchi) à la puissance (n)

avec le vecteur_lumière_réfléchi qui est la le vecteur_lumiere->vertex qui est symétrique par rapport à la normale au vertex.
le n étant la puissance, jouant sur "l'étendue du reflet" (si n est petit l'angle de reflet spéculaire sera important, sinon ce sera très localisé)
la lumière spéculaire met en oeuvre le vecteur vertex->camera (ton oeil), car sinon le reflet n'est pas réaliste, quand tu regardes une vitre avec un reflet, ce qui fait que le reflet évolue c'est que ton oeil bouge, pas la source de lumière ou la vitre elle-même.

dans la pratique, par exemple avec les cartes 3d, lorsque tu as calculé (avec le T&L de la carte), le coef de lumière diffuse et le coef de lumière spéculaire, ces coefs sont ensuites interpolés le long du triangle, et on applique un truc du style:

couleur_à_écrire=couleur_texture*coef_lumière_diffuse+coef_lumière_spéculaire

sachant que le long de ton triangle, tu peux avoir des configs ou la lumière diffuse décroit et la lumière spéculaire croit (c'est pour ça que l'on interpole séparément lumière diffuse & spéculaire, faire l'addition diffuse+spéculaire au niveau du vertex et interpoler après la somme serait faux)

le phong-phong: plus supporté en hard dans les cartes 3d par magouille je pense:

tu prends l'équation pour l'éclairage du phong, mais là tu interpoles le vecteur normal le long du triangle, et ensuite tu calcules l'équation par pixel (au lieu de par vertex).

Ce qu'il faut retenir, c'est que le gouraud, l'éclairage est calculé par vertex, en phong l'éclairage est calculé par pixel.

La différence graphique est que par exemple, si tu prends un triangle équilatéral, tu plaçes la source de lumière au centre (de gravite), en peu plus "haut", l'approche par vertex (gouraud), te donnera d'un point de vue lumière diffuse les mêmes angles aux sommets, donc les mêmes intensités => le triangle sera de couleur unie (donc comme si c'est du flat shading), alors qu'en phong, le produit scalaire sera refait par pixel, et là tu auras un max d'intensité lumineuse au centre de gravité du triangle, en décroissant en allant vers les sommets, ça fera une auréole, ce qui est graphiquement correct.

[edtdd]--Message édité par bjone--[/edtdd]

rufo

bjone a écrit a écrit :

heu, ce que j'avais donné, c'est la préparation des normales de chaque vertex, qui seront utilisé pour le gouraud (ou le phong si tu interpoles le vecteur normal par pixel et que tu refais les produits scalaires).

ce que j'ai pas compris, c'est :
1) que vient faire le produit vectoriel là-dedans?
2) où calcules-tu les 3 composantes de la lumière (diffuse, spéculaire, etc.)?

merci :)

bjone

heu, ce que j'avais donné, c'est la préparation des normales de chaque vertex, qui seront utilisé pour le gouraud (ou le phong si tu interpoles le vecteur normal par pixel et que tu refais les produits scalaires).

rufo	voilà, j'ai trouvé l'algo de gouraud en pseudocode mais j'ai un doute sur sa validité. je l'ai mis temporairement sur mon site http://perso.libertysurf.fr/chris.jav/gouraud.html ps: le triagle (dont on parle dans l'algo a le sommet haut nommé A, le sommet bas gauche B et le sommet bas droit C)...

LeGreg

tu as besoin de quoi exactement?

N'importe quel Carte 3D fait du lissage
de gouraud par defaut. Donc pour les demos
tu regardes les jeux qui utilisent ton hardware 3D.

pour Phong:
Google + phong + demo

A+
LEGREG

rufo	si y'en a qui ont d'autres infos, genre où trouver des démos en 3D, etc, merci d'avance :)

rufo

legreg a écrit a écrit :

euh en plus j't'ai deja repondu
mais bon..

LEGREG

oui, mais tu m'avais conseillé de mettre monpost dans prgm. Donc, c'est ce que je fais...

LeGreg

euh en plus j't'ai deja repondu
mais bon..

LEGREG

Alload

Si tu veux des infos sur le gouraud shading, bjone a écrit l'algo dans ce topic:

http://forum.hardware.fr/forum2.ph [...] ic=&trash=

[edtdd]--Message édité par Alload--[/edtdd]

rufo	qq'un pourrait me filer l'algo de phong (et pourquoi pas Gouraud, même si j'ai trouver des infos dessus). Merci :)