Geometry Nodeで初めて何かを作ってみたので、このタイミングで所感を整理

投稿日: 2025/06/02 18:29:12

カテゴリ: 3DCG

サムネイル:


youtu.be

Blueskyには少し経緯を書いていたのだけれど、以前からずっとやりたいと思っていた、Geometry Nodeによるジェネラティブ(生成的)、あるいはプロシージャル(手続生成的)な造形というものをやってみた。

実はノードベースなものを扱うのは初めてではなくて、今までGodotやUnity、UE、HoudiniやNotchなどを触ってきたのだけれど、それらのほとんどがシェーダー(グラフ)部分あるいはメッシュ生成部分のみで、メッシュ生成からシェーダまで自分のプログラムで完結したのは、おそらく初めてではないかと思う。

以下、少し長くなるかもしれないけれど、自分にとっては一つ大きな一歩だったので、このタイミングに思考整理を赤裸々に書き連ねておきたい。

3DCGの持つ様々な分野と、分業について

元々マルチにいろんなことをやっていた影響で、3DCG、特にゲームエンジンの仕組みについては詳しい方ではあったのだけれど、自分は特にUV展開を不得意としていて、UVはいつもほぼ自動生成させていた。例えばHoudiniやNotchでは、メッシュ生成だけを楽しんでいて、色は単色をつけたり、出力したメッシュを一度保存して、自動UV展開して、ペイントしたり既存のテクスチャをつけて遊んでいた。(逆にGodotをはじめとするゲームエンジンでは、シェーダを中心に遊んでいた。)

余談になるのだけれど、3DCGというのは、基本的には分業制のところが多いと思う。自分が経験してきた会社は中小ばかりなので、1人で完結しなければならない場合が多かったし、3DCGアーティストをもし内部に持てたとして1人とか数人みたいな、個々人がアーティストやクリエイターとして動く場合が多かったのだけれど、おそらく多くの場合は分業だろうと思う。

例えばライティングならライティングの専門の人がいるし、モデリング専門の人がいる。テクスチャ描く人がいる。エンジニアがいる。それぞれの力で成り立っているというのが普通だと思う。

自分の場合はゲームエンジンのエンジニアとしてはシェーダを中心に仕事をしていて、趣味でずっと造形をしていた関係で個人的にモデリングは詳しかった。で、元々あまり視覚優位な人間ではないので、テクスチャにはさほど興味がなくて、結果的にUV展開が苦手分野として残った。

それでも自分はUV展開は自動ツールに頼っていたので、正直ほとんど不便はなかった。ツールさえ覚えれば作業はできるし、自分に(UV展開という意味での狭い分野で)求められるものにそこまでのクオリティは必要はなかった。

Geometry Nodeに要求される知識: 3DCGのフル知識

ただ、TiXL (Tooll) などのいわゆるVJツールや、今回のようなGeometry Nodeの場合は、やはりある程度広範囲にわたって知識を要求される。モデル生成から最終レンダリングまで完結するということは、そういうことだし、ジェネラティブ(生成的)やプロシージャル(手続き生成的)に造形をするということになれば、それらの仕組みを理解していなければならなくなる。

そういう意味で、自分はずっとcelestialmazeさんというアーティストさんをずっと尊敬していてこの分野の動画はたくさん観ながらも、実際に自分でやろうとは思わなかった理由は、やはり苦手分野をどこか無意識に自覚していたからかもしれない。

ちなみに、celestialmaze さんの肉声というものを先日オンライン開催だったBlender Fes 2025 SSで初めて拝聴したのだけれど、目の前でリアルタイムに何かが組まれていく様子というのは、本当に感激するものだったし、胸を打たれるものがあった。

その分野でまさか自分自身が一歩目に挑戦するとはちょっと想像もしていなかったのだけれど、本当に不思議なものだと思う。

(ちなみにこの項のタイトルにある3DCGのフル知識について、話の流れ的に結局触れることがなかったので最後に補足しておくと、3DCGのフル知識があればあるに越したことはないし、ソロプレイに向いたツールであるのは確かだと思う。ただ、Geometry Nodeがあるからといって全分野を一人でやる必要はないので、ここでも分業は十分可能なはず。また、Processingなどがそうであるように、なんの知識もなくても普通に楽しい。)

Geometry Nodeを始めようと思ったきっかけ: TiXLとクリエイティブ・コーディング

ちなみにGeometry Nodeをやり始めようと思ったきっかけは、実は celestialmaze さんの講演がきっかけではない。

Geometry Nodeをやり始めたきっかけは、TiXL (Tooll) というツールが好きだからという理由が一番あった。

厳密にはTiXL (v4) はまだリリースされていなくて、先日Preview版を使った入門記事を自分で書いたばかり。それも、執筆時点でまだこのとき使ったPreview 3 以降のバージョンはまだ出ていない。

TiXL (Tooll) 自体は1年くらい前からウォッチしていて、自分がMacユーザだったので手が出ないでいた。開発用のデスクトップ機はあったのだけれど、実はこのためにわざわざ中古の5年前くらいのゲーミングノートPCを偶然格安で手に入れたことで、やり始めた。

そもそも普段プログラミングをしていることの多い自分がノードベースのツールをなぜ急に使い始めようと思ったかについては、それはクリエイティブ・コーディングの一種だからという理由で、それ以上の深い意味はないと思う。別にノードだろうがプログラムだろうが、本質はあまり変わらないけれど、最近LuaJITなどのスクリプト言語を書くことが多かったので、リアルタイムに何かが変わっていく様子がわかるというライブコーディングに惹かれていた部分はあった。

なお、「じゃあTiXL (Tooll) 中心にやれば?」といわれたら本当にその通りなのだけれど、まだまだ主にMacユーザな自分にとってはハードルがある部分が若干あるのと、モデリングに関しての不足を補いたいという思いがGeometry Nodeに目を向けさせた。特に、Blenderの場合は元々自分がBlenderについてはある程度操作の知識があるので、どんなノードが存在するかはなんとなく直感的に理解できる。そういう意味でGeometry Nodeは、自分が純粋に3DCGのメッシュをまるで映画マトリックスの世界のように作為的に自由自在に操作できるまでの、つなぎとなるのかもしれないし、このままGeometry Nodeを中心に突き進むかもしれない。(実際、Bevyなどのプログラミングでも、メッシュの直接操作は自分の苦手分野の一つ。)

あと、次の項で主にGeometry Nodeで得られるものについては書いていくつもりなのだけれど、EEVEE (Next)というレンダラーのおかげで、ほぼリアルタイムに様々なことが完結できるのがGeometry Nodeの強いところ。正直、最新のBlender(執筆時点で4.3)ではVulkanも実験的に採用されているし、このままBlenderを使ったリアルタイム・ライブ・コーディングとかVJとかが進化していけば、もう正直自分はそれで十分かもしれない。(この分野はまだ未成熟なので、今後に期待。)

Geometry Nodeで得られるもの: 規則的な内部構造+人為性

Geometry Nodeで何が得られるかといえば、何かしら規則的な内部構造を持つ3DCGが作りやすくなる。

これは昔はHoudiniという非常に高額な3DCGツール(いわゆるDCCツール)が持っていた機能でもあり、CADなどの分野でいえばGrasshopper(こちらも比較的高額…)などが担っていた分野でもあった。

過去にHoudiniやNotchにハマっていたとき、高額なサブスクを契約しようかと思ったことも一瞬あったのだけれど、自分にはその勇気は出なかった。(個人でIndieプランを契約するのが精一杯だったし、それでも十分高額だった。)

そういう意味で、とても良い時代になったなと思う。Blenderがv3になり、v4になる過程で、スカルプト(彫刻)などのそれまで高額だった様々な機能を取り込んでいき、3DCG分野にとっては大きな変化だっただろうし、少し余談にはなるけれど、その間にPlasticityやMagicaCSGなどの新しい動きも生まれていった。

Geometry Nodeは、プロシージャルな造形ができるツールとして、Blenderを中心にいろんなものの中核として既に動いている感があって、Python(+ dll)のみがBlender拡張機能の中心だった時代からすれば、Blenderのアドオンもとても色彩豊かになった。

自分はその分野への憧れがちょっとあったのかもしれないし、元々何かの内部構造を観察したり考えたりするのが好きで、かつ日々の実験や試行錯誤が好きな自分にとっては、もしかすると相性が良い分野なのかもしれない。

なお、あえてGeometry Nodeと通常のプログラミングとの違いをあげるとすれば、Blenderなどはグラフィカルにアーティストが使いやすい道具が揃ったなかでリアルタイムにノードを組み上げていけるので、人のタッチや感覚をすぐに反映できるというのがある。TiXLもそれは似た部分があるのだけれど、ぜひ通常のプログラミングなどでも、ImGuiなどが進化してそのあたりのInterop(行き来)がスムーズになればと願う。(現時点でもBevyなどが徐々にそうなりつつはある。)

今後の造形の方向性

あまり能書きを書き連ねても仕方がないので、思考整理は一旦これくらいにしたい。

今後の個人制作はおそらくGeometry Node等が中心になっていくだろうし、ひょっとすればテクスチャへのベイクなどの関係でSubstanceシリーズくらいまでは手を広げる可能性はあるけれど、当面はGeometry Nodeというおもちゃで遊んでいくのではないかと思う。

一方でTiXL (v4)の正式リリースが自分の本望(他力本願)ではあるので、TiXLが正式リリースされればまた少し方向性が変わってくるかもしれないけれど、いずれにしても当面は、ノードベースでリアルタイムに試行錯誤しながら造形を楽しむ方向性でいきたいなと思う。

余談: ライブコーディングの楽しさと、少しだけTouchDesingerについての所感

本当に余談だけれど、ライブコーディングというのはとても楽しくて、特に音楽分野でTidalCyclesやSuperColliderなどのライブコーディングが積極的に行われている面白さに、Geometry NodeやTiXLの面白さはとても近いと思う。もちろんだけれど、それはTouchDesignerが流行っていることと(自分は詳しくはないけれど)おそらく直接的に関係している。

ちなみにTouchDesignerはやらないのかといわれれば、たぶん今後もやらない。昔、流行ったときに少しだけ触って楽しかったのだけれど、TiXLとは内部構造が似ているようで根本的に違う部分が多々あるし、(本当に自分はTDには全く詳しくないのだけれど、)その多くがGPUのパイプラインやバッファの扱い、そしてコンピュートシェーダに関する部分が多い。そういう意味で自分はなぜか不思議と 1 Geometry Node等のほうがTiXLとの親和性は高いように感じていて、TiXLで利用するモデルの生成という意味でも親和性は強く感じている。2

ただ、もし今後の開発動向に変化があれば、TDもウォッチしていくかもしれない。いずれにしても、クリエイティブ・コーディングの手段が多いこと、選択肢が多いことは、個人的には常に大歓迎だし、今後も自分はいろんなツールでいろんな楽しみ方ができればと願うばかり。

(後日談)その後作ったものについて

2025/06/07 追記

この記事を書いたあと、毎日少しずつスケッチを重ねていて、Geometry Nodes 3 は"画材"としてとても楽しいなと改めて感じている。

日常の些細な風景をスケッチしたり、心象風景をスケッチしたり、そういうことができる画材として、クリエイティブ・コーディングのあるべき姿というのは、こういうものなのかもしれないという感慨を日々噛みしめている。

日々のスケッチはBlueskyやCaraで少しずつ綴っていこうかなと思っているけれど、毎日いろんな日があると思うので、頻度や中身は日によって様々になると思う。そうした、日々の喜怒哀楽や苦楽を、そのままスケッチして残していけたらいいなと思う。

bsky.app

cara.app


  1. Geometry Nodeはたぶん基本的にはCPU処理なはずだと自分は思うのだけれど、実は内部構造がよくわかっていないので、このあたりの考察は勉強ポイントとして次回以降に回したい。ただ、EEVEE (Next) のおかげなのか、あるいはBlenderのブーリアン演算などが高速なおかげなのか、キャッシュのおかげなのか、不思議とリアルタイムにメッシュを生成したりいじったりできる謎さはある。【追記】2025/06/07 GPU実装は実験的なので、基本的にCPU処理であることは間違いないものの、fieldsというPythonのnumpyでいうndarrayのようなもの(おそらくVBOやIBOなどの各種バッファに相当する概念)を基本的に使っていれば、例えばSIMD演算化したりなどの各種最適化が自動的に行われる様子。実際、Repeat Zoneなどのfor文にあたるものを直接使えば重いけれど、fieldsやインスタンスを意識して実装していくことで様々な最適化が図れる様子。このあたりも今後調査を進めてまとめていきたい。↩
  2. 一応TouchDesignerの肩をもっておくと、もちろんTDの良さはたくさんあって、豊富なアドオンでの拡張や、一応サウンド(DSP)なども直接扱えるなと、裾野の広さは魅力だと思う。↩
  3. この記事を書いた当初時点では、Geometry Nodeと単数形で書いていたけれど、英語圏ではGeometry Nodesと複数形での表記が多いようで、ハッシュタグなどもそちらが一般的のようなので、今後はそちらに統一していければと思っている。↩