4月5日、State of UnrealにてついにUE5の正式リリースが行われました。
「まあ多分UE5のリリース発表だろうな…」というのはみんな分かりきってたと思いますが、それに加えてさらなるサプライズとして、例のMatrix AwakensのプロジェクトがCityサンプルとしてDLできるようになりました。
（ちなみに、「Cityサンプルを遊ぶためにUE5インスコするの面倒だな…」とか「容量足りないな…」という方は、Cityサンプルをビルドしてアップロードしてくれてる方がいるので、こちらからDLして遊べます。Cityサンプルプロジェクトは85GBくらいありますが、ビルドしたゲームは17GBくらいに収まってます。↓）
私としては、ちょうどバーチャル日本プロジェクトを立ち上げたところだったので、大規模な都市の作り方のサンプルとして役に立ちそうだ！と期待しました。
しかし、Cityサンプルの中身をのぞいてみると、「これってUE5のサンプルというより実質Houdiniのサンプルじゃね？」と思うくらい、ガッツリHoudiniが使用されています。
たしかに最終的に生成された大規模都市のモデルをリアルタイムで体験できるようになったのは、UE5のNaniteなどの新技術のおかげです。
しかし、その都市のモデル自体はHoudiniによって完全にプロシージャル生成されています。
プロシージャルの時代がやって来る！
Houdiniは3Dモデルのプロシージャル生成が得意なソフトです。
プロシージャルってなんじゃ？というと、日本語で言うと「手続き的」という意味です。
「手続き的」というと、なんか手作業っぽい感じがしますが、実際にはその逆で、「自動生成」みたいな感じです。
それで、これからの時代はプロシージャルモデリングの時代だと言われています。
たとえば、「ある会社では事務作業を全部電卓でやってる」みたいな話を聞いたら、「今さら電卓で手作業で計算してるの！？エクセル使えよ！」と思いますよね。
それと同じノリで、「色んな建物の３Dモデルのバリエーションを手作業で作ってる」と言ったら、「今さら手作業でモデル作ってんの！？プロシージャル使いなよ！」とか言われる時代になって行きそうだという事です。
今までは、ゲームのマップの規模なんてたかが知れていたので、わざわざプロシージャルとかやんなくても手作業でやった方が速くね？という空気でした。
これは、たとえば123+456+789は？と訊かれたら、それだけの計算ならわざわざエクセル使うのは大げさで、電卓で計算した方が手っ取り早いみたいなもんです。
しかし、Cityサンプルでは4km四方というメッチャクチャ広い規模の都市を作る必要がありました。
これは、手作業で作ってたら10年くらいかかるかもしれません。
しかし、Houdiniなら数時間放置するだけで大規模都市をプロシージャル生成してくれます。
オープンワールドのゲームがこれから増えていったりして、ゲームのマップはどんどん広くなっていってます。
もはや手作業で世界を作ってたら一生終わりません。
オープンワールドゲームだけではなく、デジタルツインやメタバースの分野でもプロシージャル生成は必須になっていくであろう技術です。
デジタルツインなんかは下手すると地球全体をバーチャルで作り直すハメになるかもしれませんから、手作業では絶対に不可能です。
プロシージャルモデリングならゲームマップの規模がどんだけ大きくなって行ってもスケールします。
Cityサンプルは現時点での技術の集大成
Houdiniのプロシージャル技術を駆使すれば、超大規模な都市なんかも丸っと生成できるかもな～みたいな想像はみんなしてたと思いますが、「でもそんなの作ってもポリゴン数多すぎてゲームで表示できるわけ無いわ」って感じだったと思います。
そう、UE5が出るまでは…。
UE5のNaniteによって、Cityサンプルの超高精細、超大規模な都市モデルをリアルタイムで描画する事が可能になりました。
そしてUE5はリリースされていきなりその可能性を実証してみせたという事です。
そして、Cityサンプルには都市を生成するためのHoudiniプロジェクトなどのもろもろ全てのテクノロジーが公開されてます。
今後、Cityサンプルが実証してみせた技術をベンチマークとして、ゲーム世界のプロシージャル生成の流れが普及していく事になると思います。
それはいいんですが、私はHoudiniの使い方はよく分かりません。
ですから、たとえばCityサンプルをいじって日本の都市が作れるようにしたい！と思ってもどうやればいいのかサーパリ分かりません。
Cityサンプルにはちゃんと交通規則を守って歩く群衆がいますが、「じゃあ自分のゲームマップにこの群衆を入れたい！」とか思ってもサーパリ分かりません。
導入されているテクノロジーが高度過ぎて、ちょっとやそっとの素人には全く扱う事が不可能なサンプルだなと思います。
そもそも、Cityサンプルの群衆や車は、今までのUEのデフォルトのアクタ、コンポーネント、ナビゲーションメッシュ、ビヘイビアツリーのような当たり前の仕組みは使われてません。
MassEntityという、Unityで言う所のECSのような新しい仕組みが使われてます。
つまり、既存の仕組みでは大量の群衆を制御するのにまったくパフォーマンスが足りなかったという事でしょう。
群衆が歩くルートも、ナビゲーションメッシュではなく、Houdini上で自動生成された、大量のスプラインパスのようなメタデータで制御されてます。ZoneGraphってヤツです。
それで、MassEntityはまだ実験的機能であり、ブループリントからは使えず、C++でしか扱えません。
それどころか、ドキュメントは今のところほぼ概要しか書かれてません。
https://docs.unrealengine.com/5.0/ja/mass-entity-in-unreal-engine/
さらに、その概要ですら何のこっちゃサーパリ分かりません。
私は自分のゲームとかにCityサンプルの群衆とか車とか取り入れたいと思ってましたが、結局のところ、現状ではさっぱり意味不明で手の出しようがありませんね。
Cityサンプルは、HoudiniとUE5の素晴らしい可能性を実証する事はしましたが、その技術をド素人でも扱えるように噛み砕いて提供してくれる事はしてくれてなさそうです。
まあひとまず１年くらい寝かしておけば、もっとドキュメントが充実したり、頭のいい人が噛み砕いて分かりやすく解説してくれたりしてるかなと思います。
Cityサンプルはシミュレーションだけどゲームじゃ無い
このように、Cityサンプルが現時点での技術の到達点を実証してくれましたが、それと同時に別の事も実証してしまっていると思います。
Cityサンプルは、極めてすぐれた都市の超リアルなリアルタイムシミュレーションです。
しかし、これは全然ゲームではありません。
私が最近提唱してる、「ゲーム性とシミュレーションは別物」理論をこれ以上ないくらいに実証してしまっていると思います。
要するに、ゲームとして面白くないという事です。
ゲームは、デザインされた体験だと言ってしまえるかもしれません。
それに対して、現実の都市空間というものは、体験がデザインされた空間ではありません。
都市と言うのは単に、効率よく沢山の人々が生活するための空間です。
ですから、都市をリアルに作れば作るほど、それは詰まらなくなるという事でしょう。
Epicはメッチャ苦労してちゃんと信号を守って移動する群衆や自動車を実装しましたが、歩道で信号待ちする体験なんてなんも面白くありません。
考えてみれば、Matrix Awakensの実際のゲームプレイはハイウェイでのカーチェイスシーンでした。（ちなみにCityサンプルにはカーチェイスパートは含まれていません。MatrixのIPが含まれてるから）
その肝心かなめのハイウェイ道路は、レベルデザイナーによって“手作業”でパスがデザインされています。
Matrix Awakensを一つのゲームとしてみた場合、メチャクチャ苦労して制作された、超リアルなシミュレーションされた大規模都市というのは単なる背景でしかありません。
そして、肝心のハイウェイ部分はプロシージャル生成ではなく結局手作業でデザインされてます。
ここに話の本質的な部分があります。
”プロシージャルは体験のデザインでは無い”らしいという事です。
我々が生きているありのままの現実世界には、デザインされた体験は基本的に仕込まれてません。
しかし、空き地に手を加えて子供たちが楽しめる公園を作ろう！としたら、そこには体験がデザインされる事になります。
世界に手を加える事で体験がデザインされるわけです。
デザインする、手を加えるというのは、本質的にプロシージャルではなく手作業なのかもしれません。
というわけで、ゲームにプロシージャルを導入する際は、使い方をよく考えた方がいいかもしれないという話でした。
散々プロシージャル褒めた後にディスか？と思うかもしれませんが、しかしCityサンプルをゲームではなくシミュレーションとして見ると、現実の再現性は凄まじいです。
つまり、プロシージャルはシミュレーションに対して恐ろしいくらいのパワーを発揮すると言えるでしょう。
Cityサンプルを発展させれば、都市の人流シミュレーションや渋滞予測シミュレーション、自動運転AI学習などの様々なシミュレーションに活用できそうです。
プロシージャル、HoudiniかBlenderか
プロシージャルモデリングにおいてはずっとHoudini一強の時代が続いてましたが、最近はBlenderにもジオメトリノードが搭載されました。
Houdiniは素晴らしいソフトですが、問題点もあって、まずライセンスが結構高いです。
そして、バージョン間でファイルの互換性がありません。
Houdiniのインディー版で作られたファイルはHoudini通常版では開けません。
まあビジネスモデル的に仕方ない制約ですが、この問題によって、誰かが素晴らしい建物のプロシージャル生成システムを作っても、それをシェアし合ったりするのが難しく、なかなか技術共有が進みません。
それに対して、Blenderはオープンソースソフトウェアなので、当然ファイル互換性に縛りとかはありません。
今後はBlenderでプロシージャルモデリング技術の共有が進んでいくと思われます。
というかすでにネット上で素晴らしいジオメトリノードが共有されまくってます。
とは言え、Houdiniの方が技術的に断然先を行っているので、今後数年間はHoudiniの優勢は変わらないと思いますが、その先はどうなるか分かりません。
ですから、これからプロシージャルモデリングを学習するならBlenderのジオメトリノードから始めてみるのもアリな気がします。それで機能的に物足りなくなったらHoudiniに移行するという流れもアリでしょう。
また、UnrealEngineやUnityなどのゲームエンジン上でHoudiniのプロシージャル生成が使用できる、Houdini Engineというのもあります。
これについては、Blenderのジオメトリノードでも同じような事ができる、Altermeshというものがあります。