Discussion :

[Michel_57]

Bonjour à tous.

J'ai lu récemment un cours sur opengl2. Puis j'ai lu un autre cours sur opengl3. Le problème c'est que le cours d'opengl3 était axé sur la réécriture des fonctions disparues (dépréciées) depuis opengl2 comme glulookat, glperspective, glrotate, etc ...

Je me dit que c'est idiot de détruire quelque chose pour le refaire exactement pareil ...

Alors je me suis posé beaucoup de questions, et j'aimerais bien avoir quelques renseignements sur la philosophie de cette version 3.

1) Le produit matriciel

Les matrices 4x4 permettent de définir un repère par rapport au repère absolu, à l'aide de multiplications de matrices. Est-ce possible, judicieux, de faire faire ces calculs par le GPU au lieu du CPU ? En gros, si on peut passer une série de transformations via un tableau (je ne sais pas si ça marche) et le GPU s'occupe du reste.

2) La projection sur une surface 2D

Dans le cours que j'ai lu, ils définissent une fonction du genre glperspective et une du genre glulookat. Je ne comprend pas pourquoi on passe par deux fonctions. Une fois que toute la scène 2D est définie, on doit la projeter sur une surface rectangulaire selon un certain vecteur directeur. Il y a sûrement une matrice qui le fait d'un coup non ? Pourquoi passer par deux fonctions ?

3) Shader

Je ne connais encore quasiment rien là-dessus donc je vais encore potasser, mais j'ai une question de base déjà. Si on veut utiliser le même shader (un vert et un frag) dans toute l'application (pour commencer) quel est le code minimal ? Parce qu'il y a beaucoup de choses, je ne sais pas où elles vont (à l'initialisation ? dans la boucle principale ? avant/après chaque appel à drawelement/drawarrays ?).


Merci de m'avoir lu et re-merci d'essayer de m'aider

[stardeath]

1) j'ai pas compris ta remarque.

2) glperspective permet de définir la matrice de projection qui va "transformer" les points 3D en points 2D.

glulookat permet de transformer les points 3D du repère monde vers le repère utilisateur.

les 2 matrices n'ont donc totalement rien à voir entre elles. avoir 2 matrices permet d'avoir la flexibilité de pouvoir en changer 1 voire les 2 de manière indépendante.

[Michel_57]

Pour le premier point :
On fait les multiplications de matrices pour calculer la position des sommets. Pourquoi ne pas envoyer au GPU les sommets de base, sans transformation, et avec ça un tableau de transformations, par exemple dire au GPU que tels sommets doivent subire telle rotation et telle translation avant d'etre affichés. Comme ça on déleste le CPU des produits matriciels sur les matrices "modelview".

Pour le second point :
Je ne comprend pas pourquoi on a besoin de passer par 3 matrices pour faire une projection. En gros vous me dites, on doit changer le repère monde en repère utilisateur, puis projeter sur un plan. Mais n'est-ce pas totalement identique à projeter directement sur le plan, sous réserve qu'on ait son équation ?
Je formule autrement :
Ce que l'on fait c'est tourner et déplacer tous les objets avec glulookat, et à la fin on projette sur un plan fixe. N'est-ce pas identique à projeter directement sur un plan mobile ?


Si la disparition de ces fonctions dans opengl3 doit servire à faire des optimisations, je me demande si elles se situent là où je pense, ou si je suis à côté de la plaque.

[stardeath]

pour le 1), c'est déjà ce qu'on fait, on passe les points non transformés au gpu, on lui passe aussi les matrice de transformation, et il calcule tout, tout seul.

pour l'histoire des 3 matrices, c'est surtout une histoire de simplification et pas d'optimisation.

en plus on fixe 3 matrices, mais rien ne nous empêche d'en voir plus, avant on était limité à 2 matrices (MODELVIEW et PROJECTION), maintenant on peut faire ce que l'on veut.

[pyros]

Salut,

1) Ca dépend si le résultat du calcul dépend du vertex ou du mesh. S'il est constant pour tous les vertex (exprimer le vecteur lumière dans le repère caméra par ex.), il vaux mieux le calculer une fois sur le cpu et le passer au shader (ne pas oublier qu'un vertex shader s’exécute 1 fois pour chaque vertex). S'il dépend de chaque vertex (typiquement multiplier la position d'un vertex par une matrice de passage), là autant le faire sur GPU. Après tout, c'est son boulot

2) En gros, la matrice projection représente la lentille de la caméra. C'est elle qui gère le zoom si tu préféré. Elle est généralement assez simple (diagonale pour une camera orthographique, diagonale avec valeur non nul sur la dernière ligne pour une perspective)
La matrice vue représente la position de la caméra dans le scène.
La matrice model représente la position de ton objet dans la scène.

Ces 2 dernières sont normalement des composition de rotation, translation et homothétie (mais rien ne t’empêche des faire des distorsions un peut plus compliqué )

Souvent, les matrice models et vue sont fusionnée (la fameuse matrice modelView).

Cependant, certains effets ne doivent pas être appliqués en utilisant la projection (l'éclairage par exemple, et tout ce qui utilise les normales en général). Mais je ne me souvient plus exactement pourquoi .
C'est pourquoi on a toujours au moins la matrice de projection et la matrice modelView.

3) Dsl, pas le temps de te donner du code, mais un shader s'utilise comme une texture. Tu le cré au début et tu le bind à chaque fois avant de dessiner ton objet. Dans ton cas, avant le drawElement.

[LastSpear]

Hello

Cependant, certains effets ne doivent pas être appliqués en utilisant la projection (l'éclairage par exemple, et tout ce qui utilise les normales en général). Mais je ne me souvient plus exactement pourquoi

- si tu applique ta matrice de projection sur tes normal, elle seront plus du tout de norme 1 (sauf si ta projection est d'un angle nulle). Et même, il faudrait aussi changé totalement de base pour tout les position de lumière aussi : une galère inutile.
- si tu applique au couleur (de lumière et autres), ce ne seront plus les mêmes couleurs et le rendu ressemblera à rien.

Le passage à OpenGL 3 et supérieur, est vraiment radicale ! Beaucoup plus de rigueur dans la programmation niveau API, mais çà t'offre beaucoup plus de liberté. Fini les Push/PopMatrix, Scale, Translate. Tu génère comme bon te semble les matrices, beaucoup plus libre. Grace à çà, il faut aller dans la nouveauté : multithread.

- thread 1 : le rendu OPENGL qui fait que des commende OpenGL 3 (ou supérieur bien sur) à gogo, en optimisant un maximum (ARRAY_BUFFER, le dessin par instance, UNIFORM_BUFFERS).
- thread 2 : événement, et calcul des nouvelles matrices, animation et optimisation d'affichage.

Et si t'a la chance d'avoir un ordi avec plusieurs carte graphiques, tu peut même te débrouillé pour faire plusieurs threads dédié à OpenGL. (Grosse prise de tète, mais les performances sont au rendez vous)

Si la disparition de ces fonctions dans opengl3 doit servire à faire des optimisations, je me demande si elles se situent là où je pense, ou si je suis à côté de la plaque.

C'est juste que les architectures de cartes graphiques évoluent très rapidement, donc certaines techniques comme les displays listes, deviennent pas suffisamment puissantes pour exploiter tout les ressources de la carte graphique. :cool:

Si tu va en version 3, profite pour passé directement en 3.3 (pense à mettre tes pilots à jour), il n'y aura pas beaucoup de différences, elle est très ressente, profite de pas mal de nouveauté (même si C pas la 4.2 bien entendu )

donc un petit exemple de petit shader :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
// VERTEX SHADER
#version 330
 
// des constantes que tu peut modifier par l'API
uniform mat4 CameraViewMatrix ;
uniform mat4 ProjectionMatrix ;
uniform mat4 ViewProjectionMatrix ;
 
// les donné entrante, venant des vertex array ou plus souvent des VBO
layout(location = 0) in vec4 InVertex ;
layout(location = 1) in vec3 InNormal ;
 
// les donné envoyer au fragment shader
out vec3 Normal ;
 
void main ()
{
// le code du shader
    gl_Position = ProjectionMatrix * (CameraViewMatrix * InVertex);
// ou : gl_Position = ViewProjectionMatrix * InVertex ; => plus rapide bien entendu !
 
    Normal = InNormal ;
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
// FRAGMENT SHADER
#version 330
 
// encore des constantes que tu peut modifier par l'API
uniform vec3 SunDir ;
uniform vec4 Ambient ;
uniform vec4 Difuse ;
 
// les donné recupéré du vertex shader
in vec3 Normal ;
 
// la couleur de ton pixel dans ton FBO
out vec4 FragColor ;
 
void main ()
{
// le code du shader
    float SunDot = max(dot(Normal, SunDir), 0.0);
 
    FragColor = Ambient + SunDot * Difuse ;
    FragColor.a = 1.0 ;
}

Dès que tu va goutté au shaders, tu ne t'en débarrassera plus du tout car c'est grasse à çà que tu peut faire des vagues, post processing, et autre effet très sympathique.

[pyros]

si tu applique ta matrice de projection sur tes normal, elle seront plus du tout de norme 1 (sauf si ta projection est d'un angle nulle)

Si tu fait un scale dans ta modelView aussi. Je crois que c'est plus une histoire que la projection perspective casse le produit scalaire (le repère n'est plus orthogonal, donc tu perd la notion de normal).

Pour le passage à openGL 3, en plus de "quelques" nouvelles features, le gros changement est la disparition de beaucoup d'ancienne méthode (displayList, glBegin, ...). Depuis le temps qu'on nous dit de plus utiliser le mode direct (glBegin, glVertex), fallait bien que ça arrive
La disparition des anciennes fonctions sert surtout à faire de la place sur silicium. Dans l'absolue, gérer ses matrices à la main, faire du multithread et multigpu, on pouvait le faire avant. Mais là, on sera obligé, et ça sera plus simple