Stack Overflowに投稿することを検討しましたが、この問題についてMicrosoftが選択するための合理的な技術的説明を考えることができないため、質問は主観的すぎると思います。しかし、この質問は長い間私を悩ませてきました、そして問題は私のプロジェクトの1つで起こり続けます、そして私はこれを説明しようとする試みを実際に見たことがありません:
OpenGL は右手座標系を使用し、世界座標系の+ Z部分はビューアに向かって伸びます。
DirectX 左手系を使用し、世界座標の+ Z部分がinto画面に伸び、ビューアから離れます。 。
Glide API を使用したことがないので、どのように機能するかわかりませんが、収集できるものから、左利きのシステムも使用しています。
これには技術的な理由がありますか?そうでない場合、座標系の特定の利き手に概念上の利点はありますか?なぜ一方が他方を選ぶのでしょうか?
私はこれが古い投稿であることを知っていますが、この投稿が参照されているのを見て、選択した回答の口調が嫌いです。
だから私は少し調査をしました!
これから、私はいくつかのことについて推測することができます:
したがって、私の結論は次のようになります。
彼らが選択しなければならなかったとき、彼らは標準を知らず、「他の」システムを選択し、そして他の誰もがただ乗りに行きました。不快なビジネスではなく、後方互換性がマイクロソフトのゲームの名前であるため、運ばれた不運な設計決定に過ぎません。
OpenGLが左手系の座標系でも動作することに誰も触れていないことに驚いています。少なくとも、シェーダーで作業していて、デフォルトの深度範囲を使用している場合はそうです。
固定関数パイプラインを破棄すると、「クリップスペース」を直接処理します。 OpenGL仕様では、クリップ空間を4D同次座標系として定義しています。変換を正規化されたデバイス座標をたどってウィンドウスペースまでたどると、これがわかります。
ウィンドウスペースは、ウィンドウのピクセルのスペースにあります。原点は左下隅にあり、+ Yが上がり、+ Xが右になります。これは、右手系の座標系とよく似ています。しかし、Zはどうでしょうか。
デフォルトの深度範囲(glDepthRange)は、Zの近くの値を0に設定し、Zの遠い値をoneに設定します。したがって、+ Zはビューアーからawayになります。
それは左手座標系です。はい、深度テストをGL_LESSからGL_GREATERに変更し、glDepthRangeを[0、1]から[1、0]に変更できます。しかし、OpenGLのdefault状態は、左利きで動作します座標系。そして、クリップ空間からウィンドウ空間に到達するために必要な変換はどれも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設計者のみに関係します。
DirectX(およびDirect3D)のリード開発者Alex St. John最近それについてコメントしました。 Direct3Dの歴史に関する記事で彼は次のように書いています。
私はDirect3D APIの利き手を選択するように求められました。 個人的な好みから一部左手座標系を選択しました。 [...]これは任意の選択でした。
出典: http://www.alexstjohn.com/WP/2013/07/22/the-evolution-of-direct3d/
理解する必要があるのは、左手座標系と右手座標系の間で変換するのに膨大な量のプログラマー時間が無駄になり、特定の瞬間にどのシステムが必要であるかを覚えているプログラマー時間がさらに無駄になったことです。
右手系の座標系が業界標準になったとき、そのすべてがなくなりました。
利き手の質問を導入して数を2倍にすることなく、すでに一般的に使用されている十分な座標系があります。 Minkler&Minkler、 "Aerospace Coordinate Systems and Transformations" を参照してください。航空宇宙コーディネート事業をしている場合は、フライトシミュレーション、あなた[〜#〜]が必要です[〜#〜]その本。
私の推測では、Microsoftは業界標準について何も知らないDirectXプロジェクトに誰もいなかったし、業界標準が存在することを知らなかったし、それが問題ではないと考えたのだ。
右利きのシステムが業界標準であることを知っていて、DirectXを意図的に左利きにして、DirectXを使用するコードをOpenGLを使用するように変換するのを困難にするというもう1つの可能性は考慮されていません。私がこれが実際に事実であることを発見したとしたら、レドモンドで斧殺人犯として、おそらくは短命のキャリアに乗り出す必要があると思います。
Direct3Dの初期の左利きに対する本当の答えは、一部の人が推測しているよりもはるかに不吉ではありません。 DirectXは、Microsoftが1995年にRenderMorphicsを買収したときに始まりました。
当時、RenderMorphicsのオフィスで使用されている標準のグラフィックステキストは、左手座標を使用してすべてを行うNewmannとSproulによる「Principles of Interactive Computer Graphics」でした。私が大学で使ったのと同じ本です。 D3Dコードを見ると、本の方程式に一致する変数名を使用してそれらを確認することもできます。
マイクロソフトの陰謀ではありません。この決定は、Microsoftが登場する前に行われました。
右利きまたは左利きには利点がないと考えるすべての人にとって、あなたは絶対に間違っています。デカルト座標系の右利きは、ベクトル外積の定義に由来します。 XYZ基底ベクトルの場合、u
、v
およびw
、w = u X v
。
この定義は、ベクトル数学、ベクトル計算、および多くの物理学の基本です。電磁相互作用をシミュレートしようとしていると仮定します。磁場ベクトルM
があり、その粒子内を速度v
で移動する荷電粒子があります。充電はどのように加速しますか?簡単-M X v
の方向。一部のばか者がディスプレイシステムを左利きにするのは楽しいと思ったので、-M X v
の方向に加速します。
基本的に、2つのベクトル量の間の物理的な相互作用は右利きとして定義されるため、その相互作用をシミュレートする必要があるときはいつでも、グラフィックスシステムが右利きであることを望みます。あなたのすべての数学。
3D座標を2Dサーフェスにマッピングするので、最終的にはどちらも他より優れています。3番目の次元(実際に3Dにする)は、ビューアまたは画面に向けて任意に選択できます。とにかく4x4のマトリックスを使用するので、どちらか一方を選択する技術的な理由はありません。機能的には、次のように主張できます。
結論:X軸についてはある程度のコンセンサスがありますが、他の2つについては、両方向について議論することができ、2つの右手と2つの左手構成が得られ、それらはすべて意味があります。
興味深い事実。
Direct3D(DirectXではない-DirectXは入力、サウンドなどもカバーします)しないでください左手座標系を持っています。
RHとLHシステムの両方を完全にサポートできます。SDKのドキュメントを見ると、D3DXMatrixPerspectiveFovLH and D3DXMatrixPerspectiveFovRHなどの関数が表示されます。両方とも機能し、両方とも機能します。選択した座標系で正常に使用できる射影行列を生成します。必要に応じて、Direct3Dで列メジャーを使用することもできます。これは単なるソフトウェアマトリックスライブラリであり、使用する必要はありません。一方、OpenGLで使用する場合は、OpenGLでも完全に機能することがわかります(これは、おそらく、Direct3D自体からのマトリックスライブラリの独立性の決定的な証拠です)。
したがって、プログラムでRHシステムを使用したい場合は、関数の-RHバージョンを使用してください。 LHシステムを使用する場合は、-LHバージョンを使用します。Direct3Dは関係ありません。同様に、LH OpenGL-ちょうどglLoadMatrix an LH射影行列。これは重要なことではなく、時々それが成り立つことがわかっている巨大な問題のどこにもありません。
これを私の以前の回答の補足資料としてここに提供します。 1990年代の古いOpenGL仕様から:
OpenGLは、どの座標系でも左利きまたは右利きを強制しません。
(ソース: http://www.opengl.org/documentation/specs/version1.2/opengl1.2.1.pdf )。
したがって、D3DもOpenGLも利き手を強制しないため、本当の問題は次のとおりです。なぜ人々はこれを大したことと見なすのですか?
どちらの利き手にも技術的な利点はなく、完全に恣意的です。あなたが一貫している限り、どちらもうまくいきます。
一貫性の利点のため、理想的には「他の全員が使用しているものを使用する」だけですが、実際には圧倒的に「推奨される」慣例がないため、これは多くの場合非常に困難です。両方の利き手が広く使用されています。せいぜい、特定のコミュニティ(OpenGLなど)内にはある程度の一貫性があります。
ですから、私はこの質問に対する基本的な答えは次のとおりだと思います。彼らは自分が選んだものを選んだのは、それが正しいと感じた(間違いなく彼らはその利き手で以前にいくつかの経験をした)からで、そうしない理由はほとんどありません。
結局、それはほとんど違いがありません。アセット/コードを他のシステム/コミュニティと真剣に交換したい人は、いずれにせよ、利き手変換に対処する準備ができているはずです。