2025年10月22日（現地時間）- 2025年9月に開催されたジオメトリノードのワークショップの内容が共有されました。
Blenderカンファレンス後に開催されたワークショップでは多くの設計トピックについて議論が行われました。今回はMolecular Nodesアドオンの開発者であるBrady Johnston氏と、EntagmaのManuel Casasola Merkle氏の2名がゲストとして参加したとのことです。
以下では、そのワークショップの内容を紹介したいと思います。
これまでのジオメトリノード
前回のワークショップは、わずか2か月半ほど前でしたが、多くの進展があり、改善点の多くが次期Blender 5.0リリースに盛り込まれています。
- クロージャとバンドル (Closures and Bundles)：クロージャとバンドルは、実験的機能ではなくなりました。詳細は以下の記事をご覧ください。さらに、これらはリピートゾーンと共にシェーダーノードでもサポートされるようになりました。
- ソケット形状 (Socket Shapes)：ソケット形状の更新も実験的機能から外れました。変更点は以下の記事をご覧ください。
- ボリューム (Volumes)：新しいボリュームグリッドノードも実験的機能ではなくなりました。詳細は後述。
- リスト (Lists)：リストの初期バージョンが実験的機能としてマージされました。設計と実装作業は継続中です。
- ヘアープロジェクト (Hair Project)：これも継続中です。物理ソルバーの統合に関して多くの実験が行われました。Blenderカンファレンスではこれに関する講演がありました。
- エッセンシャルアセット (Essentials Assets)：Geometry Nodesでの作業をしやすくするための、新しい組み込みノードグループが追加されました。
- ビューアー (Viewer)：前回のワークショップで議論された新しいビューアーノードの設計が実装されました。
- タンジェント (Tangents)：新しいUVタンジェントノードにより、メッシュ上のタンジェントベクターにアクセスできるようになりました。
Blender 5.0で予定されているジオメトリノードの変更点の概要については、リリースノートをご確認ください。当サイトでもまた紹介したいと思います。
エッセンシャルアセット
Blender 5.0 では、これまで多くのアセットを同梱する際に障害となっていた大きな技術的課題が解決されました。従来の「アペンド」や「リンク」には、エッセンシャルアセットをユーザーファイルに追加する際にさまざまな問題がありましたが、新しく導入された「パッキング（Packing）」によって改善されています。パッキングでは、リンクされたデータブロックを現在の .blend ファイル内にも保存できるため、自己完結型のファイルを維持できるようになりました。
今回追加された中で注目は、Geometry Nodes をベースにした以下の 6 種類の新しいモディファイアです。これらは柔軟な配列やスキャッタリング（配置）、インスタンス化を標準でサポートし、より効率的な制作ができるようになります。
Array（配列）
オブジェクトを直線、円、カーブ、またはカスタム変換に沿って配置します。ギズモやランダム化にも対応しています。従来のアレイモディファイアも現時点では利用可能です。
Scatter on Surface（サーフェス上に散布）
他のオブジェクトをサーフェス上にインスタンスとして配置します。密度ベースや数量ベースのサンプリングに対応し、分布は属性やイメージテクスチャで制御可能です。複数のモディファイアを連結することで、異なるオブジェクトを異なる分布で散布できます。
Instance on Elements（要素上にインスタンス）
ポイント、エッジ、フェイス、またはフェイスのコーナーにインスタンスを作成します。
Randomize Instances（インスタンスのランダム化）
他のモディファイアで作成されたインスタンスに追加のランダム性を加えます。
Curve to Tube（カーブからチューブへ）
カーブから円柱メッシュ（または任意のカスタム形状）を生成します。丸いキャップに対応し、UV マップも生成します。
Geometry Input（ジオメトリ入力）
モディファイアスタックの最初に使用し、別のオブジェクトの最終ジオメトリをコピーできます。
さらに、Geometry Nodes でよく使う処理を簡単にする低レベルのノードグループアセットも追加されました。また、別チームによってコンポジター用の新しい組み込みエフェクトも導入されています。
新しいモディファイアやノードの内容はワークショップ前に合意されていましたが、ワークショップ中にノードグループの見直しが行われ、リリース前にいくつかの改善点が見つかりました。これらの修正はすでに最新のビルドに反映されています。
物理バンドル
開発チームは、物理シミュレーションを「宣言的システム」として統合することを目指しています。このシステムでは、ユーザーがフォースフィールドやコライダー、さまざまな制約を使って「どう動いてほしいか」を記述し、ソルバーノードがすべてを正しくシミュレートする方法を計算します。
課題のひとつは、シミュレーションワールドに関する情報をどのようにソルバーへ渡すかという点です。これには、あらかじめ決められた構造を持つ「バンドル」を利用する方法が検討されています。カスタムXPBDソルバーの実装や、Bullet、Jolt、Box2Dの公開に関する様々な実験が行われてきました。
基本的な流れとしては、ソルバーノードが「シミュレーションワールド全体を記述したバンドル」を入力として受け取り、それを処理して変更を加えたうえで、シミュレーションゾーンに出力します。次のステップでは、その出力が新たな入力として利用され、シミュレーションが継続されます。さらに、別のノードを使えば、シミュレーションゾーンの外部からバンドルを更新し、ワールドの変化を反映させることも可能です。
将来的には、カスタムルールを使用して別のバンドルからバンドルを更新することで、このプロセスを簡素化する新しいノードが計画されています。
物理ソルバー
開発チームが最初に取り組んでいる実用的なソルバーは XPBDソルバーで、まずはヘアーシミュレーションに焦点を当てています。
基本的な動作はすでに実現していますが、まだ多くの機能が実装段階にあるとのことですか。
ワークショップでは、以下のような実装の詳細や優先順位について議論が行われました。
コリジョン（衝突）処理
正確で安定した衝突検出と接触処理は、シミュレーションにおいて非常に重要です。議論では以下の点が取り上げられました。
- 面と点、または辺と辺（エッジ同士）の衝突を検出する必要があり、その際には相対速度も考慮する必要があります。
- SDF（符号付き距離関数）による衝突検出は、処理が高速である可能性がある一方で、別のトレードオフ（精度の問題など）がある選択肢として議論されました。
- SDF と BVH ツリーの比較
- SDF：SDF は、点がオブジェクト内部にあるかどうかの判定は高速ですが、押し出す方向を求めるには勾配フィールドが必要であり、低解像度では精度が問題となります。
- BVHツリー：BVH ツリーは Blender の現行実装ではやや低速ですが、非常に正確な接触点を得ることができます。
- ハイブリット案：SDF を高速な衝突テストに、BVH ツリーを正確な衝突解決に用いるハイブリッド方式も検討されました。
- コライダー内のインスタンス
- シミュレーションが多数のインスタンス化されたオブジェクト（例：岩）とも衝突できることが望ましいとされています。
- 理想的には、各インスタンスの BVH ツリーを統合して一つの BVH ツリーを構築することですが、現状の Blender では直接サポートされていません（Embreeなど外部ライブラリへの置き換えも代替案）。
- 現状では、ノード側からインスタンスのジオメトリを直接参照する方法がないため、、まずはインスタンスではない実ジオメトリをコライダー入力として扱う方法が検討されました。
静止形状の初期化
グルーミングされたヘアーは通常、重力を前提に作られています。そのため、シミュレーションで再度重力が適用されると髪が垂れ下がってしまいます。この問題を解決するために、重力が適用された後でも元のグルーム形状を維持できるよう、各セグメントの静止時の長さや曲げ角度、剛性を逆算する「静止形状の初期化」が議論されました。
これらの計算（rest_segment_length や bending_stiffness など）を行う専用ノードを用意する案や、元のカーブに直接アトリビュートを書き込むノードツールとして提供する案も検討されています。
ソルバーの出力
ソルバーは、シミュレーションのデバッグやエフェクト調整に役立つ追加データを出力できます。特に重要なのは「解の品質」を示すエラー値で、拘束が正しく解決されるほどゼロに近づきます。もしシミュレーション結果が悪く、この値がゼロから遠い場合は、まずサブステップ数を増やすといった判断が可能になります。
また、エラー値をタイムライン上で時系列表示したり、セグメントの伸縮といった内部の力を可視化することも有用であると議論されました。
その他の議論内容
上記に加えて、次のようなテーマも話し合われました。
- ヘアーの自己衝突：髪同士の衝突については、現状のユースケースでは有用性が低い可能性がありますが、密度ボリュームを使ったボリューム維持や摩擦のシミュレーションといった関連効果が検討されました。
- ウォームスタート：前フレームの計算結果を次のフレームの初期値として利用する手法です。特に砂のような粒状シミュレーションでは有効ですが、衝突判定をフレーム間で一貫して扱うのが難しく、実装は複雑になるとされました。
- ガイド変形：ガイドカーブに基づく変形ワークフローをサポートするため、ヘアーアセットの更新が必要であり、適切な補間処理には「リストアトリビュート」機能が不可欠であると確認されました。
これらの詳細な議論内容については、devtalkのスレッド（英語）で確認できます。
オブジェクトバンドル出力について
多くのユースケースでは、Geometry Nodes モディファイアから単なるジオメトリだけでなく、より複雑なデータを出力する必要があります。例えば、複数のメッシュやアニメーションを駆動する値、さらには他のオブジェクトのエフェクターとして利用できるフィールドやクロージャなどです。
これは、現在は「バンドル」が利用可能になったことで、Geometry Nodes モディファイアからバンドルを出力し、それを他のオブジェクト（例：オブジェクト情報ノード経由）から読み取ることで実現可能です。
課題となるのは「バンドルをどのように出力するか」で、次のような方法が検討されました。
- 専用のバンドル出力ソケットを設ける方法
→ 可能ですが、他のモディファイアにもバンドルをパススルーさせる必要があり、処理ルールが複雑になります。 - バンドルのみを出力し、ジオメトリをその一部とする方法
→ 実現は可能ですが、既存システムに大きな変更が必要で不便です。 - ジオメトリセット内にバンドルを保存する方法
→ すでにプロトタイプが存在し、ジオメトリ全体にわたる属性のように扱えます。Geometry Nodes がサポートするあらゆる種類のデータを含められ、専用の「バンドル取得／設定ノード」で操作できます。既存の仕組みと自然に統合でき、実装もシンプルなため、この方法が最善と合意されました。
ただし、バンドルとカスタムプロパティの関係については課題が残ります。バンドルは保存方法が異なり、フィールドのようにカスタムプロパティとして保存できないデータも含むためです。そのため、これらのバンドルアイテムにアクセスするには、新しいタイプのドライバー変数が必要になると考えられています。
ズームアウト時のノードエディタ描画
最近のフレームノードの改善を受けて、ノードグループをより見やすくするために、フレームの活用をさらに推奨する方法が検討されました。
良いアプローチひとつとして、ラベルが読めなくなるほどズームアウトした際に、ノードツリーをより抽象的に描画することが挙げられています。この場合、フレームとそのラベルがより強調され、ツリー内での現在位置を把握しやすくなるかもしれません。
この考え方は、ノードツリーにミニマップを導入する発想とも関連しています。いずれの場合も、ノードエディタ全体に関わる設計上の課題は共通しており、「ビューを過度に複雑にせず、必要な情報をどう残すか」という点が重要になります。
もちろん、実際に有効かどうかは見た目のデザインに大きく左右されます。現時点ではこのビューのための十分なデザイン検討は行われていないため、今後はコミュニティからのモックアップや提案が寄せられることが期待されています。
デフォルト入力
ノードグループのデフォルト値をより柔軟に扱えるようにすることは、長年繰り返し議論されてきた難しい課題です。これまでの最初の提案には大きな制約があり、その後に出された多くの案も、元の設計を少し変えただけにとどまるか、あるいは「構成可能性（composability）」に問題がありました。特に「単一ノードからグループを作成した場合、元のノードと同じ動作を持つべき」という原則を満たすのが困難でした。
そこで、新しいアプローチが検討され、有望視されています。それは「入力のデフォルト値を計算する専用のノードグループを、グループ入力に割り当てられるようにする」という方法です。例えば、ノイズフィールドを出力するだけの小さなノードグループを作り、それをフロートフィールドソケットのデフォルト入力として利用できるようにします。
この方法の利点は以下の通りです。
- 構成可能性の問題を解決できる
- デフォルト値を再利用しやすくなる
- 各ノードツリーをより整理された状態に保てる
実現のためには、既存の「デフォルト入力」ドロップダウンを拡張し、「ノードグループ」という新しい選択肢を追加する必要があります。これにより、単純なケースでは従来通りのデフォルト入力を使いつつ、必要に応じてカスタムのデフォルト値も設定できるようになります。
さらに、柔軟なノードグループ入力によって実現可能であるにもかかわらず、「デフォルト値としてカスタムアトリビュート名をサポートすること」も合理的であると合意されました。
複数オブジェクト対応のノードツール
Blender カンファレンスでは、インスタンスを使うことでオブジェクトをノードツールで処理する簡単な方法になるのではないか、という話題が短時間ながら取り上げられました。これが実現すれば、ジオメトリノードを使ってオブジェクトの移動・作成・削除といった操作が可能になります。
ツール用ノードグループに「実行モード（execution mode）」を追加することで、既存のノードグループとの互換性を保ちつつ、ノードを使って幅広いシーンデータの処理にも対応できる可能性が開けます。
カンファレンス直後に実装を試みたところ、設計はうまく機能し、コードの大幅な変更も必要ありませんでした。ただし、オブジェクト間でデータを共有するさまざまな方法を考慮すると、オブジェクト名を保存するための文字列属性（string attribute）の正式なサポートが不可欠であることが明らかになりました。これが整備されて初めて、機能として完成したと言える状態になります。
モーダルノードツール
この1年間、モーダルノードツールのプロトタイプ開発が進められてきましたが、その過程でいくつかの課題が明らかになりました。今回のワークショップでは設計面の議論が進み、次のステップとして、プロトタイプ段階を超えたより恒久的な実装に移行できる見通しが立ちました。
シミュレーションゾーンにおける評価中のデータ保存については、モディファイアと同じ方法で扱うべきであるという方針が改めて確認されました。
さらに、ノードツールのオペレーター登録方式についても見直しが行われました。これまではすべてのノードツールに対して1つのオペレーターを登録する方式でしたが、今後はツールごとに個別のオペレーターを登録する方針です。これは、従来の方式では Blender のオペレーター設計が過度に拡張されており、モーダルキー操作（keymap）の実装が難しいためです。
また、ノードグラフにユーザー入力を取り込む方法について、新たな設計方針が決まりました。モーダルキー入力は、ノードツールツリー内に配置された「モーダルイベント」ノードによって定義されます。このノードには、キー入力項目の名前と、その入力がアクティブなときに出力されるブール値が含まれます。
デフォルトのキー設定はノードエディタのサイドパネルで構成され、ユーザー独自のキー設定は既存のオペレーターと同様にキー設定エディタで編集できます。
以前に検討されていた設計と比べて、モーダル入力ごとに個別のノードを使う今回の方式は、モーダルツールの構築をよりシンプルにすることが期待されています。
ボリューム
ボリュームに関する話題は、シミュレーション関連の議論の中で繰り返し取り上げられました。当初の計画には含まれていませんでしたが、ジオメトリノードにおけるボリュームグリッド機能を Blender 5.0 で正式にリリースすることが望ましいという点で合意されました。詳細については、以下の記事をご覧ください。
Blender 5.0以降のボリューム機能に関しては、圧力ソルバー、ポイントのラスタライズ、レイキャスティングなど、今後追加されると便利と考えられる機能については合意が得られましたが、具体的な実装方針についてはまだ決定されていません。
リスト
リストは現在進行中の開発トピックであり、最初のイテレーションはすでに実験的機能としてメインブランチに含まれています。さらなる機能拡張に向けて、いくつかの設計上の判断が必要とされました。
フィールドやクロージャからリストを生成するノードについては、複数の入力を受け取り、複数の出力を生成できる構造にするべきだという点で合意されています。また、単一の値・リスト・フィールドの組み合わせをノードが処理する場合に、どのような挙動を取るべきかについても検討が行われました。
リストフィールドがサポートされた場合の、簡略化されたEdges of Vertexノードのモックアップ。
リストへの関心のほとんどは、「リストフィールド」の導入です。これは、例えば各頂点に対して値のリストを持つような構造であり、現在複雑になっているメッシュトポロジーノードの簡素化に大きく貢献すると期待されています。
非フィールドのリストが適切に機能すべきであること、リストを用いたフィールド評価に関するいくつかの実装詳細について議論され、リストをアトリビュートとして保存することは初期実装の一部である必要はないという点で合意されました。
その他
これまでに挙げた主要なトピックに加えて、以下のような項目についても簡単に検討が行われました。
ビューアーノードの再設計、コミュニティから提供されたスワップオペレータ、UVタンジェントノード、動的な出力の可視性、スイッチノードの追加ボタン、バンドル/クロージャの型定義、オプションのラベル、オプションの管理パネルなど、すでに進行中パッチがレビューされました。
会議中に取られたすべてのメモ（英語）がこちらから閲覧可能です。
5.0アップデートに関する豆知識
Dalai Felinto 氏が、DNA（あるいはRNA）を模したアイコン（表示モードドロップダウンにあるデータAPIの左側に表示される）のらせんの向きが、生物学的に正しくない「左巻き」になっていたことを発見！DNAもRNAも基本的には「右巻き」であるべきとのことで、アイコンを反転することで修正が行われました。
何も言われなければ、この変更に気づく人はほとんどいないかもしれません。
さらに Dalai 氏は、RNA_ADD（RNAに「+」が付いたアイコン）が Blender 本体では一度も使われていないことも突き止めました。そこで削除を提案したところ、「いやいや、アドオンで使ってる人がいるかも」「削除は破壊的変更になるのでは？」と議論が勃発。最終的には「未使用アイコンを放置すると混乱やメンテナンス負荷が増える」という理由から削除が妥当と判断されました。
こうして、一つのアイコンの反転から始まった一連の変更は、破壊的な変更としてBlender 5.0 のリリースノートの「Python APIの変更点」に記載されることになりました。
開発をサポート
これらのプロジェクトはまだ開発中であり、目標を達成するためには専門のデザインおよび開発リソースが必要になります。開発基金にメンバーとして参加するか、一度の寄付でサポートすることができます。
コメント