2025年5月2日(現地時間) – Blender Developer ブログにてジオメトリノードでの宣言的システム（Declarative Systems in Geometry Nodes）についての記事が公開されました。
ここでは、その内容について紹介したいと思います。
現在、Blenderのジオメトリノードでは、物理シミュレーションのための高レベルで使いやすいノードグループアセットを構築できる段階に到達することが目標とされています。
全般的なアプローチは昨年の以下記事で簡単に紹介されました。
今回共有された内容では、もう少し詳しく説明されています。
以下では、最も簡単なのでパーティクルシミュレーションを例として説明していますが、同じことがヘア、クロス、流体のような他の多くのシミュレーションタイプにも当てはまります。
2つの異なる視点
パーティクルシミュレーションの見方として次の2つの異なる方法があります。
- 宣言的（Declarative）：エミッター、フォース、コライダー、サーフェスアタッチメントなどの様々な既存の振る舞いを組み合わせることによって、パーティクルの意図された挙動（behavior）を記述します。
- 命令的（Imperative ）：パーティクルをシミュレートするための計算ステップ（computation steps）を記述します。例えば「力の積分」→「位置の更新」→「衝突点の検出」といったステップを記述します。
どちらもパーティクルシミュレーションを扱う有効な方法ですが、何を達成したいかによって、どちらが実用的かは異なります。
ほとんどのパーティクルシミュレーションはさまざまな挙動の組み合わせで記述できるため、宣言的な見方の方が実用的ですが、パーティクルシステムをゼロから構築する場合やカスタムのニーズがある場合は、命令的なアプローチの方が低レベルな詳細を扱う必要がある分、柔軟性が高くなります。
現在の状況
ジオメトリノードは、すでに命令的アプローチでパーティクルシステムを構築するのにかなり適しています。あらゆる種類のシミュレーションに対応できるようになるためには、まだいくつかの組み込み機能が不足していますが、全体の構造は整っています。
一方、挙動のセットを組み合わせて宣言的アプローチでパーティクルシステムを構築するのはずっと難しく、特定の挙動を記述するノードグループを作成し、それを「ソルバー」に渡して正しい順序で実際の計算を行わせる必要があります。
目標
現在、宣言的システムを構築できるようにするために、バンドル、クロージャ、リストといったコア機能の開発が進められています。下の画像は、個々の挙動がノードグループによってどのようにカプセル化されるかを示しています。
すべての挙動は同じタイプを持つため、それらを簡単に組み合わせて高レベルな挙動を形成できます。パーティクルソルバーに渡される順序は、基本的に重要ではありません。
このパーティクルソルバーの構築方法により、誰かが特定のインターフェースを公開するソルバーを作成し、他の人はそのソルバー用の挙動を作成・組み合わせることができ、内部がどう動作しているかをあまり気にする必要がなくなります。
すべての挙動ノードグループは非常に似た構造（さまざまな入力、1つの挙動出力）を持っているため、それを管理する高レベルなUIも構築できます。例えば、Particle Solverノードグループがモディファイアとして使われる場合、UIは以下のモックアップのように見えます。各パネルが1つの挙動に対応しており、任意の数の挙動を追加できます。個々の挙動（behavior）はアセットライブラリから提供されるノードグループアセットになります。
もちろん、ノードエディター内では常により柔軟に操作できますが、専用UIがあれば、多くの一般的な作業やよくあるニーズについては、複雑なノードエディタを直接操作しなくても、手軽に目的を達成できるようになるはずです。
最後に、この「宣言的システム」という考え方を取り入れることのもう一つの大きな利点は、Blenderの機能を拡張する「アドオン」の開発がより簡単になるという点です。
その理由は、いくつかの挙動を自動的に統合するコードを書く方が、複雑に入り組んだり階層が深くなったりしがちなノードグループの内部構造をプログラムで一つ一つ直接編集・操作するよりも、ずっとシンプルで開発しやすくなるからです。
シミュレーション以外への応用
この挙動ベースの宣言的システムアプローチは、あらゆる物理シミュレーションでうまく機能しますが、ユーザーが「どうやるか」ではなく「何をしたいか」を考える場合、他のケースでも有効です。
例えば、その一例にラインアートがあります。Line Artノードは、シルエット、非オクルードエッジ、交差など、さまざまな特徴に基づいてカーブを生成しますが、ユーザーはカーブがどう計算されるかにはあまり関心がなく、どんな種類のカーブが必要かだけを気にしています。異なる種類のカーブを記述するノードグループを作成し、それをLine Artノードに渡すことで、必要なすべてのカーブが出力されます。
同様のことは、ランドスケープ生成でも当てはまり、そこでは挙動が地形の特徴やアセットの散布ルールをカプセル化します。
命令的アプローチと宣言的アプローチの間には常にトレードオフがありますが、何百万人もの人が使う高レベルツールでは、柔軟性が少し低下する代わりに認知負荷を大幅に軽減できるため、宣言的アプローチの方が良いことが多いです。
バンドル/クロージャと宣言的システムの関係
バンドル（Bundles）とクロージャ（Closure）は現在実験的な機能です。（前回のワークショップ記事参照）これらは単体でも多くの興味深い用途がありますが、これが開発されている主な理由は、宣言的システムを構築できるようにするためです。
簡単に言うと、バンドルは複数の値を1つのリンクで渡せるようにし、クロージャはどこでも評価できる関数を渡せるようにします。
各個別の挙動は基本的にバンドルとしてカプセル化されます。そのバンドルの正確な構造は、その挙動を使うソルバーによって決まります。例えば、非常に基本的なメッシュパーティクルエミッターは下の画像のようになります。
バンドル内のTypeは、この挙動がどのような種類かをソルバーが判断するために使われます。ソルバーはEmitコールバックを呼び出して新しいパーティクルを作成します。コールバックの入出力もパーティクルソルバーによって決まります。
クロージャは、このシステム全体を機能させるための基本機能ですが、同時にほとんどの人はそれを知る必要がない、ニッチな機能でもあります。ほとんどのユーザーは、内部的にクロージャが裏で支えることで可能になる、優れた操作性の高機能なUIを持つシステムを、その仕組みを意識せず使うことになります。
以上、今回共有された内容となります。
フィードバックは、こちらの対応するフォーラムスレッドに投稿できます。
コメント