Suivant les conseil de JY², j´ai jeté un oeil à glOrtho versus gluPerspective.

J´ai eu un cour d´algèbre linéaire et vectoriel ( niveau collégial) pendant la session qui vient tout juste de terminer. Franchement, j´aurais penser pouvoir piger un peu plus facilement les matrices avec ça. Mais, au final, j´ai appris comment faire les calculs à la base des matrices mais vraiment pas à visualiser le résultat dans un environnement.

Donc, en gros, ce que je cherche à dire, c´est que j´ignore l´intérêt de multiplier la matrice de projection ( supposant qu´elle soit ramenée à la matrice identité avant tout... bien qu´il y a peut-être une utilité à faire cette démarche sur une matrice qui n´est pas identité mais je vois encore moins qu´est-ce qu´elle pourrait être).

Quelqu´un ici serait-il capable " d´illustrer" les résultats de glOrtho versus ceux de gluPerspective ? Ce genre de trucs, j´en mange généralement alors si vous vous sentez d´attaque, hésitez pas sur les détails .

Merci !

Juste en guise de piste sur le genre d´information qu´il me faut pour comprendre... Quelqu´un peut me dire exactement à quoi correspond chaque position dans la matrice de projection ? Si je ne suis pas complètement fou, c´est une matrice 4x4 ? !

Je me base sur ces trucs...
http://pyopengl.sourceforge.net/documentation/manual/gluPerspective.3G.html
http://pyopengl.sourceforge.net/documentation/manual/glOrtho.3G.html

Je suppose que dans le cas de la matrice de projection, on parle ici de la position de la caméra donc ça donnerait...

x___
_y__
__z_
____

Résultat, tous les _ sont des trucs dont j´ignore l´utilité .

Ah les matrices C´est bien puissant ça !
Allez, petit cours de maths :
Titre " Les espaces Affines" et " Les espaces de projection"

Tu connais peut etre déja les espaces vectoriels ? Ici, on ne va parler que des espaces de R^3
Disons qu´un tel espace vectoriel n´est fait que de vecteur a 3 composantes x,y,z

Passons direct aux espaces Affines :
Dans un tel espace ( toujours R^3), tu as un " monde" constitué uniquement de VECTEURS et aussi de POINTS
on ecrit chaque point ou vecteur avec x,y,z,w
On dit que si w = 0 --> c´est un vecteur
On dit que si w = 1 --> c´est un point
Aucune autre valeur de w n´est admise en espace Affine.
Et tout se vérifie :
Tu peux additionner ou soustraire des vecteurs a ton aise ! Pour le w, ça donne :
0 + 0 - 0 + 0 + . ... + 0 = ( la tete a toto) = 0 --> valeur w valide : c´est un vecteur
Tu peux calculer un point + 1 vecteur ( toujours si tu regardes le w ) :
1 + 0 = 1 --> le resultat est un point
Tu peux calculer la distance ( le vecteur entre 2 points )
1 - 1 = 0 --> vecteur
Tu peux calculer le point milieu de 2 points :
( 1 + 1)/2 = 1 --> point
Tu peux calculer le point milieu de n points :
( 1 + . .. +1)/n = 1 --> point
mais tu ne peux pas calculer la somme de 2 points ( ça ne veut rien dire)
1 + 1 = 2 --> invalide
etc ! ! c´est bien fait les espaces affines...

Une matrice de transformation est un changement de repere, donc simplement l´image de la base :
a d g j
b e h k
c f i l
0 0 0 1
comme tu vois, en colonne, tu as 3 vecteurs et un point ( en regardant la derniere ligne) : ça correspond aux vecteurs x,y,z de la nouvelle base, et au nouveau centre.

Une transformation dans l´espace affine a toujours cette tete.
la matrice ModelView par exemple, a TOUJOURS cette tete la.

Passons maintenant a ton soucis.
Une fois qu´OpenGL a multiplié un point par ModelView, la coordonnée x,y,z de ton nouveau point est dans le repere de la caméra.
C´est a dire que, une fois multiplié, tu es dans le cas particulier intéressant ou ta caméra est en 0,0,0 et regarde dans la direction z=1

Le plus simple est glOrtho. Regarde la page que tu m´as donné sur glOrtho : regarde la tete de la matrice : si tu regardes la derniere ligne, tu vois que c´est toujours 0 0 0 1 --> transformation affine.
glOrtho te fait juste une projection orthogonale sur le plan z : c´est a dire que 2 points qui auront le meme x,y ( je parle des points déja traités par ModelView) seront superposés a la sortie.
prend le cas particulier ou ta caméra est centrée autour de 0 ( prend par exemple right=1, left=-1 top=-1 bottom=1, tu es ok que la caméra est centrée autour de 0)
calcule maintenant tx,ty --> 0
tout ce que tu constates, c´est que si tu remplaces les -1 par des 1 et les -2 par des 2, tx et ty vaudront toujours 0 mais les points seront + serrés.
ça vient des valeurs de a,e,i ( cf ma matrice plus haut) qui seront plus petites, donc les vecteurs de la base image seront plus petit --> on a une matrice " scale" une matrice d´échelle.
si maintenant tu donnes 0,0,1,1 --> ton centre sera 0.5 0.5 --> calcule tx,ty --> translation de la caméra pour mettre au bon endroit.
le calcul tz et i vont juste permettre ensuite a mettre a l´échelle le z pour le z-buffer, c´est tout.

Voila comment marche la matrice de projection pour glOrtho.

Maintenant ça se corse pour glPerpective.
Probleme : pour un x,y donné, la coordonnée rasterisée dépend du z... et tu n´as plus un rectangle de vue mais un frustrum
Il n´existe pas de transformation affine pour faire cela, il faut donc trouver une transformation qui va plus loin que les transformations affine
la matrice de glPerspective, tu le vois, ne finit pas par 0 0 0 1.
Pire, il y a un -1, ce qui est une valeur interdite dans l´espace Affine...

--> Bienvenue dans l´espace de projection.
Ce que je peux te dire, c´est qu´un " machin" dont le w!=0 et w!=1 dans cet espace est toléré. On parle souvent de points infinis pour ce genre de trucs.
et le point infini est - comme par hasard - en face de " z" --> cela veut dire que c´est z qu´on va projeter.
Mes connaissances en espace de projection ne sont pas encore parfaites, donc je vais m´arreter la, pour ne pas te dire des conneries.
Je sais qu´il y a des démonstrations pas forcément trivialles la dessus.

J´espere avoir pu t´éclairer

JY² : tres bon petit concentré sur les espaces affines

juste un petit complément plus proche de la question initiale, p-e :
" j´ignore l´intérêt de multiplier la matrice de projection ( supposant qu´elle soit ramenée à la matrice identité avant tout)"

note bien que le role de ta matrice de projection est de PROJETER ( si si) des points à l´intérieur de la pyramide tronquée ( frustrum dont parle JY²) sur le plan de l´écran ( le sommet de la pyramide, en l´occurence). Avec une matrice identité, tu ne projetes rien du tout, puisque tous tes points sont invariants.

Un petit mot de " pratique" sur les espaces projectifs, aussi. L´interet des espaces projectifs et qu´on travaille avec des classes d´équivalence : tous les éléments ayant la meme projection constitue une classe. Autrement dit, quand on choisit par ex. un point de écran ( plan de projection), on dertermine implicitement toute une famille d´éléments : les points 3D se projetant à cet endroit.
On remarque, en disant ça, un automorphisme naturel entre R^4 et un espace projectif construit sur R^3. C´est d´ailleurs de là que vient l´introduction de la coordonnées homogène w. Avantage dont parlait JY², on peut matérialiser, avec cette notation, les points à l´infini, qui definissent donc une classe d´équivalence à part entière, et se projetent en un meme point.

Au passage, non ce n´est pas intuitif du tout, au début, ces histoires d´espaces projectifs et de w ; donc pas d´affolement si on se paume un peu...

La prochaine fois, c´est sur quoi ? géométrie épipolaire ?

Merci ! J´ai tout sauvegardé, je vais prendre le temps d´étudier ça bien tranquillement je crois .

Franchement, ça donne hate à un cour de maths vectoriels encore plus poussé, je vois bien que je suis pas entièrement près pour entrer dans les petits détails ( j´essais quand même remarquez bien ) .

Ça m´amène à une autre question ( plus courte celle-là)... Les intrégrales et les différentielles, ça sert dans les jeux ? Je me doute bien que ça ne doit pas être inutile mais qu´est-ce qu´on fait généralement avec ça ?

Curiosité encore !

Merci !

oui, ça sert, mais les versions " numériques" seulement ( un poil différente des écritures formelles, y´a une discrétisation en plus, quoi).
Les applications sont variées, calculs d´aires, de distances, filtrage, etc. A partir du moment où ça rentre dans le domaine de traitement du signal, tu peut t´en servir à peu pres partout...

Je vois, merci encore !

Balèze LGV c´est vrai que c´est pas évident les espaces de projection

vaut mieux se servir de OpenGL qui fait ça tout seul comme un grand en fait

c´est clair.. mais quand on dit que la théorie derrière la 3D c´est pas trivial.. ; )