マトリックス スタック、gluPerspective()、glMatrixMode() などの非推奨の固定機能パイプライン機能を混在させる傾向があるのはなぜですか。また、これが手動で行われ、ユニフォームとして GLSL に押し込まれることを意図している場合は、そうではありません。
このアプローチには何か利点がありますか?
マトリックス スタック、gluPerspective()、glMatrixMode() などの非推奨の固定機能パイプライン機能を混在させる傾向があるのはなぜですか。また、これが手動で行われ、ユニフォームとして GLSL に押し込まれることを意図している場合は、そうではありません。
このアプローチには何か利点がありますか?
ユーザーの健全性の観点から、これを行う正当な理由があります。固定機能マトリックス (および GLSL で追跡されるその他の固定機能状態) はグローバルな状態であり、すべてのユニフォーム間で共有されます。すべてのシェーダーで射影行列を変更したい場合は、1 か所で変更するだけで実行できます。
固定関数なしで GLSL でこれを行うには、均一なバッファーを使用する必要があります。それか、使用するすべてのシェーダーに状態情報を収集するシステムを構築する必要があります。後者は完全に実行可能ですが、非常に面倒です。前者は比較的新しく、2009 年に導入されたばかりで、DX10クラスのハードウェアが必要です。
固定機能と GLSL 状態追跡を使用する方がはるかに簡単です。
私が知る限り、メリットはありません (機能を再コーディングする必要がないことをメリットと見なさない限り)。
ほとんどの場合、単に怠惰であるか、代替方法の知識が不足しています。
ほとんどのチュートリアルは非推奨のOpenGLを教えているので、おそらく人々はよく知らないでしょう。
利点は、よく知られた、徹底的にテストされた信頼性の高いコードを使用していることです。MS Windows または Linux のプロプライエタリ ドライバーの場合、GPU を構築した人によって作成されているため、非常に高速にする方法を知っていると見なすことができます。
グループ プロジェクトのもう 1 つの利点は、それを行う方法が 1 つしかないことです。独自の C++ 行列クラスを作成する必要があるかどうか、それを何と呼ぶ必要があるか、どの演算子をオーバーロードする必要があるか、および内部実装が 1D または 2D 配列である必要があるかどうかについての議論はありません...
基本的に、これらのアプリケーションはシェーダーを実行する必要がありますが、プログラマーは、OpenGL 互換性プロファイルを使用して既に利用可能な機能を再実装するのが面倒/ストレスになっているためです。
置き換えるのが「難しい」注目すべき機能は、線の幅 (1 より大きい)、線の点描、前面と背面のポリゴン モードを分離することです。