その章で説明されている手法を、FrameBuffer オブジェクトをテクスチャへのレンダリング方法として使用して実際に実装しました (ただし、WebGL は当時存在しなかったため、デスクトップの OpenGL では)。残念ながら、私はもうコードを持っているとは思っていませんが、今後の質問に [webgl] のタグを付けていただければ、何かお役に立てるかどうかお調べします。
フレームごとに数回ピンポンする必要があります (記事では 5 つのステップについて言及していますが、正確な数は、必要なシミュレーションの品質と正確な境界条件に依存するようです)。FBO の使用は、これが書かれたときよりもかなり効率的です (著者は、GeForce FX 5950 の使用について言及していますが、これは少し前のことです)。データを CPU に戻さない限り、テクスチャとフレーム バッファを切り替えるためのコストが高すぎるとは思わないはずです。
境界がわずか 1 ピクセルの厚さの場合、多少の漏れが発生しますが、結果のレンダリング方法と流体の速度によっては、許容できる場合と許容できない場合があります。境界を厚くすると効果があるかもしれません。これ以降、流体を境界内に閉じ込めるさまざまな方法を探る論文が書かれています (また、より効率的な拡散/圧力ソルバーに関するいくつかの論文も思い出します。バージョンは動作しています... Google Scholar で GPU gems の記事を引用している論文を検索すると、興味深いフォローアップがいくつか見つかります)。
補遺: 境界に関するあなたの質問を完全に理解しているかどうかはわかりません。重要なのは、境界にしたいものの各ピクセルでシェーダーを実行する必要があるということですが、そのピクセルがどのようにそこに到達するかは、線、点、または三角形で描かれているかどうか (その入力がは正しい）。
非常に一般的なケース (限られた数の境界プリミティブしかない場合は適用されない可能性があります) では、フレームバッファーをカバーするクワッドを描画する必要があります。これは、速度フィールドと圧力フィールドとの相互作用がより複雑であるためです (周囲のピクセル単純にエッジを定義するのではなく、別の境界ピクセルにすることもできます)。それを行う方法の説明については、セクション 38.5.4 (任意の境界) を参照してください。何かが境界でない場合は、ベクトル フィールドに触れません。そうである場合は、ベクトル値を合計するためにどの方向を見たいかをハードコーディングする代わりに、周囲のピクセルをテストして合計するだけになるでしょう。境界条件を適用できるように、境界ではないもの。
