Pourquoi DirectX utilise-t-il un système de coordonnées pour gaucher?
J'ai envisagé de publier sur Stack Overflow, mais la question me semble beaucoup trop subjective car je ne peux pas penser à une explication technique raisonnable du choix de Microsoft dans cette affaire. Mais cette question me dérange depuis si longtemps et le problème revient sans cesse dans l'un de mes projets, et je n'ai jamais vu de tentative d'expliquer cela:
OpenGL utilise un système de coordonnées droitier, où la partie + Z du système de coordonnées mondial s'étend vers la visionneuse.
DirectX utilise un système pour gauchers où la partie + Z de la coordonnée mondiale s'étend dans l'écran, loin du spectateur .
Je n'ai jamais utilisé Glide API , donc je ne sais pas comment cela a fonctionné, mais d'après ce que je peux en déduire, il utilise également un système pour gauchers.
Y a-t-il une raison technique à cela? Et si non, y a-t-il un avantage conceptuel à la neutralité particulière d'un système de coordonnées? Pourquoi choisirait-on l'un plutôt que l'autre?
Je sais que c'est un ancien post, mais j'ai vu ce post référencé et je n'aime pas le ton de la réponse choisie.
J'ai donc fait un peu d'enquête!
- DirectX est ancien. Il a été publié pour la première fois en 1995, lorsque le monde comptait bien plus que Nvidia et ATI , DirectX vs OpenGL. Cela fait plus de 15 ans, les gens.
- dfx Interactive Glide (un des concurrents de DirectX à l'époque. OpenGL n'était pas destiné à jouer à l'époque) utilisait un système de coordonnées pour gaucher.
- POV-Ray et RenderMan (logiciel de rendu Pixar), utilisent également un système de coordonnées pour gaucher.
- DirectX 9+ peut fonctionner avec les deux systèmes de coordonnées.
- WPF et XNA (qui fonctionnent avec DirectX sous les scènes) utilisent un droit de coordonnées à main levée.
De cela, je peux spéculer sur deux ou trois choses:
- Les normes de l'industrie ne sont pas aussi standard que les gens aiment.
- Direct3D a été construit à une époque où tout le monde faisait les choses à sa manière, et les développeurs ne savaient probablement pas mieux.
- La gaucherie est facultative, mais habituelle dans le monde DirectX.
- Étant donné que les conventions s'éteignent, tout le monde pense que DirectX ne peut fonctionner qu'avec la gaucherie.
- Microsoft a finalement appris et suivi la norme dans toutes les nouvelles API qu'ils ont créées.
Par conséquent, ma conclusion serait:
Quand ils ont dû choisir, ils ne connaissaient pas la norme, ont choisi `` l'autre '' système, et tout le monde s'est contenté de faire le tour. Aucune affaire louches, juste une décision de conception malheureuse qui a été emportée parce que la compatibilité descendante est le nom du jeu de Microsoft.
Je suis surpris que personne n'ait mentionné quelque chose: OpenGL fonctionne également dans un système de coordonnées gaucher. Au 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 traitez directement avec "clip-space". La spécification OpenGL définit l'espace de clip comme un système de coordonnées homogène 4D. Lorsque vous suivez les transformations par le biais de coordonnées d'appareil normalisées, et jusqu'à l'espace fenêtre, vous trouvez cela.
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 Z proche à 0 et la valeur Z extrême à n. Donc, le + Z va loin du spectateur.
C'est un système de coordonnées pour gaucher. Oui, vous pouvez changer le test de profondeur de GL_LESS à GL_GREATER et changer le glDepthRange de [0, 1] à [1, 0]. Mais l'état par défaut d'OpenGL est de travailler dans un gaucher système de coordonnées. Et aucune des transformations nécessaires pour accéder à l'espace fenêtre à partir de l'espace clip n'annule le Z. Donc, l'espace clip, la sortie du vertex (ou de la géométrie) est un espace gaucher (un peu. C'est un espace homogène 4D, donc il est difficile de cerner la neutralité).
Dans le pipeline à fonction fixe, les matrices de projection standard (produites par glOrtho, glFrustum et similaires) se transforment toutes d'un espace droitier en un gaucher une. Ils inversent le sens de Z; il suffit de vérifier les matrices qu'ils génèrent. Dans l'espace des yeux, + Z se déplace vers le spectateur; dans l'espace de 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.
C'est de l'histoire pure. Dans les temps anciens, les premiers programmeurs de graphismes rupestres considéraient la surface de visualisation du moniteur (télétype? Type de pierre?) Comme du papier quadrillé. En mathématiques et en ingénierie, les conventions habituelles pour tracer des points de données sur du papier millimétré sont les suivantes: x = droite, y = haut. Puis un jour, environ une semaine après l'invention de la roue en silicone, quelqu'un a pensé au graphisme 3D. Lorsque l'ampoule de cette idée clignote au-dessus de leur tête, pour une raison quelconque, ils choisissent d'ajouter Z = loin du spectateur. (Aïe, ma main droite me fait mal juste imaginer ça.)
Ils n'avaient aucune idée qu'un jour leurs descendants lointains deviendraient des ingénieurs, des scientifiques, de beaux artistes, des artistes commerciaux, des animateurs, des concepteurs de produits, etc. et trouveraient les graphiques 3D utiles. Toutes ces belles personnes modernes utilisent des systèmes de coordonnées droitiers pour être cohérents entre eux et avec les textes mathématiques et les conventions de physique les plus établis.
Il est insensé de baser le système de coordonnées 3D sur la surface d'affichage. C'est le modèle qui compte - les triangles et les polygones et les avions décrivant une maison, une chaise, un ogre vert en surpoids ou une galaxie. De nos jours, nous concevons et modélisons tous dans des systèmes XYZ pour droitiers, et nous le faisons en termes de monde du modèle, avant même de penser à la façon dont il sera rendu. La caméra est ajoutée à un moment donné, peut-être conçue pour voler de manière folle, et c'est une infrastructure invisible qui convertit le modèle en pixels qui, dans ses entrailles, doivent se tortiller avec des transformations de système coordonnées.
Pour ajouter à la confusion, certaines bibliothèques graphiques reconnaissent que les écrans CRT numérisent l'image de haut en bas, et ont donc Y = bas. Ceci est utilisé encore aujourd'hui dans tous les systèmes de fenêtrage et les gestionnaires de fenêtres - X11, fvwm, gtk +, API Win31, etc. Ce besoin ne concerne que les programmeurs d'applications et les concepteurs d'interfaces graphiques.
Ils sont tous deux essentiellement équivalents, car l'un peut être facilement transformé dans l'autre. Le seul avantage que je peux trouver pour le système pour gauchers est: comme les objets sont plus éloignés de l'observateur, dans n'importe quelle direction (x, y ou z), la distance est une valeur plus élevée. Mais je ne sais pas si c'est pourquoi Microsoft a choisi l'un plutôt que l'autre.
POV-Ray utilise également un système couloir gaucher.
Le développeur principal de DirectX (et Direct3D) Alex St. John a récemment commenté cela. Dans un article sur l'histoire de Direct3D, il a écrit:
On m'a [...] demandé de choisir une solution pour l'API Direct3D. J'ai choisi un système de coordonnées pour gaucher, en partie par préférence personnelle . [...] c'était un choix arbitraire .
Source: http://www.alexstjohn.com/WP/2013/07/22/the-evolution-of-direct3d/
La chose à comprendre est qu'une énorme quantité de temps programmeur a été gaspillée lors de la conversion entre les systèmes de coordonnées gauchers et droitiers, et encore plus de temps programmeur a été gaspillé en se souvenant du système nécessaire à un instant donné.
Tout cela a disparu lorsque les systèmes de coordonnées pour droitiers sont devenus la norme de l'industrie.
Il existe déjà suffisamment de systèmes de coordonnées couramment utilisés, sans doubler le nombre en introduisant une question de neutralité. Voir Minkler & Minkler, "Systèmes de coordonnées aérospatiales et transformations" . Si vous êtes dans le domaine des coordonnées aérospatiales, par exemple simulation de vol, vous [~ # ~] avez besoin de [~ # ~] ce livre.
Je suppose que Microsoft n'avait personne sur le projet DirectX qui savait quoi que ce soit sur les normes de l'industrie, ne se rendait pas compte qu'il existait une norme de l'industrie et pensait que cela n'avait pas d'importance.
L'autre possibilité, qu'ils savaient que les systèmes pour droitiers étaient la norme de l'industrie, et qu'ils ont délibérément créé DirectX pour gauchers, afin de rendre difficile la conversion du code utilisant DirectX pour utiliser OpenGL à la place, n'est pas prise en considération. Si je découvrais que tel était bien le cas, il me faudrait entreprendre une nouvelle et probablement courte carrière de meurtrier à Redmond.
La vraie réponse à la gaucherie précoce de Direct3D est beaucoup moins sinistre que certains d'entre vous spéculent. DirectX a fait ses débuts lorsque Microsoft a acheté RenderMorphics en 1995.
A cette époque, le texte graphique standard utilisé dans les bureaux de RenderMorphics était "Principles of Interactive Computer Graphics" par Newmann et Sproul qui fait tout en utilisant les coordonnées gauchers. C'est le même livre que j'ai utilisé au collège. En regardant le code D3D, vous pouvez même les voir en utilisant des noms de variables qui correspondent aux équations du livre.
Ce n'est pas une conspiration de Microsoft. La décision a été prise avant même que Microsoft entre en scène.
Pour tous ceux qui pensent qu'il n'y a aucun avantage à la droite ou à la gauche, vous avez absolument tort. La droiture des systèmes de coordonnées cartésiennes provient de la définition du produit vectoriel croisé. Pour les vecteurs de base XYZ u, v et w, w = u X v.
Cette définition est fondamentale pour les mathématiques vectorielles, le calcul vectoriel et une grande partie de la physique. Supposons que vous essayez de simuler des interactions électromagnétiques. Vous avez un vecteur de champ magnétique, M, et une particule chargée se déplaçant dans ce champ avec la vitesse v. De quelle façon la charge accélère-t-elle? Facile - en direction de M X v. Sauf qu'un idiot pensait que ce serait amusant de rendre votre système d'affichage gaucher, donc il accélère dans le sens de -M X v.
Fondamentalement, toute interaction physique entre deux quantités de vecteurs est définie comme droitière, et donc chaque fois que vous avez besoin de simuler cette interaction, vous feriez mieux d'espérer que votre système graphique est droitier ou vous devrez vous rappeler de faire le tour des signes négatifs dans tous vos calculs.
Ni l'un ni l'autre n'est finalement meilleur que l'autre - vous mappez des coordonnées 3D sur une surface 2D, de sorte que la troisième dimension (qui rend les choses en 3D) peut être choisie arbitrairement, pointant vers le spectateur ou vers l'écran. Vous allez de toute façon faire passer les choses dans une matrice 4x4, il n'y a donc aucune raison technique de choisir l'une plutôt que l'autre. Fonctionnellement, on pourrait soutenir:
- Il existe un consensus assez large en informatique et dans d'autres domaines pour que l'axe X soit exécuté de gauche à droite (les aviations étant apparemment une exception notable).
- En mathématiques, l'axe Y pointe vers le haut. (Aussi, c'est là que vont les bulles).
- Sur les écrans d'ordinateur, l'axe Y pointe vers le bas (parce que c'est ainsi que fonctionnent les écrans CRT, et aussi parce que c'est l'ordre dans lequel la plupart des scripts humains organisent les lignes).
- Lorsque vous regardez le côté "visible" d'une surface dans le plan X/Y, la normale doit pointer vers le spectateur (comme lorsque vous regardez des images satellite; la "hauteur au-dessus du niveau de la mer" pointe vers le satellite, pas vers le centre de la Terre). Étant donné que la normale pour le plan X/Y est le vecteur de l'axe Z, il s'ensuit que l'axe Z doit également pointer vers la visionneuse.
- Lorsque vous regardez des images 3D sur un écran d'ordinateur, les points les plus éloignés de la visionneuse doivent avoir un composant Z plus grand. Par conséquent, l'axe Z doit pointer vers l'écran.
Conclusion: Il y a un certain consensus pour l'axe X, mais pour les deux autres, les deux directions peuvent être défendues, donnant deux configurations pour droitiers et deux pour gauchers, et elles ont toutes un sens.
Fait intéressant.
Direct3D (pas DirectX - DirectX couvre également l'entrée, le son, etc.) en fait ne fait pas avoir un système de coordonnées pour gaucher.
Il est parfaitement capable de prendre en charge les systèmes RH et LH. Si vous regardez dans la documentation du SDK, vous verrez des fonctions telles que D3DXMatrixPerspectiveFovLH et D3DXMatrixPerspectiveFovRH. Les deux fonctionnent, et les deux produire une matrice de projection qui peut être utilisée avec succès avec le système de coordonnées de votre choix. Enfer, vous pouvez même utiliser la colonne majeure dans Direct3D si vous le souhaitez; c'est juste une bibliothèque de matrice logicielle et vous n'êtes pas obligé de l'utiliser. d'autre part, si vous souhaitez l'utiliser avec OpenGL, vous constaterez qu'il fonctionne également parfaitement avec OpenGL (ce qui est peut-être la preuve définitive de l'indépendance de la bibliothèque de matrices par rapport à Direct3D lui-même).
Donc, si vous souhaitez utiliser un système RH dans votre programme, utilisez simplement la version -RH de la fonction. Si vous souhaitez utiliser un système LH, utilisez la version -LH. Direct3D s'en fiche. De même, si vous souhaitez utiliser un système LH dans OpenGL - juste glLoadMatrix une matrice de projection LH. Rien de tout cela n'est important et ce n'est pas du tout l'énorme problème que vous voyez parfois apparaître.
Fournissant ceci comme matériel supplémentaire à ma réponse précédente ici. D'après une ancienne spécification OpenGL des années 1990:
OpenGL ne force ni gaucher ni droitier sur aucun de ses systèmes de coordonnées.
(source: http://www.opengl.org/documentation/specs/version1.2/opengl1.2.1.pdf ).
Donc, puisque ni D3D ni OpenGL n'appliquent la neutralité, la vraie question est: pourquoi les gens voient-ils cela comme quelque chose d'important?
Il n'y a aucun avantage technique à la neutralité, c'est complètement arbitraire. Les deux fonctionnent bien tant que vous êtes cohérent.
En raison des avantages de la cohérence, on devrait idéalement simplement "utiliser ce que tout le monde utilise" - mais c'est assez difficile dans de nombreux cas, car il n'y a pas non plus de convention "privilégiée" écrasante dans la pratique: les deux mains sont largement utilisées. Au mieux, il existe une certaine cohérence au sein de certaines communautés (par exemple OpenGL).
Je pense donc que la réponse de base à cette question est: ils ont choisi ce qu'ils ont choisi parce que cela leur semblait juste (sans aucun doute, ils avaient une certaine expérience antérieure avec cette neutralité) et il y avait peu de raisons de ne pas le faire.
En fin de compte, cela ne fait aucune différence: quiconque souhaite sérieusement échanger des actifs/du code avec d'autres systèmes/communautés devra de toute façon être prêt à gérer la conversion de la main-d'œuvre, car c'est une réalité de la vie graphique 3D.