oop - Opengl - 表示リストと OOP

Question

私は Nehe OpenGL チュートリアルを読んでおり、表示リストに関するチュートリアルがあります。「クラスとオブジェクト」の代わりに使用する理由はありますか? たとえば、cube のクラスを作成してから、単に cube.render(x, y, z); と記述します。?

Answer 1

アイデアは、オンボードのディスプレイリスト処理でハードウェアを利用することでした。基本的には、グラフィックプロセッサのメモリに表示リストを作成し、オブジェクトを表示するたびにすべての座標などを再送信する代わりに、1つのコマンドを送信するだけでリスト全体を表示できます。これにより、CPUとGPU間の帯域幅要件を大幅に削減できます。

実際には、使用しているハードウェアとOpenGLの実装に大きく依存します。一部の実装では、ディスプレイリストによってパフォーマンスが大幅に向上しますが、他の実装では、本質的にまったく効果がありません。

Answer 2

私は Nehe OpenGL チュートリアルを読んでおり、表示リストに関するチュートリアルがあります。

Neheを読むのをやめることをお勧めします。Stackoverflow で言及されている Nehe に関連する適切なものを見たことがなく、チュートリアルでプラットフォーム固有の API が多用されすぎているのを見たことがありません。

NEHE の代わりに、OpenGL.org にアクセスして「books」セクションを確認してください。または、"OpenGL red book" の最初のバージョンがglprogramming.comで入手できます。OpenGL 4 に存在する最新の API はカバーしていませんが、利用可能なすべてのメソッドは、「互換性プロファイル」を介して OpenGL の最新バージョンでも引き続き利用できます。

「クラスとオブジェクト」の代わりに使用する理由はありますか?

2 つの異なる概念を混同しています。表示リストは、OpenGL 呼び出しのシーケンスを保存する OpenGL の方法であるため、後ですばやく「呼び出す」ことができます。OpenGL の実装によっては、アプリケーションのパフォーマンスが向上する場合があります。表示リストの使用は、プログラム (OOP) の内部構成とは何の関係もありません。OOP を使用し、cube.render() 内で表示リストを引き続き使用できます。または、頂点バッファ オブジェクトなどを使用することもできます。または、「非 OOP」スタイルで作業し、引き続きディスプレイ リストを使用することもできます。

Answer 3

表示リストは、GPU レベルで事前にコンパイルされています。独自のレンダリング関数は CPU レベルでコンパイルされ、その個々のコマンドは実行時に GPU を通過する必要があります。

これは、「ストアド プロシージャ」をインライン SQL を呼び出すカスタム関数と比較するようなものです。ストアド プロシージャはコンパイルされ、実行プランはサーバー側で生成されますが、カスタム関数はクライアント側アセンブリでのみコンパイルされます。