OpenGL でのレンダリングを準備する際に考慮しなければならない組織的な考慮事項の 1 つは、トポグラフィーのタイプと頂点の配置であることがすぐにわかりました。
現在、頂点を非常に長い配列に編成するための興味深い方法がいくつかあります。インターリーブされた配列、インデックスなどをうまく使用して、多くのジオメトリを 1 回の OpenGL 呼び出しに注ぐことができます。
ただし、場合によっては、小さな頂点配列を使用して単純に反復して複数の呼び出しを実行する方がはるかに簡単です。
時期尚早の最適化はやや無駄であるという考えには同意しますが、OpenGL 呼び出しを最小限に抑えることは、特に複数の呼び出しが実際に呼び出しごとにはるかに少ない頂点を必要とする場合に、どれほど重要な考慮事項でしょうか?
これは、開発プロセスの早い段階で重要な決定事項の 1 つであることがわかります。これは、頂点の作成方法と編成方法の多くの構造を形成するためです。
GPU に送信するコマンドごとにオーバーヘッドがあります。頂点をバッチ処理することで、そのオーバーヘッドを最小限に抑え、ドライバーがデータをハードウェアに送信する前に小さな最適化を行うこともできます。それはかなりの違いを生む可能性があり、それが glBegin と glEnd が OpenGL の新しいイテレーションから完全に削除された理由です。
多くのドライバー状態の変更と多くの描画呼び出しを避けるようにしてください。
EDIT :三角形のストリップで縮退した頂点を使用することを検討してください (処理される頂点の数を最小限に抑えるのにも役立ちます)。これにより、1 つの描画呼び出しを使用してすべてのトポロジをレンダリングできます (トポロジのパーツ間でドライバーの状態を変更する必要がない限り)。 .
特定のニーズに合わせたバランスを見つけることができます。しかし問題は、方程式には多くの変数があるということです。そして、単純な解決策はありません (「シーンを常に 1 つの大きなバッチとして作成する!」など)。ただし、 TraxNetからは良いアドバイスがありました。常に API 呼び出しを最小限に抑えるようにしてください (描画または状態の変更に関係なく)。しかし、それはほんの数回の電話である必要はありません。最新の PC では、1 フレームあたり数千である可能性がありますが、最新の携帯電話ではなく、おそらく数百です。また、TraxNetは縮退三角形 (フォーム ストリップを支援する) について言及しました - それらはまだ三角形ですが (レンダリングされた「合計」三角形数に少し追加されます) - ドロー コールの量を最小限に抑えるのに役立つコストはほとんどありません。