newbie en détresse (diffuse light)

Version imprimable

bonjour,

tout d'abord pardon de pas être plus précis dans l'intitule je ne sait même pas si ca viens d'un shader ou même de l'architecture de mon code... alors dans le doute je vous met le tout a disposition :

svn checkout http://black-death-revenger-raytrace...com/svn/trunk/ black-death-revenger-raytracer-read-only (linux + sfml 1.6, makefile inclu...)

(j'etait pas tres inspirer pour le nom :mrgreen:)

mes symptomes :
dans Fdefuse.glsl (le fragment shader)
les lignes
Code:

1 2 final_color = gl_LightSource[0].diffuse * cosNL; gl_FragColor = final_color;
m'affiche tout bonnement du noir... mais chose intéressante quand j'essaye ceci :
Code:

1 2 3 4 5 6 7 8 if (cosNL == 0.0) gl_FragColor = vec4(1,0,0,0); else if (cosNL < 0.0) gl_FragColor = vec4(0,1,0,0); else if (cosNL > 0.0) gl_FragColor = vec4(0,0,1,0); else gl_FragColor = vec4(1,1,1,0);
sur mon laptop (nvidia nvs 5100m) mon triangle est blanc (oui oui ... il rentre dans ce else qui n'a même pas lieu d'exister...8O) et sur mon desktop (ati 6870) il est rouge ...

donc voila je suis un peut démuni devant ceci... je présume que la normal ou la position de la light arrive mal (sinon le produit vectoriel serait bon) mai pourquoi ?

ps : je sait que gl_LightSource[0].diffuse * cosNL; ne me donnera pas une couleur comme on en attendrait d'une light... je cherche seulement a chopper le "dégrader" et a comprendre openGL avant de m'attaquer aux math.

et dernier truc: mon clavier est qwerty le peut d'accent qu'il y a c'est le correcteur orthographique qui me les prêtes :calim2:

15/07/2012, 17h21
LastSpear

Les conditions, sont à éviter en GLSL que je sache. :? Comme il y a un grand nombre d'unité de calcul sur une carte graphique, on se doute qu'elles ne peuvent être aussi complete qu'un CPU. Donc ces unités sont conçu pour faire des calculs 3D, donc disposent avant tout d'instructions vraiment spécialisées dans le calcul en float. Ainsi d'autre types d'instructions peuvent être mal optimisées (partagée entre plusieurs unités par éxemple), ou voir même absente. :aie: Seul les GPU récents qui sont aussi conçu pour faire du computing avec OpenCL par exemple dispose de plus d'instructions, donc plus amiable de faire des conditions. Mais ces instructions rajouté peuvent être moins bien optimisé. :calim2:

Tout comme, les boucles for en GLSL doivent être utilisées avec un nombre d'itérations constant à la compilation, sinon elles utilisent aussi les conditions. :zoubi:

De plus les shaders sans conditions, dit aussi linéaire, sont plus rapide car leurs temps d'exécution est identique quelque soit le vertex/pixel, donc le driver peut prévoir à quel moment sont travail sera fini et ainsi préparer sa tache suivant en parallèle. :ccool: Donc pour les calculs de lumière il faut préférer les fonctions GLSL min, max et clamp qui elles utilisent des instructions plus optimisées, et surtout assure la linéarité du temps d'exécution du shader.

Par ailleurs, je vois que tu utilises l'ancien système de lumière d'OpenGL, donc il faut faire attention à certaines choses ... :aie: De souvenir, il faut que LIGHTING et LIGHT0 soient activé avec glEnable (ou un truc du genre). :lol:
Mais pour ce débarrasser de ce genre de problème hold school, il est préférable d'utiliser soit même les uniforms pour les lumières, et même pour tout le reste. C'est en partit pour cette raison que ce système a été retiré dans les versions d'OpenGL plus moderne. Les développeurs dispose d'une plus grande liberté dans la programmation de leurs système d'éclairage avec les uniforms. :ccool:

En espérant avoir répondu.

PS: penses à la balise code http://www.developpez.net/forums/images/editor/code.gif pour que celui ci soit plus visible :ccool:
16/07/2012, 05h23
LittleWhite

Bonjour,

Pour le problème des tests, il en est de la précision des float (et de leur représentation dans un GPU / CPU). En effet, il arrive que l'on est quelque fois des imprécision (par exemple, 0 n'est pas réellement 0, mais 0.0000001 :aie:) et du coup, il se peut que cela fasse échouer le test (même si je doute, car il devrait y avoir un epsilon). En plus, cela dépend des cartes / constructeurs :D (sinon c'est pas fun :))

Sinon, il semble que votre cosNL soit proche de 0, dans tous les cas :P

Et pour revenir au pourquoi pas de tests en GLSL (GPU). C'est simplement car la carte graphique possède de nombreuses unités de calculs, parallèles et qu'elles calculent la couleur des pixels par bloc (on prend 16 pixels et c'est pusher en un tour). Lorsqu'il y a des tests, cela casse le parallélisme du bloc, car vous pouvez avoir deux pixels sur les 16 qui vont de l'autre coté du if (les relou) ... du coup, y a pas trop moyen de paralléliser, car on a pas la constante.
Après, ce qui se passe, c'est que le GPU, fainéant de trop réfléchir, va faire l'exécution des deux résultats du if (ou de plus) et regardera à la fin, quel est le résultat qu'il faut garder... Donc, les if sont déconseillé, car on perd tout de même pas mal de temps à les exécuter.

je dirais que cosNL est "Not a number" donc il echoue a tous les tests
on peut obtenir ce resultat avec un compilateur C normal:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 #include <stdio.h> #include <stdlib.h> int main(void) { float x = 0.0f/0.0f; if (x == 0.0f) { printf("0\n"); } else if (x < 0.0f) { printf ("< 0\n"); } else if (x > 0.0f) { printf ("> 0\n"); } else { printf("Eeeeuuuuh...\n"); } return EXIT_SUCCESS; }
not bien que 1.0f / 0.0f est pas indefini, c'est l'infini, c'est seulement 0/0 qui donne "Not a number"
il est possible que les cartes radeon ne le traitent pas comme NaN du aux optimisations, enfin quand on se retrouve avec NaN on ne peut pas s'attendre a des resultats corrects de toutes facons.

bref, reste a savoir comment tu calcules cosNL.

ausi, je veux dire, les performances du IF c'est gentil de lui dire mais il faisait ca pour faire du code de debug et afficher pourquoi le pixel etait noir, je crois que la performance il s'en fout... merci de rester sur le probleme de l'auteur du post, pas du probleme auquel vous savez repondre mais qu'on a pas demande.....

16/07/2012, 11h24
gbdivers

Pour le problème du test d'égalité avec les flottants, une disucssion récente sur le forum C++ : http://www.developpez.net/forums/d12...on-cpp-suffit/
Il y a également une série d'article de Gamasutra de sur le sujet en cours de traduction

Citation:

Envoyé par screetch

ausi, je veux dire, les performances du IF c'est gentil de lui dire mais il faisait ca pour faire du code de debug et afficher pourquoi le pixel etait noir, je crois que la performance il s'en fout... merci de rester sur le probleme de l'auteur du post, pas du probleme auquel vous savez repondre mais qu'on a pas demande.....

Oui, mais non. Si c'est effectivement du code de debug (ce qui n'est pas précisé), alors ok. Par contre, si c'est du code final, alors le problème des if (séquentialisation des instructions et donc perte de performance) peut amener à se poser la question de savoir s'il ne faut pas écrire le code sur CPU au lieu du GPU si le calcul n'est pas parallélisable
Comme on n'en sait pas assez, lui faire la remarque n'a rien de déplacé

merci pour toutes vos réponses ! ça fait plaisir que malgré mon niveau ridicule il y a quand meme quelqu'un pour aider :mrgreen:

voici mon fragment shader:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 varying vec3 normal, lightDir, eyeVec; void main (void) { vec4 final_color; vec3 N = normal; vec3 L = lightDir; float cosNL = dot(N,L); final_color = gl_LightSource[0].diffuse * cosNL; gl_FragColor = final_color; }
maintenant voici mon vertex shader :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 varying vec3 normal, lightDir, eyeVec; void main() { normal = gl_NormalMatrix * gl_Normal; vec3 vVertex = vec3(gl_ModelViewMatrix * gl_Vertex); lightDir = normalize(gl_LightSource[0].position.xyz - vVertex); eyeVec = normalize(-vVertex); gl_Position = ftransform(); }
Citation:

cosNL est "Not a number" donc il echoue a tous les tests

apparament oui... je cherche pourquoi mais franchement je voi pas bien

je pense que le soucis viens surement de la "communication" programme/shader, pourtant j'ai bien des glEnable(GL_LIGHTING); glEnable(GL_LIGHT0); avant mes glUseProgram(GLint); mai j'avoue que j'en sait rien... seulement une piste m'aiderai énormément...

(cf main.cpp tri.cpp si vous avait la patience et le courage de voir mon immonde code :cry:)

Citation:

il est préférable d'utiliser soit même les uniforms pour les lumières, et même pour tout le reste

si le problème persiste je recoderai toute mes light avec en uniform... pour l'instant j'aimerai seulement comprendre pourquoi madame graphics card n'a pas envie de me calculer le produit scalaire.

ps : mes if sont bien du code de debug (mais merci tout de meme pour les precision d'optimisation c'est toujours bon de le savoir)

16/07/2012, 11h41
screetch

il y a beaucoup de possibilites de planter:

- ta matrice de transformation pourrait etre nulle. Ce serait un bug dans ta communication programme-shader
- le vecteur gl_Vertex pourrait etre nul. Ca ca me semble plausible pour tous les objets; il suffirait d'avoir un vertex a l'origine dans ton modele 3D et c'est mort.
- le vertex peut coincider avec gl_LightSource[0]. Dans ce cas tu te retrouves avec une difference nulle et normalise dessus ca va pas etre glop.
- gl_LightSource peut etre NaN et dans ce cas ca propage les NaN partout
- gl_Normal peut etre NaN

je recommende donc de les prendre un par un et de remplacer les valeurs potentiellement pas belles par des valeurs codees en dur dans le shader, pour voir si ca aide, jusqu'a trouver le ou les NaN

Citation:

Envoyé par gbdivers

Oui, mais non. Si c'est effectivement du code de debug (ce qui n'est pas précisé), alors ok. Par contre, si c'est du code final, alors le problème des if (séquentialisation des instructions et donc perte de performance) peut amener à se poser la question de savoir s'il ne faut pas écrire le code sur CPU au lieu du GPU si le calcul n'est pas parallélisable
Comme on n'en sait pas assez, lui faire la remarque n'a rien de déplacé

oui mais non. Comme il n'a pas demande et que le code ressemble a du code pour debugger, la meilleure chose a faire c'est de ne pas etaler sa science comme du nutella.
16/07/2012, 12h04
gbdivers

On est complètement HS...
C'est une question récurrente : doit on répondre juste à la question technique posée ou doit on également apporter plus de précision sur les problèmes plus profonds que l'on soupçonne ?
Même si c'est un code de debug, il ne connaît pas forcement le problème des if, ni les spécificités de la représentation des flottants. Ce n'est pas du temps perdu de l'informer de l’existence de ces problèmes.
Je suis d'accord avec toi sur le fait qu'il faut répondre à la question en premier (ce que le premier post ne fait pas), mais il ne faut pas non plus dénigrer les informations un peu HS qui sont données
Fin du HS

suite aux conseils de screetch j'ai fait pas mal de test et suis tomber sur ce test
[c'est du code de debug !]

vertex shader:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 varying vec3 normal, lightDir, eyeVec; void main() { normal = gl_NormalMatrix * gl_Normal; vec3 vVertex = vec3(gl_ModelViewMatrix * gl_Vertex); //lightDir = gl_LightSource[0].position.xyz - vVertex; lightDir = vec3(150,150,150); //en dur comme conseiller... eyeVec = -vVertex; gl_Position = ftransform(); }
et le fragment
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 varying vec3 normal, lightDir, eyeVec; void main (void) { vec4 final_color; vec3 N = normalize(normal); vec3 L = normalize(lightDir); float cosNL = dot(N,L); final_color = gl_LightSource[0].diffuse * cosNL; gl_FragColor = final_color; if ((normal == vec3(0,0,0)) && (lightDir == vec3(0,0,0)) && (eyeVec == vec3(0,0,0))) gl_FragColor = vec4(0,1,0,1); else gl_FragColor = vec4(1,1,1,1); }
et c'est vert ! donc aucun de mes varying de passerait ? je sait pas si je suis devant un erreur mystique ou j'ai simplement fait une erreur honteuse :oops: (je penche pas mal sur la seconde...) mai je vois pas du tout ou ni meme ne comprend comme c'est possible...

ps : même si c'est aussi énorme que ce que je pense me frappez pas trop fort... :cry:

et avec

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
ou vec3 normal;
out vec3 lightDir;
out vec3 eyeVec;
 
void main()
{
  normal = gl_NormalMatrix * gl_Normal;
  vec3 vVertex = vec3(gl_ModelViewMatrix * gl_Vertex);
  //lightDir = gl_LightSource[0].position.xyz - vVertex;
  lightDir = vec3(150,150,150); //en dur comme conseiller...
  eyeVec = -vVertex;
 
  gl_Position = ftransform();
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
in vec3 normal;
in vec3 lightDir;
in vec3 eyeVec;
 
void main (void)
{
  vec4 final_color;
  vec3 N = normalize(normal);
  vec3 L = normalize(lightDir);
  float cosNL = dot(N,L);
 
  final_color = gl_LightSource[0].diffuse * cosNL;
  gl_FragColor = final_color;
 
  if ((normal == vec3(0,0,0)) && (lightDir == vec3(0,0,0)) && (eyeVec == vec3(0,0,0)))
    gl_FragColor = vec4(0,1,0,1);
  else
    gl_FragColor = vec4(1,1,1,1);
}

aussi, as tu un geometry shader?

J'ai trouvé plusieurs anomalies dans ton code qui sont surement la cause de ton problème. :)

Tout d'abord, parlons des shaders : je vois que tu utilises 2 instances (vtx et frg) de ta classe shader dans tri.hpp. Et chacune crée un shader program. Et que ensuite dans ton pipeline tu fait un :
Code:

1 2 3 vtx.call(); frg.call();
or ces fonction call tu les a définie comme ceci (dans shade.hpp) :
Code:

1 2 3 4 5 void call() { glUseProgram (programID); }
Donc la tu fais ta première érreur que je me permet d'expliqué plus en détail maintenant :
Tu confonds les shader et les shader programs en réalité. Un shader program est en fait un ensemble de shader que tu attache, un vertex shader, un fragment shader, et bien d'autre type ... (que je permet de passé pour ne pas t'embrouillé) Ensuite ce shader program tu l'appel par glUseProgram (programID); comme tu l'as compris.
Mais un shader program doit être au moin constitué d'un vertex shader et d'un fragment shader, alors que ta classe shader te créer deux shader programs, un pour ton vertex shader et un pour ton fragment shader. Donc en faite, tes shaders ne sont pas sur le même shader program, donc il ne fonctionne pas ensemble.
Or dans ton pipeline tu appelés vtx.call(); et ensuite frg.call(); donc concrètement ce qui se passe, tu appel le shader program qui n'a que le vertex shader, et tu remplace tout de suite par le shader program qui n'a que le fragment shader. Donc tu dessine sans vertex shader, avec ton fragment shader, mais donc tes varying que tu récupère dans ton fragment shader ne seront pas contrôlé par le vertex shader car il n'y en a pas sur le shader program dernièrement choisi avec glUseProgram. :aie:
Donc je te propose une nouvelle architecture de ta classe shader qui serai fonctionnel avec la documentation OpenGL : ta class shader doit géré le chargent du vertex shader et du fragment shader, et tu attaches ces deux shaders à un seul et même shader program qui sera indexé par le membre programID de ta class shader. Et ensuite tu fais donc un seul mon_shader_program.call (); dans ton pipeline avant ton dessin, et tes shaders seront ainsi fonctionnels.

Ensuite deuxième anomalie trouvé dans le pipe line :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 void tri::put() { glEnable(GL_LIGHTING); glEnable(GL_LIGHT0); vtx.call(); frg.call(); glEnableClientState(GL_VERTEX_ARRAY); glVertexPointer(3, GL_FLOAT, 0, g_vertex_buffer_data); glDrawArrays(GL_TRIANGLES, 0, 3); glDisableClientState(GL_VERTEX_ARRAY); glDisable(GL_LIGHT0); glDisable(GL_LIGHTING); }
Il faudrait peut être aussi envoyer les normals des vertex au shader program aussi ? sinon gl_Normal sera un vecteur null. ;)

Sinon, ton fragment shader correct, mais n'oublie pas le max(cosNL, 0.0), parce que sinon il y aura des couleur négative pour les faces qui sont dos à ta source lumineuse. :ccool:
Code:

1 2 3 4 5 6 7 8 9 10 11 varying vec3 normal, lightDir, eyeVec; void main (void) { vec3 N = normal; vec3 L = lightDir; float cosNL = dot(N,L); gl_FragColor = gl_LightSource[0].diffuse * max(cosNL, 0.0); }
Il ce peut qu'il y ai encore des problèmes, mais pour commencer, il faut déjà corriger ces deux là. Je regarde encore ton code voir si il y en aurait pas d'autre ... :ccool:

PS (@ screetch): Je ne peut résister a l'envi de te dire, et ce en tout courtoisie, de revoir ta manière de venir en aide. C'est pas un algo C/C++ exécuté sur un CPU doté d'une architecture complètement différent des unités de calcul d'un GPU qui va faire avancer le problème. Alors serte tu peut accusé que nos remarques sur les conditions GLSL n'aide pas parce que plus compliqué, mais on ne fait que rapporté les problèmes dans l'ordre ou on les trouves. Sans rancunes.

16/07/2012, 14h22
newinn

@LastSpear je vai regler tout ces soucis, et merci aussi pour l'eclairement entre les shader et les programes ! merci aussi d'avoir passer du temps dans mon code

aux autres merci pour vos précision vous m'avez apris pas mal en quelque heures :P

je vous tiens au courent des que j'ai attacher mes shader au même program :mrgreen:
16/07/2012, 15h26
newinn

j'ai créer une class shaderProgramm qui possède un vertex shader et un fragment shader et les attache au même programme et ça m'a l'air de fonctionner vachement mieux.

maintenant, juste avant de clore je sujet j'ai trouver
glEnable(GL_NORMALIZE);
qui (m'a-t-on dit) crée les normals a la vole pendant le rendu.
faut-il les initialiser ou ça crée des normal perpendiculaire au tri ?
16/07/2012, 17h06
LastSpear

A moins de dire une bêtise, je crois que glEnable(GL_NORMALIZE) ne calcul pas les normals, mais s'assure seulement que gl_Normal dans ton shader soit bien de norme 1.

La gestion des normals dépends des artistes qui crée les objets 3D après ... En effet, tu peut par exemple lissé les normals des objets partout si tu veux une sphère bien "ronde" (même si elle est faite avec des triangles), qu'a certain endroit (si tu veux quand même avoir une arrête bien vive sur une demi-sphère par exemple), ou voir même pas du tout (si tu veux un dée à 6 faces par exemple).

A ce moment là, je te propose d'implémenter un loader OBJ ou 3DS, les plus simples à réalisé, et apporté la gestion du stockages des normales dans ton système de vertex array. Ensuite, tu crées tes objets avec l'éditeur 3D de ton choix. (Blender est gratuit).

Sinon tu peut à partir d'un vertex array calculé les normals, pour rappel une normal d'une surface triangulaire ABC n'est autre que le vecteur normalisé de AB ^ AC avec ^ produit vectoriel.

Regarde aussi du coté des VBOs, se sont comme des vertex array, mais stocké sur la mémoire GPU, donc plus rapide à dessiné. Comme çà tu pourras prendre en main toute la puissance de ta 6870. :ccool:
16/07/2012, 17h57
newinn

merci pour tes lunieres (sans jeux de mots...) ! je vais m'interreser au VBO (on m'en a deja parler) mai je vai commencer par coder mon parceur de .obj (c'est vachemen simple alors ...). sauf si le VBO change toute l'architecture...

bon bref je clos ^^ encore merci a tout ceux qui ont passer du temps a me repondre :mrgreen:

ps : je suis artiste 3D avec blender avant de coder (j'ai commencer a coder que depuis 1 ans)