2025年7月24日（現地時間）- 2025年7月に開催されたジオメトリノードワークショップの内容が共有されました。
このワークショップでは、様々なジオメトリノードとBlenderの貢献者がアムステルダムのBlender HQに集まり、多くの設計トピックについて議論が行われました。
ここではその内容を紹介したいと思います。
目次
これまでの進捗状況
前回のワークショップから8ヶ月が経ちましたが、以下のリストはそれ以降に取り組んできた主なトピックに関する簡単なアップデート内容となっています。中には、最近のBlender 4.5 LTSリリースに含まれたものもあります。
- メッシュ法線：新しいメッシュ法線を設定(Set Mesh Normal)ノードが追加され、ジオメトリノードでカスタム法線を扱えるようになりました。これは、近年の様々な変更、特に自動スムーズに関する変更によって可能になりました。
- インポートノード：ディスクから直接、様々なファイルタイプ（.obj, .stl, .ply, .vdb, .csv, .txt）をインポートできるようになりました。
- グリースペンシル：アトリビュートを設定するための様々なビルトインノードが追加されたことで、ジオメトリノードでのグリースペンシルデータの扱いが簡素化されました。
- 表示ジオメトリをオブジェクトに：ジオメトリノードの出力を個別のオブジェクトに変換できるようになり、編集やエクスポートが可能になりました。
- ノードエディタのUX：ノードエディタには、特にフレームノード、エラーハンドリング、ノード検索、その他に関連する様々なUX改善が行われました。
以上の機能はBlender 4.5 LTSリリースで追加されました。詳細は以下の記事をご覧ください。
- クロージャーとバンドル：これは現在実験的な機能であり、間もなく準備が整う予定です。
- ヘアープロジェクト：これはまだ進行中です。物理シミュレーションを設定するための一般的な宣言的システムは、クロージャーとバンドルで可能になります。ソルバーの開発はまだ進行中です。
- リスト：リストの初期バージョンが間もなく実験的機能としてマージされる予定です。
- ソケット形状：ソケット形状の更新は現在、実験的機能として利用可能であり、いくつかの仕上げ作業が終われば完了します。
議論されたトピック
ヘアーダイナミクス
開発チームが目指している全体的な宣言的デザインに変更はなく、開発作業は、クロージャーとバンドル、ソルバー、リストを含む複数の面で進行中です。
宣言的デザインの詳細は以下の記事をご覧ください。
今回のワークショップでは、達成したいマイルストーンをもう少し具体的に設定することに焦点が当てられています。
その中で特に重要だったのは、「プロダクション用のファイルを作れるようなシステムを構築すること」と、「誰でも使いやすく、ヘアシミュレーションを作成できる適切なワークフローを整えること」では、求められるシステムに大きな違いがあるということです。
まず最初のステップとして、最終的に目指す仕上がりに近いヘアシミュレーションを含んだ .blend ファイルを作成する「垂直スライス（ユーザーが体験する一連の流れを丸ごと試作すること。）」が構築されます。この段階では、理想的なワークフローがまだ完全には整っていない可能性もありますが、この試作を通して、全体の進むべき方向性を確認することが目的です。
その次のマイルストーンは、ソルバーをリリースし、その周りにワークフローを構築することとなっています。
リスト
全体的なデザインに変更はありません。今回のワークショップでの主な目標は、実験的機能としてマージできる優れた最小限の機能セットを定義することでした。PRはすでに利用可能です。
最初の実験的機能には、新しいソケット形状と3つのノードが付属します。1つはリストを作成するため、1つは個々または多くの要素を取得するため、もう1つはリストの長さを取得するためのものです。最適ではありませんが、これらのノードを組み合わせることで、連結やスライスなど、他の重要なリスト操作をすでに構築できます。
カラーランプとカーブマッピング
Blenderではこれまで、ノードグループが「カラーランプ」や「カーブマッピング」を入力として扱えないという制約が長らく存在していました。この制限は、ノードの再利用性を損なう要因の一つです。というのも、これらのウィジェットは、現在サポートされている他の入力タイプとは性質が大きく異なっているためです。
しかし、クロージャーの導入により、この問題に対してより明確な解決の道が開かれました。実際には、カラーランプもカーブマッピングも、float値からcolor値への変換を行う関数にすぎず、関数という形で定義できれば、クロージャーとしてノードグループに渡すことが可能となります。
このような高度な仕組みを導入しても、ノードグループを利用するユーザーがクロージャーの技術的な詳細を理解している必要はありません。そこで現在検討されているのが、ノードUI上に対応するウィジェットそのものを表示する仕組みです。これには、クロージャー型の入力に対して、デフォルトでどのウィジェットを用いるべきかを指定する「サブタイプ」を持たせることで対応できます。また、組み込みのクロージャーをユーザーが定義したものに置き換えることも可能です。
最初のPRはすでに公開されており、ノードUIには省スペースのためウィジェットが折りたたまれた状態で表示される仕様になっています。ユーザーがクリックすることで、ウィジェットを展開することが可能です。なお、これらのウィジェットをジオメトリノードモディファイア上でも表示できるようにするには、さらに技術的な対応が必要であり、まだ実装は完了していません。
ノードグループに公開されたカーブとカラーランプ。
ノードグループインターフェースレイアウト
現在、ソケットを任意にネストされたパネルにグループ化する機能があります。これにより、ビルトインモディファイアに見られるすべての（または少なくともほとんどの）レイアウトを置き換えることができるようになりました。しかし、現時点ではいくつかの制約も残っており、たとえば複数のプロパティを1行に並べて表示することができません。
この課題に対する解決策として、ノードグループインターフェースのツリービューで、より多くの種類のレイアウトを作成できるようにする方針が採られました。これに伴い、従来「パネル（Panel）」と呼ばれていたものは「レイアウト（Layout）」として再定義され、そのレイアウトは「パネル」「列」「行」のいずれかのタイプを持つ形となります。これはBlenderのPython APIでレイアウトを構築する方法と似た設計です。
このようなUI設計の中で重要なのは、インターフェースをBlenderらしく見せることです。たとえば、パネルはソケットの後に配置されるべきだというルールがありますが、行についてはその限りではありません。問題は、たとえUI構築中の一時的な段階であっても、無効な状態を作れないように設計することで、オーサリング作業が煩雑にならないようにすることです。
そこで採用されたアプローチは、アセットを作成する段階ではツリービューUIからすべての制約を取り除くというものです。ただし、ノードグループを実際に使用する段階になると、各種の制約が自動的に適用されます。たとえば、ツリービューでパネルがソケットより前に配置されていたとしても、実際の使用時にはソケットの後に表示されるようになります。また、無効な状態になっている場合は、ノードグループの作成者に警告が表示されます。
ただし、UI構築の段階でこうした制約をすべて強制すると、すでに十分に手間がかかるうえ、今後さらに分かりづらく複雑な制約が加わっていくことを考えると、作業の煩雑さが増していく可能性があります。
ソケットとレイアウトのオプション
個々のインスタンスの表示
新たに提案された機能のひとつに、「スプレッドシートで選択したインスタンスを3Dビューポートでも表示する」というアイデアがあります。これは、大量のインスタンスを含む複雑なジオメトリの中から、特定の部分だけを簡単に確認できるようにすることが目的です。
ただし、この方法（スプレッドシートでインスタンスを選択して表示する）は機能する可能性はあるものの、最初のアプローチとしては理想的ではありませんでした。というのも、多くのユーザーがスプレッドシートを使わずにジオメトリノードを利用しているからです。
それでもこの機能には意味があるので、現在ではこの機能を「ローカルビューの特殊なケース」として扱うのが最も適した方法と考えられています。つまり、個々のオブジェクトだけでなく、インスタンスやサブオブジェクト単位でもローカルビューに切り替えられるようにするという構想です。ただし、そのための具体的なUI設計については、まだ明確には定まっていません。
任意のデータを表示
「バンドル」「グリッド」「リスト」といった新しいデータ構造の導入に伴い、データの表示方法にも新たなアプローチが求められています。現在のビューアノードは、基本的に1つのフィールドを持つジオメトリしか表示できず、他の種類のデータに対しては実用的とは言えません。
この課題に対しては、主に2つの方向性が検討されています。ひとつは既存のビューアノードを汎用化する方法、もうひとつは用途ごとに異なるビルトインビューアノードを用意する方法です。現時点では、汎用的なビューアノードをひとつ設ける方がより効果的だと考えられています。
この汎用ビューアノードは、動的に型付けされた複数の入力を受け取れるように設計されており、任意のデータを接続できるようになります。リンク数も2つ以上に対応可能です。ノードは受け取ったデータの種類を確認し、それに応じて表示方法を自動的に決定します。
既存の「Ctrl + Shift + 左クリック」でビューアを切り替える操作は、少し分かりづらくなる可能性がありますが、少なくとも現在と同程度の使いやすさは維持できる見込みです。
カスタムビューア
上記に関連して、「カスタムビューア」の話題も挙がっています。これは、Viewerとして扱われるべきノードグループのことで、入力データに対して追加の処理を行い、標準のビューアノードとは異なる可視化を提供できるようにするものです。
このカスタムビューアは、Ctrl + Shift + 左クリックによる既存の操作にも対応し、作成や選択が簡単に行える設計が求められています。また、表示対象となるデータの入力と、ビューアの設定を行うための入力を明確に区別できるようにする必要があることも分かってきました。
なお、この話題は、3Dビューポート上で属性データを表示するオーバーレイ機能とは別のものですが、そちらも今後さらに機能が強化される予定です。
デバッグビュー
ノードグループに、デバッグ情報を表示するためのビューアノードをあらかじめ組み込んでおくというアイデアがあります。
これにより、作者だけでなくユーザーにとっても有益な情報を表示できるようになります。Groupノードやモディファイアを使用する際に、これらのデバッグビューを有効化することで、ノードグループの内部処理を可視化し、理解を深めることが可能になります。
UIの具体的な形はまだ明確ではありませんが、デバッグビュー用のトグル（切り替えスイッチ）を、他のノードグループの入力と並列に配置するのが良く、専用のパネルを設けるよりも、より自然な操作感が得られると考えられています。ただし、デバッグビューを有効にしても最終結果には影響しないことが、ユーザーにとって明確に分かるようにする必要があります。
さらに理想的な仕組みとしては、ノードグループがネストされたノードグループのデバッグビューを継承できるようにすることで、柔軟な構成が可能になります。
ジオメトリノード機能を他のノードツリーにも展開
現在、リピートゾーンや、今後導入予定のクロージャやバンドルなど、先進的なノードツリー機能の多くはジオメトリノードでのみ利用可能です。しかし、技術的にはこれらの機能はシェーディングノードやコンポジットノードでも有用です。
これらの機能がジオメトリノードに限定されている理由は、評価システムが汎用的に設計されており、機能の活用に最も適しているためです。ただし、他のノードツリーでも限定的な形で機能を導入することは有益だと考えられています。
比較的シンプルな解決策としては、ユーザー定義のノードツリーを事前に処理し、リピートゾーンなどの高度な機能をインライン化する方法があります。すでにこの処理を行うプルリクエスト（PR）も存在しています。ただし、ジオメトリノードと比べると制限があり、例えば繰り返し回数は定数でなければならないなどの条件があります。それでも、シェーダーノードにこれらの機能を早期に導入するための妥協案としては有効と考えられています。
もうひとつの選択肢として議論されているのが、インライン化されたノードツリーのための新しい中間表現を導入する方法です。これは技術的には可能ですが、プロジェクトの規模が大きくなり、将来的にシンプルな方法よりも有用になるかどうかは不透明です。もし将来的にレンダラーが高度な評価機能を標準でサポートするようになれば、事前処理自体が不要になる可能性もあります。
一方で、コンポジターの場合は状況が少し異なります。というのも、コンポジターの評価方式はジオメトリノードに近く、左から右への単純なデータフローで、サンプルごとではなく一度だけ評価されるためです。これにより、中間表現を必要とせず、より直接的に高度な機能をサポートしやすいという利点があります。また、元のノードツリーに近い構造を保つことで、ユーザーが見ている内容と評価される内容の対応関係が明確になり、デバッグもしやすくなります。
アセットメニューパス
ノードグループのアセットは、ノードやモディファイアの「追加（Add）」メニュー、さらには3Dビューポートのヘッダーやノードツール用メニューなど、UIのさまざまな場所に表示される可能性があります。現在は、アセットカタログのパスがそのままメニューパスとして使用されていますが、これは単純なケースではうまく機能するものの、制約もあります。
たとえば、同じノードグループがノード追加メニューとモディファイア追加メニューの異なる場所に表示されることがあります（例：Subdivide操作）。また、異なるオブジェクトタイプで使用されるノードツールでも同様の問題が発生します。
このような課題に対して、今後はカタログパスとメニューパスを分離し、用途に応じて1つのアセットに複数のメニューパスを設定できるようにすることが望まれています。メニューパスをカタログごとに保存する方法もありますが、現時点ではアセット自体にメニューパスを保存するのが最も柔軟で、アセット作成者にとっても制御しやすいと考えられています。
さらに、メニューパスに変数を使用することも可能です。たとえば、ツールメニューパスに {OBJECT_CONTEXT}/Transform/... と記述すれば、現在のモードに応じて Object/Transform/... や Mesh/Transform/... にマッピングされるようになります。
ボーン情報
新たに「Bone Info」ノードを導入するためのプルリクエスト（PR）が提出されています。このノードの目的は、アーマチュアから情報をジオメトリノードに取り込むことです。ワークショップでは、この機能がジオメトリノードにおけるアーマチュアの将来的な扱いにどう関わってくるかについて議論されました。また、初期バージョンで公開可能と考えられるソケットの構成についても合意が得られているとのことです。
もちろん、特定の1つのボーンから情報を取得するだけでは、アーマチュア全体を扱う場合と比べて制限があります。しかし、これは「どちらか一方を選ぶ」という話ではありません。特定のボーンに固定されたノードでデータを取得することには利点があり、依存関係グラフがジオメトリノードが何に依存しているかを正確に把握できるため、アーマチュア全体への汎用的な依存を作成する必要がなくなります。この仕組みは、ジオメトリノードの出力が同じアーマチュア内の他のボーンを駆動するようなケースでは、依存関係の循環（サイクル）を避ける必要があるため特に重要です。
アセットのバージョニング
Blender周辺のアセットエコシステムが拡大し、Blender本体にもアセットが同梱されるようになった現在、アセットの更新とユーザーへの通知がますます重要になってきています。
Blenderでは、「packed asset（ファイルに埋め込まれたアセット）」において、アセットが変更されたかどうかは検出できます。しかし、ディスク上のバージョンが現在使用中のものより古いのか新しいのかは判断できません。この問題を解決するには、ユーザーが明示的に管理できるバージョン番号が必要です。理想的には、セマンティックバージョニング（例：v1.2.3）を用いる形が望まれます。
バージョン番号の記録方法にはいくつかの選択肢があります：
- アセットが入った
.blendファイル内に保存する - ファイル名に含める（例：
materials_v1.0.0.blend） - 別の設定ファイルに記録する
現時点では、ファイル名にバージョンを含める方法が最も管理しやすいと考えられています。この方法には、「そのファイル内のすべてのアセットが同じバージョンになる」といった制約がありますが、実用性は高いと見られています。
最低対応Blenderバージョンは、一般的にアセット単体ではなくファイル全体に紐づけられることが多く、現状では「そのファイルが最後に保存された時のBlenderバージョン」がそのまま使われています。
クロージャーとバンドル
Closures（クロージャ）と Bundles（バンドル）は、以前の投稿で紹介されました。これらは宣言型システムを構築するうえで不可欠な要素です。どちらの機能も、Blenderではしばらくの間「実験的機能」として提供されています。
今回のワークショップでは、主に細部を改めて確認し、チーム内で方向性の認識が一致していることの確認が行われました。
また、ソケットの自動入力（automatic population）に関しては、改善の余地があるいくつかのケースが見つかりました。また、これらの機能が正しく使用されていない場合に表示される警告メッセージの追加についても検討されました。
今回議論された主な機能変更は、Bundle内のアイテム名に特定の記号文字を使用することを禁止することです。この変更は、root/forces/wind/... のようなネストされたBundle構造内でパスを指定できるようにするために必要となりました。
まとめ
以上が今回のワークショップで議論された主な内容となります。
他にもジオメトリノードの将来的な方向性に関して、いくつかの話し合いが行われたようです。具体的な実装には至っていませんが、たとえば、公開方法を変更することで入力ソケットインターフェースを拡張するより一般的な方法（例：ジオメトリソケットをオンデマンドでオブジェクトまたはコレクション入力として公開する）やマージ準備が整った複数のPRに署名し、Blenderのアーキテクチャとコードに関する一般的な議論などが行われたとのことです。
ワークショップの生のメモも公開されていますので、さらに詳しく知りたい方はそちらご覧ください。
開発をサポート
このプロジェクトは初期段階にあり、目標を達成するためには専門のデザインおよび開発リソースが必要になります。開発基金にメンバーとして参加するか、一度の寄付でサポートすることができます。
