DirectXが左手座標系を使用するのはなぜですか？

Stack Overflowに投稿することを検討しましたが、この問題に関するMicrosoftの選択に対する合理的な技術的説明を考えることができないため、質問はあまりにも主観的であると思います。しかし、この質問は非常に長い間私を悩ませており、私のプロジェクトの1つで問題が発生し続けており、実際にこれを説明する試みを見たことはありません。

OpenGLは、右手座標系を使用します。世界座標系の+ Z部分は、視聴者に向かって伸びます。

DirectXは、世界の+ Z部分は座標左手系が延び使用に見る人から離れて、スクリーン。

私はGlide APIを使用したことがないため、どのように機能したのかわかりませんが、収集できるものから、左利きのシステムも使用しています。

これには技術的な理由がありますか？そうでない場合、座標系の特定の利き手に概念的な利点はありますか？なぜ一方が他方を選択するのでしょうか？

私はこれが古い投稿であることを知っていますが、この投稿が参照されており、選択した回答のトーンが嫌いだと思いました。

だから私は少し調査をしました！

1. DirectXは古い。1995年に最初にリリースされたとき、世界にはNvidiaとATI、DirectX対OpenGL よりもはるかに多くのものがありました。それは15年以上です、人々。
2. 3dfx Interactiveの Glide（当時のDirectXの競合他社の1つ。OpenGLは当時のゲーム用ではありませんでした）は、左手座標系を使用していました。
3. POV-RayおよびRenderMan（Pixarのレンダリングソフトウェア）も、左手座標系を使用します。
4. DirectX 9+は両方の座標系で機能します。
5. WPFとXNA（シーンでDirectXで動作する）はどちらも右手座標系を使用します。

これから、いくつかのことを推測できます。

• 業界標準は、人々が好むほど標準ではありません。
• Direct3Dは、誰もが独自の方法で作業を行ったときに開発されたものであり、開発者はおそらくそれをよく知らなかったでしょう。
• 左利きはオプションですが、DirectXの世界では慣習的です。
• 慣習は完全に消滅するため、DirectXは左利きでしか機能しないと誰もが考えています。
• マイクロソフトは最終的に学習し、作成した新しいAPIの標準に従いました。

したがって、私の結論は次のようになります。

彼らが選択しなければならなかったとき、彼らは標準を知らず、「他の」システムを選択しました、そして、他のみんなはただ乗りに行きました。 怪しげなビジネスはありません。下位互換性がMicrosoftのゲームの名前であるため、運が悪かっただけの設計上の決定です。

誰も言及していないことに驚いています：OpenGLは左手座標系でも動作します。少なくとも、シェーダーを使用していて、デフォルトの深度範囲を使用している場合はそうなります。

固定機能パイプラインを破棄すると、「クリップスペース」を直接処理します。OpenGL仕様は、クリップ空間を4D同次座標系として定義しています。正規化されたデバイス座標を介してウィンドウスペースまで変換を実行すると、これがわかります。

ウィンドウスペースは、ウィンドウのピクセルのスペースにあります。原点は左下隅にあり、+ Yが上がり、+ Xが右になります。これは、右手座標系に非常によく似ています。しかし、Zはどうですか？

デフォルトの深度範囲（glDepthRange）は、ニアZ値を0に設定し、ファーZ値を1に設定します。したがって、+ Zはビューアーから遠ざかります。

それは左利きの座標系です。はい、深度テストをGL_LESSからGL_GREATERに変更し、glDepthRangeを[0、1]から[1、0]に変更できます。ただし、OpenGL のデフォルトの状態は、左手座標系で動作することです。そして、クリップスペースからウィンドウスペースに到達するために必要な変換はどれもZを無効にしません。したがって、クリップスペース、頂点（またはジオメトリ）シェーダーの出力は左手スペース（ちょっと。4D同次空間です。利き手を特定するのは難しいです）。

固定機能パイプラインでは、（glOrtho、glFrustum等製）標準射影行列は、すべてに右利きの空間から変換左利き 1。Zの意味を反転させます。生成する行列を確認するだけです。目の空間では、+ Zは視聴者に向かって移動します。投影後の空間では、移動します。

Microsoft（およびGLide）は、単に投影行列で否定を実行することに煩わされていなかったと思われます。

それは純粋な歴史です。古代の洞窟グラフィックプログラマーは、モニター（テレタイプ？ストーンタイプ？）の表面を2次元のグラフ用紙と見なしていました。数学と工学では、グラフ用紙にデータポイントをプロットするための通常の規則は、x = right、y = upです。ある日、シリコンホイールの発明から約1週間後、誰かが3Dグラフィックスについて考えました。このアイデアのろうそく球が頭の上で点滅したとき、何らかの理由で、彼らは視聴者から離れてZ =を追加することを選択します。（痛い、それを想像するだけで右手が痛い。）

彼らはいつか彼らの子孫がエンジニア、科学者、素晴らしい芸術家、商業芸術家、アニメーター、製品デザイナーなどになり、3Dグラフィックスが役に立つとは思いもしませんでした。これらの優れた現代人はすべて、右手座標系を使用して、相互に一貫性を持たせ、より確立された数学のテキストと物理学の慣習に従っています。

表示面に基づいて3D座標系を作成するのは愚かです。重要なのはモデルです-家、椅子、太りすぎの緑の鬼または銀河を表す三角形と多角形と平面。今日、私たちは皆、右手系XYZシステムですべてのものを設計およびモデル化し、モデルの世界の観点からそうします。カメラはある時点で追加され、おそらく狂ったように飛び回るように作られており、モデルをピクセルに変換する目に見えないインフラストラクチャであり、腸内で調整されたシステム変換で動き回る必要があります。

混乱を助長するために、一部のグラフィックライブラリは、CRTが画像を上から下にスキャンすることを認識しているため、Y = downになっています。X11、fvwm、gtk +、Win31 APIなど、すべてのウィンドウシステムおよびウィンドウマネージャーで現在でも使用されています。ClutterやBerylなどの新しい3D GUIシステムがZをどのように処理するかは、3Dグラフィックスモデリングとは別の問題です。これが必要なのは、アプリケーションプログラマーとGUIデザイナーのみです。

どちらも簡単に変換できるため、どちらも本質的に同等です。左利きのシステムで私が見つけることができる唯一の利点は、オブジェクトが観測者から遠ざかるにつれて、あらゆる方向（x、y、またはz）で、距離がより高い値になることです。しかし、これがMicrosoftが他を選択した理由であるかどうかはわかりません。

POV-Rayは左利きのコリドーシステムも使用します。

DirectX（およびDirect3D）Alex St. Johnの主任開発者は、最近コメントしました。彼はDirect3Dの歴史に関する記事で次のように書いています。

私[...]は、Direct3D APIの利き手を選択するように求められました。個人的な好みから、左手座標系を選びました。[...]それはarbitrary意的な選択でした。

ソース：http : //www.alexstjohn.com/WP/2013/07/22/the-evolution-of-direct3d/

理解すべきことは、左手系と右手系の座標系の変換に膨大な量のプログラマー時間が浪費されており、特定の瞬間にどのシステムが必要かを思い出してさらに多くのプログラマー時間が浪費されていることです。

これらはすべて、右手座標系が業界標準になったときになくなりました。

利き手問題を導入して数を倍にすることなく、すでに一般的に使用されている十分な座標系があります。Minkler＆Minkler、 "Aerospace Coordinate Systems and Transformations"を参照してください。航空宇宙座標ビジネスに携わっている場合、たとえばフライトシミュレーションを行う場合は、その本が必要です。

私の推測では、MicrosoftはDirectXプロジェクトに業界標準について何も知らず、業界標準があることを認識せず、それが重要ではないと考えていたのではないでしょう。

もう1つの可能性は、右利きのシステムが業界標準であることを知っていて、DirectXを代わりにOpenGLを使用するようにコードを変換することを人々が困難にするように、意図的にDirectXを左利きにしたことです。これが実際に事実であることを発見した場合、レドモンドのx殺人者としての、おそらく短命の新しいキャリアに着手する必要があると思います。

右利きにも左利きにも利点がないと思う人にとって、あなたは絶対に間違っています。デカルト座標系の右利きは、ベクトル外積の定義に由来します。XYZ基底ベクトルのためにu、vそしてw、w = u X v。

この定義は、ベクトル数学、ベクトル計算、および多くの物理学の基本です。電磁相互作用をシミュレートしようとしているとします。磁場ベクトル、Mおよびその場を速度で移動する荷電粒子がありますv。充電はどちらの方法で加速しますか？簡単-の方向にM X v。一部のばかがディスプレイシステムを左利きにするのが楽しいと思ったのを除いて、の方向に加速し-M X vます。

基本的に、2つのベクトル量の間の物理的な相互作用は右利きとして定義されているため、その相互作用をシミュレートする必要があるときはいつでも、グラフィックシステムが右利きであるか、すべての数学。

Direct3Dの初期の左利きに対する本当の答えは、一部の人が推測しているよりも不吉ではありません。DirectXは、Microsoftが1995年にRenderMorphicsを購入したときに始まりました。

当時、RenderMorphicsオフィスで使用されていた標準のグラフィックテキストは、NewmannとSproulによる「Principles of Interactive Computer Graphics」であり、左手座標を使用してすべてを実行していました。大学で使ったのと同じ本です。D3Dコードを見ると、本の方程式と一致する変数名を使用してそれらを見ることができます。

マイクロソフトの陰謀ではありません。この決定は、Microsoftが登場する前に行われました。

最終的にどちらも他のものより優れているわけではありません-3D座標を2Dサーフェスにマッピングしているので、3Dディメンション（実際に3Dを実現）を任意に選択して、ビューアーまたは画面に向けることができます。とにかく4x4マトリックスを使用するので、どちらかを選択する技術的な理由はありません。機能的には、次のように主張できます：

• X軸を左から右に実行するためのコンピューティングおよびその他のフィールドには、かなり広いコンセンサスがあります（航空は明らかに注目すべき例外です）。
• 数学では、Y軸は上を向いています。（また、泡はどこへ行くのか）。
• コンピューターのディスプレイでは、Y軸が下を向いています（これがCRT画面の動作方法であり、また、ほとんどの人間のスクリプトが行を並べる順序でもあるためです）。
• X / Y平面で表面の「見える」側を見るとき、法線は視聴者の方を向く必要があります（衛星映像を見るときなど、「海抜の高さ」は衛星ではなく、地球の中心）。X / Y平面の法線はZ軸ベクトルであるため、Z軸もビューアの方向を向く必要があります。
• コンピューター画面で3D画像を見るとき、ビューアーから遠いポイントはより大きなZコンポーネントを持つ必要があります。したがって、Z軸は画面を指す必要があります。

結論：X軸についてはある程度のコンセンサスがありますが、他の2つについては、両方向について議論することができ、2つの右利きの構成と2つの左利きの構成が得られ、それらはすべて理にかなっています。

興味深い事実。

Direct3D（DirectX ではなく、DirectXも入力、サウンドなどをカバーします）には、実際には左手座標系がありません。

RHシステムとLHシステムの両方を完全にサポートできます。SDKドキュメントを見ると、D3DXMatrixPerspectiveFovLH や D3DXMatrixPerspectiveFovRH などの関数が表示されます。両方とも機能し、選択した座標系で正常に使用できる投影行列を生成します。地獄、あなたが望むならDirect3Dで列メジャーを使用することさえできます。これは単なるソフトウェアマトリックスライブラリであり、使用する必要はありません。一方、OpenGLで使用したい場合は、OpenGLでも完全に機能することがわかります（おそらく、Direct3D自体からのマトリックスライブラリの独立性の決定的な証拠です）。

したがって、プログラムでRHシステムを使用する場合は、-RHバージョンの関数を使用するだけです。LHシステムを使用する場合は、-LHバージョンを使用します。Direct3Dは気にしません。同様に、OpenGLでLHシステムを使用する場合は、glLoadMatrixとLH射影行列だけを使用します。このようなものはどれも重要ではありませんし、時にはそれが判明している巨大な問題の近くにはありません。

どちらの利き手に技術的な利点はありません、それは完全に任意です。一貫している限り、両方とも正常に機能します。

一貫性の利点のため、理想的には「他の人が使用しているものを使用する」べきですが、実際には圧倒的に「好ましい」慣習がないため、多くの場合、それは非常に困難です。せいぜい、特定のコミュニティ（OpenGLなど）内には一貫性があります。

ですから、この質問に対する基本的な答えは、彼らは自分が選んだものを選んだのは、それが正しいと感じたからだと思います（間違いなく、その利き手についての以前の経験があったのです）。

最終的にはほとんど違いはありません。他のシステム/コミュニティと真剣にアセット/コードを交換したい人は、3Dグラフィックスの現実であるため、とにかく利き手変換に対処する準備をしなければなりません。

これを以前の回答の補足資料としてここに提供します。1990年代の古いOpenGL仕様から：

OpenGLは、どの座標系でも左利きまたは右利きを強制しません。

（ソース：http : //www.opengl.org/documentation/specs/version1.2/opengl1.2.1.pdf）。

それで、D3DもOpenGLも利き手を強制しないので、本当の質問は次のとおりです。

私は言って嫌いですが、座標セットの「手」は実際には主観的です-それはあなたが物を見ていると想像する方法に依存します。OpenGLキューブマップ仕様の例：キューブの内側が外を見ると想像すると、座標系は左利きで、外側から見ると右利きだと思います。この単純な事実は無限の悲嘆を引き起こします。数値的に正しい答えを得るためには、ローカルで実際にどの仮定を行うかは関係ありませんが、すべての仮定が一貫している必要があります。

OpenGLの仕様は公式には「利き手に中立」であり、この問題を回避するために、つまりプログラマーにそれを先送りにするために、かなりの長さをしています。ただし、目の座標とクリップの座標との間には「手の変化」があります。モデルと目の空間では、クリップとデバイスの空間では外を見ています。私はこの偶然の偶然の合併症の結果に常に苦労しています。

クロス積は、一対のベクトルから確実に右利きまたは左利きの3D座標系を生成できるため、私たちの友です。しかし、どちらのハンドかは、これらのベクトルのどれを「X」と呼ぶかに依存します。

そもそも業界標準は間違っていると言える

座標の業界標準は、実際に人々がすべてを水平面である机の上に描くときの机座標から来ました。Xは左/右、Yは前/後なので、Zを上向きにし、右手座標系が生まれました。

しかし、ご存知のように、モニター画面で使用しているのは垂直面です。Xはまだ左/右ですが、Yは代わりに上下です。

それでは、右手座標系は何を引き起こすでしょうか？これにより、+ Zが後方に、-Zが前方になります。これは一体何ですか？上が+、下が-右が+、左が-しかし前方は-、後方は+ ??? キャラクターが3Dの世界で走っているゲームを作るのはとても愚かですが、進むためにzをマイナスする必要があります。だからこそ、ゲームプログラマーはDirectXを最も高く評価しています。

机から来た標準をつかんでモニターで使用することは、最初から多くのレベルで非常に間違っています。そして、OpenGLとIndustryが間違っていることを認めるべきです。彼らはそれが彼らを快適にするだろうと思うものだけを使用しますが、彼らは間違っています。