J'essaie de comprendre le système de coordonnées OpenGL. Cependant, certains tutoriels disent que le système de coordonnées par défaut est gaucher (voir http://www.c-sharpcorner.com/UploadFile/jeradus/OpenGLBasics11172005014307AM/OpenGLBasics.aspx ) et d'autres disent qu'il est droitier (voir http: // www .falloutsoftware.com / tutoriels / gl / gl0.htm ). Qui est correct? Je comprends que nous pouvons transformer l'un en l'autre par mise en miroir mais j'aimerais connaître les coordonnées par défaut.

Il y a une certaine confusion ici.

OpenGL est droitier dans l'espace objet et l'espace mondial.

Mais dans l'espace fenêtre (aka espace écran), nous sommes soudainement gauchers .

Comment est-ce arrivé ?

La façon dont nous passons de droitier à gaucher est une entrée de mise à l'échelle z négative dans les matrices de projection glOrthoou glFrustum. La mise à l'échelle de z par -1 (tout en laissant x et y tels quels) a pour effet de modifier la sensibilité du système de coordonnées.

Pour glFrustum,

loin et proche sont supposés être positifs, avec loin > proche . Dites loin = 1000 et près = 1. Alors C = - (1001) / (999) = -1,002.

Voir ici pour plus de détails et de diagrammes.

D'un point de vue orthographique , glOrtho génère une matrice comme celle-ci:

Ici, à gauche , à droite , en bas et en haut sont seulement les coordonnées de gauche verticale , droite verticale , horizontale inférieure , supérieurs horizontaux plans de délimitation (resp) .

Les plans proche et éloigné , cependant, sont spécifiés différemment . Le paramètre proche est défini comme

• Near: La distance par rapport au plan de détourage de profondeur le plus proche. Cette distance est négative si l'avion doit être derrière le spectateur.

et loin:

• zFar La distance par rapport au plan de détourage de profondeur le plus éloigné. Cette distance est négative si l'avion doit être derrière le spectateur.

Ici, nous avons un volume de vue canonique typique

Comme le multiplicateur z est (-2 / (très proche)), le signe moins met effectivement à l'échelle z par -1 . Cela signifie que "z" est tourné à gauche pendant la transformation de visualisation, à l'insu de la plupart des gens car ils travaillent simplement dans OpenGL comme un système de coordonnées "droitier".

Donc, si vous appelez

glOrthof(-1, 1, -1, 1, 10, -10) ; // near=10, FAR=-10,

Alors le PRÈS DE L'AVION a 10 unités devant vous . Où es-tu? Pourquoi, à l'origine, avec l'axe x à votre droite, l'axe y au-dessus de votre tête et votre nez pointant vers le bas l'axe z négatif (c'est la valeur par défaut "Par défaut, la caméra est située à l'origine , pointe vers le bas l'axe z négatif et a un vecteur ascendant de (0, 1, 0). " ). Le plan proche est donc à z = -10. Le plan lointain est à 10 unités derrière vous, à z = + 10 .

Par défaut, la coordonnée normalisée de l'appareil est gaucher.

Le glDepthRange est par défaut [0, 1] (proche, loin) faisant pointer l'axe + z dans l'écran et avec + x à droite et + y en haut, c'est un système gaucher.

Changer la plage de profondeur sur [1, 0] rendra le système droitier.

Citant une réponse précédente de Nicol : (le barré est mon travail, expliqué ci-dessous)

Je suis surpris que personne n'ait mentionné quelque chose: OpenGL fonctionne également dans un système de coordonnées gaucher. Du moins, c'est le cas lorsque vous travaillez avec des shaders et utilisez la plage de profondeur par défaut.

Une fois que vous avez jeté le pipeline à fonction fixe, vous vous occupez directement de "l'espace de clip". La spécification OpenGL définit l'espace-clip comme un système de coordonnées homogène 4D. Lorsque vous suivez les transformations via les coordonnées normalisées de l'appareil, et jusqu'à l'espace de la fenêtre, vous trouvez ceci.

L'espace de la fenêtre est dans l'espace des pixels d'une fenêtre. L'origine est dans le coin inférieur gauche, avec + Y vers le haut et + X vers la droite. Cela ressemble beaucoup à un système de coordonnées droitier. Mais qu'en est-il de Z?

La plage de profondeur par défaut (glDepthRange) définit la valeur proche de Z sur 0 et la valeur de loin Z sur un . Le + Z s'éloigne donc du spectateur.

C'est un système de coordonnées gaucher. Oui, vous pouvezchanger le test de profondeur de GL_LESS à GL_GREATER etchangez le glDepthRange de [0, 1] à [1, 0]. Mais l' état par défaut d'OpenGL est de travailler dans un système de coordonnées gaucher . Et aucune des transformations nécessaires pour accéder à l'espace fenêtre à partir de l'espace de clip annule le Z. Donc, l'espace de clip, la sortie du shader de vertex (ou de géométrie) est un espace de gauche (un peu. C'est un espace homogène 4D, donc il est difficile de cerner la sensibilité).

Dans le pipeline à fonction fixe, les matrices de projection standard (produites par glOrtho, glFrustum et autres) se transforment toutes d'un espace droitier à un espace gauche . Ils inversent la signification de Z; vérifiez simplement les matrices qu'ils génèrent. Dans l'espace oculaire, + Z se déplace vers le spectateur; dans l'espace post-projection, il s'éloigne.

Je soupçonne que Microsoft (et GLide) n'ont tout simplement pas pris la peine d'effectuer la négation dans leurs matrices de projection.

J'ai frappé une partie car elle divergeait de mes conclusions.

Le changement de DepthRange ou de DepthFunc et l'utilisation de ClearDepth (0) fonctionnent mais lors de l'utilisation des deux, ils se sont annulés pour revenir à un système gaucher.

UNIQUEMENT NDC

Vous devriez seulement remarquer qu'OpenGL ne connaît que NDC! et c'est un système de coordonnées gaucher.

Quel que soit le système de coordonnées que vous utilisez - système de coordonnées d'axe gauche ou droit - tous doivent être mis en miroir sur NDC. Si vous le souhaitez, vous pouvez totalement gérer l'espace-monde comme un système de coordonnées gaucher.

Pourquoi utilisons-nous généralement un système de coordonnées droitier dans l'espace-monde?

Je pense que c'est conventionnel. C'est juste le cas. Peut-être veut-il simplement faire la distinction avec DirectX.

Le livre "WebGl Programming Guide" de Kouichi Matsuda consacre près de dix pages à "WebGl / OpenGl: Left or Right Handed?"

D'après le livre:

• En pratique, la plupart des gens utilisent un système droitier

• OpenGl est en fait un système pour gauchers en interne

• En interne, plus profondément, ce n'est ni l'un ni l'autre. Tout en bas, OpenGl ne se soucie pas de la valeur z. L'ordre dans lequel vous dessinez les choses détermine ce qui est dessiné en haut (dessinez d'abord un triangle, puis un quad, le quad remplace le triangle).

Je ne suis pas entièrement d'accord avec le «ce n'est ni l'un ni l'autre», mais c'est probablement une question philosophique de toute façon.

Opengl est définitivement gaucher. Vous voyez de nombreux didacticiels indiquant le contraire car ils annulent la valeur z dans la matrice de projection. Lorsque les sommets finaux sont calculés à l'intérieur du vertex shader, il convertit les sommets que vous passez du côté client (coordonnée à droite) en gaucher, et les sommets seront ensuite passés au shader geometry et au fragment shader. Si vous utilisez le système de coordonnées de droite côté client, Opengl s'en fiche. Il ne connaît que le système de coordonnées normalisé, qui est gaucher.

Edit: Si vous ne me faites pas confiance, expérimentez simplement votre vertex shader en ajoutant une matrice de traduction, et vous pourrez facilement voir si Opengl est gaucher ou non.

En utilisant les fonctions de projection et de transformation intégrées d'OpenGL, l'observation des mouvements à l'écran suit les règles du système de coordonnées droitier . Par exemple, si un objet devant votre vue est traduit dans la direction z positive, l'objet se déplacera vers vous.

Le tampon de profondeur est tout le contraire, et c'est là que les NDC (Normalized Device Coordinates) entrent en jeu. Si le fait de passer GL_LESS dans glDepthFunc signifie que les pixels seront dessinés lorsqu'ils seront plus proches de vous que ce qui se trouve déjà dans le tampon de profondeur, alors les pixels sont considérés comme vivant dans un système de coordonnées gaucher .

Il y a un autre système de coordonnées, et c'est la fenêtre! Le système de coordonnées de la fenêtre est tel que + x pointe vers la droite et + y pointe vers le bas. Je pense qu'à ce stade, la sensibilité est sans objet puisque nous n'avons affaire qu'à x, y à ce stade.

Enfin, gluLookAt sous le capot doit annuler le vecteur de regard. Étant donné que le calcul suppose qu'un vecteur pointe dans une direction positive vers l'objet qu'il regarde et qu'une caméra regarde vers le bas -z, le vecteur d'observation doit être annulé afin qu'il s'aligne avec la caméra.

Quelque chose à mâcher. Cela n'a pas beaucoup de sens d'appeler la direction z d'un système de coordonnées droitier un vecteur avant :). Je pense que Microsoft a réalisé cela quand ils ont conçu Direct3D.