- GPUベースのリアルタイム炎シミュレーションは、流体力学、格子ベースの並列計算、燃焼・浮力・レンダリングモデルを組み合わせることで、WebGLデモとして実装できる
- 基本モデルは非圧縮・非粘性流れを仮定し、染料・温度・燃料のようなスカラー場を速度場で運ぶセミラグランジュ移流によって、安定性と並列性を得る
- ナビエ–ストークス段階では、速度場を自分自身で移流した後、圧力投影で発散を減らし、Poisson方程式はJacobi反復のようなGPU向きの近似解法で処理する
- 格子補間と1次のセミラグランジュ法は乱流渦を弱めるため、vorticity confinementとcurl noiseで小さな回転ディテールを補強する
- 炎は燃料密度と温度場を追加して燃焼・冷却・熱浮力を計算し、Planck’s Lawに基づく黒体放射の色でレンダリングすることで、煙状の流体を炎のように見せる
GPUで炎をシミュレーションする全体の流れ
- 炎はグラフィックスにおける興味深い問題だが、過去には主に物理ベースではない方法で再現されてきた
- _Lord of the Rings_では流体シミュレーションのコストが高く、多数の煙スプライトが使われた
- ビデオゲームのようなリアルタイムアプリケーションも、ほぼ完全に非物理的アプローチに依存していた
- ここ10年ほどで、GPUのおかげで高速な流体シミュレーションが容易になり、基本的な流体力学アルゴリズムはGPUでの実装に直感的になった
- ILMは2009年に Harry Potter の炎のモデリングとレンダリングにこうした手法を使用した
- NVIDIAは2014年にゲーム向けの炎・煙エフェクトシステム FlameWorks を公開した
- 実装はWebGLデモとして構成されており、数学的にはベクトル解析と微分方程式の背景知識が必要になる
- ソースコードは GitHub にある
まず流体をモデル化する
- 炎を作る前に流体をシミュレーションする必要があり、ここでは非圧縮(incompressible) かつ 非粘性(inviscid) の流体を仮定する
- 2D速度場
u(x, t) は N × N 格子で表し、各格子点はその位置での速度値を持つ
- 染料密度のようなスカラー場
ψ(x, t) が流体速度に従って移動する過程が移流(advection) である
- 単純に各格子点を前方へ移動させる方法は並列化が難しく、複数の格子点が同じ対象格子点へ移動する可能性があり、時間刻みが大きいと不安定になりうる
安定した移流: セミラグランジュ法
- 質量保存則と発散定理を使うと、非圧縮流れのスカラー移流方程式は
∂ψ/∂t = -u · ∇ψ と整理できる
- 安定した方法は、各格子点から速度に沿って前方へ送る代わりに、現在の格子点から速度方向を逆向きにたどり、以前の位置の値を取得する方式である
- この方法がSemi-Lagrangian advectionで、Jos Stam が1999年に考案した
- 各格子点は反復ごとに1回だけ更新されるため、GPUでの並列化が容易である
- どの格子点も既存格子点の最大値を超える値には更新されないため、無条件に安定である
- 固定された速度場が非圧縮条件を満たしていれば、染料のようなスカラー場を安定して運べる
ナビエ–ストークスで速度場を更新する
- Navier-Stokes equations は、非圧縮流れにおいて流体の速度場が時間とともにどう変化するかを定義する
- 非粘性流体を仮定して粘性項を除き、外力もひとまず無視すると、重要なのは次の2項になる
- 速度場が自分自身を運ぶself-advection
- 非圧縮条件を満たすためのpressure
- シミュレーションループはおおむね次の順序で進む
- 速度場
u を自分自身で移流する
- 圧力
p を計算する
u = u - gradient(p) として圧力勾配を差し引き、非圧縮性を強制する- 新しい速度場で密度場を移流する
圧力計算では Poisson 方程式がボトルネックになる
- 自己移流後に得られる候補速度場
u' が発散0の条件を満たす保証はないため、圧力でこれを補正する必要がある
- 条件を整理すると
∇²p = ∇ · u' という形のPoisson equationになる
- 格子上で発散とLaplacianを離散化すると、
N × N 格子に対して N² 個の線形方程式と N² 個の未知数を持つ線形システムが生じる
- 正確な線形システム解法は格子サイズに対して超線形にコストが増えるため、リアルタイムシミュレーションには負担が大きい
- GPUでは厳密解の代わりに、十分に良い近似値を反復的に求められる
- Jacobi method は各要素の推定値を並列に更新するため、GPU実装に適している
- Conjugate Gradient や Multigrid のような、より速く収束する解法もGPUで実装可能である
- 煙や炎では、水のように体積変化が明瞭ではないため、圧力の精度よりも移流品質や実装のしやすさが重要になる場合がある
渦のディテールを取り戻す
- 格子に速度場を保存すると、補間過程で望ましくない数値的平滑化が発生する
- 1次セミラグランジュ移流の粗い近似まで加わると、乱流の渦が消えてしまい、流体が過度に滑らかで単調になる
- 解像度を上げれば緩和できるが、リアルタイムシミュレーションでは計算資源が限られる
- Vorticity confinement は、各ステップで失われる小さなディテールを見つけて増幅する方法である
- 完全に現実的な方法ではないが、小スケールのディテールを概ね物理的に妥当な位置に保つ
- もともとはヘリコプターブレード周辺の複雑な流れ場を工学シミュレーションで扱うために考案された
- 各格子点の curl によって vorticity を測定し、周囲で vorticity が高い方向を計算したうえで、confinement 定数
ε > 0 で調整した回転力を速度場に加える
- 低い confinement 値であるおよそ
0–15 だけでも大きな違いが出る
- さらに高い値では、スタイライズされた billowing な流れを作れる
Curl noise で乱流を合成する
- Curl noise は、既存の速度場の vorticity を測定して増幅する代わりに、ノイズ関数で新しいスカラー vorticity 場を作る方式である
- 数学的には、ランダムな vorticity 場
φ = rand * z を合成し、それを既存の vorticity ω に加えて最終的な vorticity ω* = ω + φ を作る
- 煙や炎のように速く動き、乱流が強い流体は、vorticity confinement と curl noise の影響を大きく受ける
- 実際の curl noise 場
φ は時間とともに変化し、流体の流れによって一緒に移流される
炎のために燃料と温度を追加する
- 基本的な流体ルーチンだけでも煙のような流れは作れるが、炎と煙をシミュレーションするにはいくつか追加のチャネルが必要になる
- 燃焼モデルでは燃料密度
ρ と 温度場 T を追加する
0 ≤ ρ ≤ 1 は燃料密度であるT > 0 は各位置の温度である
- ここではシステム内の燃料はすでに着火しており、継続的に熱を加えると仮定し、未着火の燃料の問題は扱わない
- 各タイムステップで、燃料は指定された燃焼温度に応じて温度を上昇させる
- 温度は
T' = max(T, ρ * T_burn) の形で更新される
- 熱は高温部から低温部へ拡散し、流体の大きな流れも熱を運ぶ
- シミュレーションでは温度場を速度場で移流する
- 反応する分子も流体とともに移動するため、燃料場も移流する
- 高温の分子は Stefan-Boltzmann Law に従って光として温度を放出する
- 物理的に正確なシミュレーションなら Stefan-Boltzmann 定数を使う
- グラフィックスシミュレーションでは、アーティストが冷却率
σ_cool を調整できるほうが有用である
- 燃料は各タイムステップごとに燃焼率
γ_fuel に従って減少する
熱浮力で高温流体を上昇させる
- 温度場だけを計算しても流体の流れにはまだ影響しないため、高温の空気が上昇し、低温の空気が下降する効果を追加する必要がある
- Thermal buoyancy は、温度に比例する上向きの力を速度場に加える
- 非圧縮流れを仮定するため、実際の空気膨張は扱わない
- 速度場は
u' = u + (β T Δt) j の形で更新される
β は正の浮力定数、j は上向き単位ベクトルである
- 燃焼モデルと熱浮力を加えると、炎のように見える流体を作れる
- 適切な浮力と冷却値では、大きく膨らみながら立ち上る物質の柱を得られる
- この段階の結果は、正確な火炎というよりまだ煙に近い
- 全体のループは、速度の自己移流、燃焼、vorticity confinement、熱浮力、圧力投影、密度・温度・燃料の移流、という順序で構成される
黒体放射で炎の色をレンダリングする
- 炎はparticipating mediumであり、黒体放射によって光を放つ
- 炎のオレンジ色や赤色は黒体放射に由来し、燃焼中の燃料シミュレーションを正しい式でレンダリングすれば、煙から炎へと移行できる
- Planck’s Law は、特定温度
T の黒体が放出する光のスペクトル密度を説明する
- fragment shader で黒体レンダリングを実装すれば、流体・燃焼・浮力モデルの上に完全な炎シミュレーションを構築できる
- まだ扱っていない拡張テーマも残っている
- 固定体積内のシミュレーションを解く非格子ベースの手法
- 半分ほど水が入ったコップのように、流体が格子内の異なる領域を占有する可変ドメイン問題
- 動的障害物
- より正確な黒体放射、光散乱、後処理効果といったレンダリング改善手法
1件のコメント
Hacker News のコメント
CFD の博士号を持っているが、渦度閉じ込め（vorticity confinement）手法とカールノイズ乱流（curl-noise turbulence）は初めて見た
産業用 CFD のようにレイノルズ数がもっと高い領域では、数値手法の人工散逸をノイズで相殺しようとするアプローチは普通は望まれない
むしろ高レイノルズ数シミュレーションを安定化させるために人工散逸を求めることが多く、コンピュータグラフィックスでは物理的に正しいことよりもそれらしく見えることのほうが重要に見える
正確に見える必要すらなく、格好よく見えさえすればいい
物理オタクとしては、ゲームセンターで物理法則に反する場面を指摘して人に笑われることがよくあった
Nintendo で Mario World に携わった物理学者の翻訳インタビューが面白かった。Mario の世界の物理は「現実」の物理と同じではなくても、現実の物理のように一貫したルールがあり、プレイヤーがゲーム内で何ができるかを理解してパズルを解くうえでそれが重要だと強調していた
その論文の基本アイデアを使って、ガス惑星のテクスチャを作るなかなか良いプログラムを作った: https://github.com/smcameron/gaseous-giganticus
「なぜ Unreal Engine は数秒でできるのに、あなたのCFD ソフトウェアはシミュレーション 1 つに何時間もかかるのか」と一度ならず聞かれた
https://en.wikipedia.org/wiki/John_Steinhoff
https://en.wikipedia.org/wiki/Vorticity_confinement
関連論文もある:
https://www.researchgate.net/publication/239547604_Modificat...
https://www.researchgate.net/publication/265066926_Computati...
昔どこかで記事を読んで、C でおもちゃレベルのごく単純な炎シミュレーションを作ったことがある
各ピクセルの明るさをすぐ隣のピクセルたちの平均輝度に設定し、下から上へ計算すればいい
下側に左右へ動く「熱い」ピクセルをいくつか追加するだけで即席の炎ができ、コードもごく少なく、微積分なしでかなり格好よく見える
1 次元では単に 2 階導関数、つまり曲率で、山が鋭いほどより負になり、谷が鋭いほどより正になる
その分だけ値を変えると平均化の効果が出て、離散化された形は文字通り平均を取ることだ
実はずっと微積分をしていたということ
道を知っていることと、その道を歩くことは違う
直感的なグラフィックで説明する 3Blue1Brown の動画もある: https://youtube.com/watch?v=ToIXSwZ1pJU
ゲーム向けの火と煙のシミュレーション、GPU 上での流体シミュレーションの話をしているが、こうしたエフェクトがゲーム内で動くなら GPU はすでに忙しいのではないかと思う
CFD 問題を走らせながら同時にレンダリングするのはかなり大きな負荷に見える
dGPU がレンダリング関連の作業をしている間に iGPU でこういうものを動かせるのか、それとも iGPU が非力すぎて、むしろ CPU に落としたほうがよいのかも気になる
最近の GPU は非常に強力で、物理、派手なレンダーパス、流体シミュレーション、「ゲーム AI」のユニット経路探索などを 100FPS 以上で処理できる
長く言うと、60FPS 以上の非常に高速な「スライドショー」のフレームをレンダリングする合間の時間がフレーム予算で、通常は 5〜30ms の間に次フレームの状態計算とレンダリングに必要な計算をしなければならない
その中には、マップ上のユニット移動、炎の物理計算、地形テクスチャのコピー、マテリアル付き頂点のレンダリングなどが含まれ、多くのゲームエンジンでは GPU がフレームごとにこうした別個の計算を何十個も実行する
GPU は基本的にメインコンピュータに接続された補助コンピュータなので、毎フレーム複数の仕事を投げると結果を返し、それらの結果を合成してゲームらしく見せる
iGPU はほとんど誰も使わない
通常、主 dGPU に比べてまったく役に立たないので無視されがちだ
そのバランスを取る時代は面白くなりそうで、ますますローカルとリモートのコンピューティングリソースが負荷を分担するようになると思う
Red Faction で壊れ続ける壁を見ながら、その設定を割り当てたか、気づいたかした記憶がある
ほとんど Minecraft だが、火星でロケットランチャーを持ってやる感じだった
GPUを使うのに、必ずしもゲームをしている必要はない
最近はGPUモードを備えたレンダリングソフトウェアも多い
ただしGPUアルゴリズムは高度に並列化されているため、CPUシミュレーションのアルゴリズムとは異なる場合が多い
EmberGenは、コンシューマー向けGPUで炎と煙をリアルタイムにシミュレーションし、ノードベースのワークフローにも対応していて新しいエフェクトを作りやすい、本当にすごいソフトウェア
以前は数時間かかっていたワークフローが、今では数分で調整できるようになった
https://jangafx.com/software/embergen/
この記事はEmberGenについてのものだと思っていたし、正直なところEmberGenがHNであまり大きく注目されていないのは少し残念: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
EmberGen/JangaFXとは関係なく、単に満足している顧客
https://odin-lang.org/showcase/embergen/
こういうものが好きなら、Ten Minute Physicsも楽しめるはず
特に第17章「How to write an Eulerian Fluid Simulator with 200 lines of code」が良い
https://matthias-research.github.io/pages/tenMinutePhysics/i...
数学専攻からソフトウェアエンジニアになった人がCFDシミュレーションに入門するには、どんなおすすめ資料がよいのか気になる
このテーマは本当に面白いが、ベクトル解析や偏微分方程式をやってからかなり経っていて、数学がかなり錆びついている
https://www.youtube.com/watch?v=zxiqA8_CiC4
無料の非商用版「Apprentice」は、レンダリングと共同作業機能だけが制限されている
ただし、かなり奥の深いツール
ソフトウェア側からこの業界へ移ると、こうしたツールを学ぶワークフローはまったく違う
Houdiniは3DモデリングソフトというよりIDEに近いと言う人が多いが、多くの点で同意する
Blenderのような視覚的なツールを使う代わりに、ほぼすべてをノードネットワークを作り、属性とパラメータを変更する形で行う
ほとんどのことはPythonででき、3ds Maxのようなものよりすっきりしているが、コンパイルされないため大規模シミュレーションでは性能が悪い
独自のC系言語であるVEXも使えるし、より複雑な数学など細かな作業向けの、さらに粒度の細かいノードシステムもある
技術的には、ほぼすべてがデータ指向のワークフロー
ただし「ドキュメントを読んで学ぶ」タイプなら、チュートリアルを早く好きになる必要がある
自分が触ってきたどんな環境やパラダイムともかなり異なり、コミュニティは概して親切だが、専門性の呪いはかなり強い
本当にやりたいなら、その分野の仕事に就くのがよく、FederalまたはContractor側でMarshall Space Flight CenterやAmesに応募してみる価値がある
AmesにはTop500基準でAitken [#85, 9.07 PFlops]、Pleiades [#132, 5.95 PFlops]、Electra [#143, 5.44 PFlops]のシステムがある
GRC、LARC、JSCにも一部ある
少なくとも数年前はContractor/Federalの統合がかなりうまくいっていて、予算配分を除けばほぼ透明だった
NASA内では、MSFCのPropulsion Structural, Thermal & Fluid Analysis [2][3]とAmesのEntry Systems [4]グループがかなり知られている
当時はOverflow/LARC [5]やLoci/Mississippi State University [6]を使い、移動する重合格子、10〜20種程度の反応性燃焼化学種、ラグランジュ型の蒸発粒子ダイナミクスを含む、約1億セル規模の機体または機体＋発射台のHybrid RANS/LESシミュレーションを走らせていた
SSMEとSRBが同時に点火され、打ち上げ時の水噴射抑制システムも含まれていた
ただしこの情報は10年前のものなので、最近の最先端がどうなっているかは分からないし、今はこれより進んでいるはず
業界が関心を持つ方向を知りたいなら、古いとはいえ2014年のCFD Vision 2030 Studyは悪くない入門資料 [7]
Supercomputingのチケットを手に入れて歩き回ってみるのもよい
今年はDenverで開催された [8]
ただし焦点は「大型」寄りなので、巨大な気象シミュレーションや星雲ダイナミクスを主に見ることになるはず
カンファレンス自体は好きだが、#CPUs/#GPUs/#FPGAs++ のような規模面での成果がないと注目されにくいのは確か
NASA以外の政府系では、NIST(Gaithersburg)、DOE(Oak Ridge, Sandia, Los Alamos)、Air Force(AF Research Lab)、Huntington Beachがある
[1] NASA Advanced Supercomputing Division: https://en.wikipedia.org/wiki/NASA_Advanced_Supercomputing_D...
[2] NASA, MSFC: https://www.nasa.gov/wp-content/uploads/2016/01/g-28367g_pst...
[3] やや古い例: https://ntrs.nasa.gov/api/citations/20140016892/downloads/20...
[4] NASA Ames: https://www.nasa.gov/entry-systems-and-technology-division/
[5] OVERFLOW/NASA/LARC: https://overflow.larc.nasa.gov/
[6] Loci/MSU: https://simcenter.msstate.edu/
[7] CFD Vision 2030 Study: https://ntrs.nasa.gov/api/citations/20140003093/downloads/20...
[8] Supercomputing SC23: https://sc23.supercomputing.org/
この分野で活発に活動している Muller による第2部もあります: https://matthias-research.github.io/pages/tenMinutePhysics/i...
その後書籍化され、現在は第2版の Fluid Simulation for Computer Graphics になっています