私はOpenGLSuperbibleFifth Editionを読んでいて、彼らは独自のクラスを介してスタックを使用することについて話し合っています。それはすべて素晴らしいことですが、彼らはマトリックススタックが非推奨になったと述べています。なぜそれらは廃止されたのですか、そして人々はそれらの代わりに何を使用しますか?
4 に答える
その理由は技術的なものではなく政治的なものであり、2000年代初頭にさかのぼります。
OpenGL 3は、下位互換性を破ることをいとわない最初のバージョンでした。デザイナーは、シェーダーについてすべてを知っていて、独自のマトリックスコードを作成した、エキスパートユーザー、ゲームプログラマー、およびハイエンドの視覚化コーダー向けのAPIを作成したいと考えていました。その意図は、OpenGL3APIが実際のハードウェアと非常に厳密に一致する必要があるということでした。(OpenGL 1/2でも、マトリックススタックは通常、GPUではなくCPU側に実装されていました。)
ゲームエンジンプログラマーの観点からは、これはより優れていました。とにかく、2、3年ごとに新しいゲームエンジンを開発する必要がある場合、古いコードを破棄することの重要な点は何ですか?
この設計プロセスの結果は、OpenGL3/4コアプロファイルです。
「新世代」のOpenGLが発表されると、大学や企業のあまり専門家ではないコーダーは全員、彼らが失敗することに気づきました。これらは(私のような)3Dグラフィックスを教えたり、研究やデザインのためのユーティリティプログラムを書いたりする人々です。プレーンなアンビエント拡散スペキュラーよりも高度な照明は必要ありません。多くの場合、さまざまなソースからのコードを一緒に混合する必要があります。これは、OpenGL 2で提供されているものとまったく同じマトリックス、ライティング、テクスチャリングの規則を使用している場合にのみ簡単です。
また、聞いたことはありますが、確認することはできません。大手CAD / CAM企業も、自分たちも失敗することに気づきました。有料の(そして高額の:QuadroとGeForce、またはFireGLとRadeonの価格を比較する)顧客がいる場合、10年間の開発から200万行のコードを破棄することはできません。
そのため、NVIDIAとATIの両方が、可能な限り古いAPIをサポートすると発表しました。
このプレッシャーの結果が互換性プロファイルです。そして、OpenGL ARBは、誰もがコアプロファイルに切り替えてほしいと思っているのに、それは起こらないことに気付いたようです。OpenGL4のテッセレーションシェーダーの拡張仕様を読んでください。GL_PATCHESはglBeginで動作すると記載されています。
マトリックススタック(および残りのマトリックス関数)は、コアプロファイルでのみ非推奨になりました。互換性プロファイルでは、引き続きそれらを使用できるはずです。
私の見解では、ほとんどのエンジン/フレームワークには、マトリックスをシェーダーに送信するためのカスタムの数学コードとシェーダーの統一スタイルがあるため、削除されました。
単純なプログラム/チュートリアルの場合でも、他のものを使用して検索するのは非常に不便です。
私は使用することをお勧めします:
- glm(http://glm.g-truc.net/)
- 非常に単純な数学ライブラリ(vsml)
なぜそれらは非推奨になったのですか
誰も実際にOpenGLプログラムでそれを使用しなかったからです。物理シミュレーションを例にとってみましょう。とにかく、すべてのオブジェクト配置が4×4マトリックスとして物理システムに保存されます。だからあなたはそれを使うでしょう。可視オブジェクト決定およびアニメーションシステムについても同じことが言えます。いずれにせよ、これらはすべて行列演算を実装する必要があるため、OpenGLでこれを使用することは、ほとんどの場合、既存の行列が単純にに入れられるため、かなり冗長glLoadMatrix
です。
そして人々は彼らの代わりに何を使うのでしょうか?
彼らが以前に使用したもの:彼らのアニメーションシステム、物理シミュレーター、シーングラフなど。
私にとっての最初の主な理由は、プログラム可能なシェーダー(openglの第3バージョン以降は必須)の登場により、シェーダーに自動的に転送されたGL_PROJECTIONやGL_MODELVIEWなどのすべての変数がシェーダーから削除されていることです。 、したがって、ユーザーはシェーダーで使用するために独自のマトリックスを定義する必要があります。ユニフォーム関数を使用してマトリックスを手動で送信する必要があるため、固定変数はもう必要ありません。