OpenGL ES 2.0 を使用して、Android アプリケーション用の非常に単純なパーティクル システムを作成しようとしています。基本的には、背景で直線的に動く雲だけです。これを始める前の私の最初の考えは、ポイント スプライトを操作することでした。それが私がやろうとしてきたことです。これを機能させるのはかなり困難でしたが、これらの問題はさておき、ポイントスプライトは本当にこれに適した方法ですか?
バグを解決するための検索で、それらについてかなりの矛盾することを読みました。それが私が求めるべき解決策ではない場合、すべてを正しく機能させるために多くの時間を投資したくありません。最初の場所。人々はクリッピングなどのあらゆる種類の問題を投稿し、三角形を使用する場合と比較してパフォーマンスが低下することさえあります。経験豊富なユーザーに、ポイント スプライトがどこに適合し、いつ使用する必要があるかについての洞察を求めています。これには、画面上でせいぜい数十個の「パーティクル」しかない私のような状況が含まれます。
ポイントスプライトには厳しいサイズ制限があり、サイズが大きいほどパフォーマンスが低下することに注意してください。目標が12個の「パーティクル」のみを持つことである場合、それらをクワッドとしてレンダリングする必要があると思います。一方、目標が多数の「雲の粒子」で構成される12の雲を作成して、それぞれにアニメーション効果を与えることである場合は、ポイントスプライトを使用する必要があります。
ボトルネックは、特にブレンドを使用する可能性があるため、充填率になります。
100以上のクラウドがある場合、ポイントスプライトを使用するかどうかの質問がより適切になります。それらをアニメーション化するには、各フレームをopenglするために新しいバッファーを送信するか（方法1）、異なる変換行列を使用して別々の呼び出しで各クラウドをレンダリングする必要があります（方法2）。後者の方が最も遅い可能性がありますが、前者では、ポイントスプライトを使用した場合（方法3）、クラウドごとに1つの新しい頂点を送信するのに対し、クラウドごとに4つの新しい頂点を送信する必要があります（インデックス付きレンダリングを想定）。
この時点で、何が最速になるかを大まかに計算するのは非常に簡単です。方法2は16*4*num_clouds、フレームごとにgpuに転送されるデータのバイト数を意味します。方法1はd*4*num_clouds、方法3d*num_cloudsです。ここで、dはzが必要かどうかに応じて2または3です。
注目に値するのは、メソッド1と3が1つのバッチでデータを送信するのに対し、メソッド2は一度に16*4バイトを送信することです。
GL ES 2を使用しているため、方法2のマトリックスをスキップして、変換をベクトルとして送信することもできますが、バッチ処理されていないデータ転送と、インスタンスごとに均一を設定するコストに悩まされます。
編集：実際には、多くのパーティクルの場合に行うことは、均一な時間を設定し、静的属性として雲の速度を設定し、速度に時間を掛けてシェーダーでそれらをアニメーション化することです。必要に応じて、エッジを包み込むようにしてください。したがって、完全にアニメーション化されたクラウドシーンの場合、フレームごとに4バイトを転送するだけで済みます。
「iPhone3Dプログラミング」のパーティクル記事を読むことをお勧めします。
この本のタイトルには「iPhone」が含まれていますが、この本はOpenGL ES 1.1/2.0を一般的に説明しています。したがって、この本の知識をAndroidまたはAndroidNDKに使用できます。