Making the Procedural Buildings of THE FINALS

そのシステムは、やがてチームが現在「Building Creator」と呼んでいるものへと発展しました。

これから、Adrian Björkerud 氏にシステムの詳細を解説していただきます。また、完全に破壊可能な建物をいかに実現した、ツール設計の意思決定についても明らかにしていきます。

ゲーム用の建物制作において、破壊という要素は特有の複雑さをもたらします。アセットを完全に破壊可能で、内部を移動できるインタラクティブなものとして機能させる場合、従来の 3D コンテンツ制作で一般的だった効率化テクニックの多くは適用できなくなります。

たとえば、多くのゲームで建物は単なる外壁 (中空の殻) にすぎません。プレイヤーが中に入ることがないからです。ところが「THE FINALS」では、プレイヤーは破壊可能な建物のあらゆる場所に入り、移動し、その上に立つことまでできるとされています。つまり、廊下、階段、部屋、屋根裏部屋にいたるまで、すべての建物には完全な内部空間がなくてはならないということです。しかも、そのすべてに正確なコリジョンを設定しなければなりません。

破壊可能な建物を作るにあたり、もう 1 つのよくある制約は、すべてのジオメトリをゲームプレイ中ではなく、あらかじめ粉砕しておく必要がある点です。リアルタイムの粉砕処理は、テンポの速いマルチプレイヤーゲームでは計算負荷が高く、予測不能な挙動を招く恐れもあります。そのため「THE FINALS」の破壊可能なアセットでは、あらかじすべてのアセットを Houdini で細かいピースに粉砕しておき、銃撃や爆発などのダメージを受けるまで、その継ぎ目が目立たないように巧妙に隠しています。

このアプローチによる粉砕では、ツールがクリーンな内側フェースを自動的に生成できるよう、入力ジオメトリは完全に水密の状態 (つまりオープンエッジや繋がっていないサーフェスが存在しない) であることが求められます。

つまり、「THE FINALS」のコンテンツ制作には、従来とは異なる考え方で取り組む必要があるわけです。チームは現在 Houdini を用いた堅牢なパイプラインがあり、建物の粉砕やイテレーションはわずか数分で完了します。それでもなお、アーティストには「一歩先を見越した設計」が求められます。つまり、制作の初期段階から、水密のジオメトリ、適切に作成されたコリジョンメッシュ、クリーンなトポロジーを確保しておく必要があります。

多くのプロシージャルな建物生成ツールは、特定の建築様式を前提に設計されています。ビジュアルの一貫性が重視され、ほとんどの建物が共通の視覚言語に従うようなゲームでは、非常に有効なアプローチです。

Adrian Björkerud 氏はこれまでの経験から、プロシージャルなツールは概ね 2 つの大きなカテゴリーに分類されると考えるようになりました。

• リジッドなツール： 設定可能なパラメータは限られ、一貫性を保つとともに、ユーザによるミスの発生を最小限に抑えます。自動 UV アンラップツールや LOD (詳細レベル) 生成ツールなどがこのカテゴリーに入ります。こうしたツールの価値は、反復作業の効率化と予測可能な結果にあります。

• クリエイティブなツールセット：固定されたひとつの手順に従うのではなく、柔軟なコンポーネント群として構成されたツールです。アーティストはこれらを自由に組み合わせて、幅広い結果を得られます。良い例が SpeedTree です。ヤシの木からオークの老木まで、ユーザは、ノードを繋ぎ合わせることで多様な植生を作成できます。

このモジュール性には、いくつかの重要なメリットがあります。

• 創造面の自由 - アーティストは建物に必要な機能を選択し、ニーズに合わせてそれらを組み合わせることができます。

• 拡張性 - 既存のコンテンツを損なうリスクを最小限に抑えつつ、新しい機能を随時追加していけます。

• メンテナンス性 - ノード同士は緩やかに関連付けられている状態であるため、バグの修正や機能強化を特定のノードに限定して実施できます。

• イテレーションの高速化 - 各フィーチャノードの依存関係が明確に定義されているため、小さい変更であれば、再クックはグラフの一部のみで済みます。たとえば、窓を調整しただけでは、建物全体は再クックされません。

Building Creator ノードは、1 棟の建物を表すオブジェクトレベルの HDA です。壁の厚みや階高など、建物全体に関わる少数のグローバルパラメータを提供し、各フィーチャノードはそれらを共有して整合性を保ちます。

このノード内の SOP ネットワークで、建物が実際に組み立てられます。アーティストはここにフィーチャノードを配置し、それらを接続してノード構造を定義します。Building Creator ノードそのものはジオメトリを生成しません。各フィーチャノードが動作するための共通のコンテキストと枠組みを提供します。

フィーチャノードは、SOP レベルの HDA で、Building Creator ノード内の SOP ネットワークに配置されます。各ノードが、壁、基礎、床、屋根、窓、ドアといった特定の建築要素を生成します。つまり、1 つのフィーチャノードが建物の特定の 1 つの要素を表現します。

ほとんどのフィーチャノードは順序に依存しません。つまり、ほぼ自由な順序で配置できますが、「窓を配置する前には壁が必要」といった、論理上の例外は一部存在します。また、多くのノードにはカスタムの Viewer State ツールが組み込まれており、ビューポート上で直接的かつ直感的に操作できるようになっています。一部のノードでは、このツールがワークフローの核を成しています。

フィーチャノードは、基本的に 2 つの入力と 2 つの出力を持っています。

• 1 つ目の入力/出力は建物のジオメトリを受け渡すためのもので、ここに各建築要素が追加されます。

• 2 つ目の入力/出力は、低解像度のブロックアウトメッシュや追加の補助データを受け渡すためのものです。下流のノードは、これらを使って整列や配置、さらなる処理を行います。

Building Creator HDA でブロックアウトを参照したら、アーティストはその SOP ネットワークの中に入ります。ここが実際の構築場所です。ブロックアウトと生成されたジオメトリがネットワーク内を流れ、そこにフィーチャノードを配置していくことで、建築要素がレイヤーのように重ねられていきます。

以下が標準的なワークフローです。

1. Building Creator HDA でブロックアウトメッシュを参照します。

2. Building Creator HDA の SOP ネットワークの中に入ります。すると、ブロックアウトが自動的にフィーチャノードのチェーンへと供給されています。

3. 壁、床、窓、屋根、ディテールなど、その建物に適した順序でフィーチャノードを追加します。

4. 各フィーチャノードは入力ジオメトリストリームを読み取り、そこに自身の要素を追加していきます。

5. コリジョンとオクルーダーの生成は、アーティストによる調整を必要としないため、チェーンの最後に処理されます。

この構造により、ワークフローの柔軟性が保たれます。アーティストはどの建築要素を含めるか、またどう組み合わせるかを選択するだけでよく、データの流れや依存関係はノードチェーンが自動的に処理してくれます。開発の観点では、デバッグが容易になるというメリットもあります。建物を構成するすべての要素が、ネットワーク内で可視化および整理されているからです。

以上の解説を踏まえたうえで、主なフィーチャノードの概要と実際の運用方法を見ていきましょう。

Exterior Walls フィーチャノードは、各階を分割する水平方向のエッジループと、建物のファサードを分割する動的な垂直方向のループによって構成された、壁ジオメトリを生成します。この構造化されたトポロジーは、下流ツールの土台として機能し、窓の配置、マテリアルの適用、さらにはコーニスやモールディングといった建築ディテールの挿入を可能にします。

このノードにはカスタムの Viewer State が組み込まれ、トポロジーの生成を直感的に制御できます。壁のセグメントやコーナー単位で垂直方向のエッジループの間隔をインタラクティブに調整できるので、壁の区切りに対して精密な制御が可能です。

Floors フィーチャノードは、建物の各階に構造的な床スラブを生成し、外壁の内側フェースに揃えて配置します。このノードには、主に 3 つのパラメータが用意されています。

• Floor Height – スラブ間の垂直方向の間隔。

• Floor Thickness – 各スラブの厚さ。

• Clearance Threshold – 対象のスラブと上の天井との間に必要な最小スペース。利用可能な高さがこの閾値を下回る場合、スラブは生成されません。

Room フィーチャノードは、建物と交差するメッシュボリュームを入力として受け取ります。その交差した場所に沿って内壁を生成し、すべての囲まれたジオメトリを識別子 ("LivingRoom"など) でタグ付けします。これらの識別子は、下流で参照可能なタグとして機能します。これにより、他の Room フィーチャノードが特定のエリアにだけ小部屋を追加したり、または指定した場所には部屋を生成しないようにするといった、選択的な処理が可能になります。

Room フィーチャノードと共に用いられるのが Room Style フィーチャノードです。このノードは、特定の部屋タイプのビジュアルスタイルを定義します。識別子 ("LivingRoom"など) を使用して、モールディング、コーニス、ランプのソケット、コンセント、ヒーター、専用のマテリアル設定など、そのスタイル固有の要素を適用できます。

このように空間の定義とスタイルの装飾を切り離すことで、環境アーティストは一貫性を保ちながら、柔軟かつ容易に内部空間のイテレーションやカスタマイズを行えるようになります。

モナコマップの制作でこれらのツールを使い始めたチームは、すぐに問題に気付きました。内部空間の数が多すぎて、プレイ中に大きな混乱を招きかねなかったのです。マップには 30 以上のユニークな建物が含まれ、それぞれに 1 階から 5 階までのフロアと屋根裏部屋が存在します。バリエーションの豊富さは魅力でしたが、実際には予測しづらく一貫性に欠けるレイアウトとなり、プレイヤーを混乱させる恐れがありました。

この問題を解決するため、チームは内部空間のルールセットを明確に定め、モナコのすべての建物がそれに従うようにしました。

• 1 階の正面玄関を開けると必ず廊下につながっており、その左手には階段が配置されている。

• 廊下の右手には必ず裏口があり、プレイヤーが建物をそのまま通り抜けられるようになっている。

• 階段を登りきったところには、必ず屋根裏部屋へと続く昇降階段が設置されている。

こうした一貫性を持たせることで、プレイヤーは一度でもモナコの建物を探索すれば、ほかの建物も直感的に理解できるようになりました。たとえ建物によって外観やディテールが異なっていても、中で迷うことはありません。

室内に家具を配置することも試しましたが、ゲームのテンポと合わないことがすぐに明らかになりました。全速力で疾走するプレイヤーが椅子やテーブルにたびたび引っかかってしまうため、スムーズで予測可能な移動を優先し、あえて家具を取り除きました。

プロシージャルな部屋生成システムにこれらのデザインルールを組み合わせることで、モナコの建物は画一的でなくリアルな印象を保ちながら、激しい戦闘中でも把握しやすくプレイしやすいものとなりました。

フィーチャノードは、建物のブロックアウトメッシュをガイドとして使用し、これらのカスタムメッシュをコピー、移動、変形、結合して配置します。これにより、アーティストは建物の外観デザインを自在にコントロールできるようになります。入力メッシュがツールの仕様を満たしていさえすれば、どんな形状、詳細度、およびマテリアルセットアップのモジュールでも作成できるからです。

窓やドアのように、壁などに開口部が必要となる要素があります。これらは一般にツール内でモジュールとして参照され、以下の 3 つのコンポーネントで構成されています。

• ビジュアルメッシュ - 実際にゲーム内に表示されるメッシュで、建物のメッシュの一部です。

• ブーリアンメッシュ - 建物のジオメトリの必要な箇所に穴を開けるために使用されます。

• メッシュソケット - Unreal Engine で追加のディテールを生成するために使用されます。

このワークフローにより、モジュールは建物の表面にどんな断面や形状の穴でも開けることが可能です。曲線を描くアーチ道や円形の窓なども、余計な手間をかけずに作成できます。

モジュールという概念は、特定のノードやワークフローに限定されるものではありません。むしろ、複数のフィーチャノードで使用できる柔軟なコンポーネント群として設計されています。特に汎用性が高く広く使われているのが、Manual Module ノードです。

• さまざまなサーフェス、エッジ、フロアラインなど、主な建築要素にスナップできます。

• 配置した各モジュールを、ローカル空間またはグローバル空間で手動でトランスフォーム (移動、回転、スケール) できます。

• ブーリアンフィルタにより、建物ジオメトリのどの部分をブーリアンの対象にするかを制御できます。

通常、1 つの Manual Module ノードで 1 種類のモジュールを処理します (ドアに 1 つ、窓に 1 つなど)。これらのノードをメインの Building Creator ノード内でチェーン接続することで、その建物全体のモジュール要素を組み上げていきます。

このアプローチでは、プロシージャルなパイプラインのメリットを活かしながら、最大限のコントロールと柔軟性が得られます。アーティストは複雑な要素や 1 つひとつデザインが異なる要素を、思い通りの場所に正確に配置できます。

Exterior Decals フィーチャノードを使用すると、建物がその場に馴染み、実在しているかのような説得力を生み出せます。このノードは、プロシージャルなメッシュデカールの生成を自動化します。これらの繊細なオーバーレイによって、単調なサーフェスに細かいディテールで変化を付けることで、建物がきれいすぎたり人工的に見えすぎないようにします。

建物には主に 2 種類のメッシュデカールを使用します。

• Edge Softening Decals - メッシュのハードエッジに沿って微細な法線ディテールを追加することで、ギザギザした影の境界線を滑らかにし、より自然な遷移を作り出します。

• Grout および Leak Decals - モジュール、外壁のコーニス、壁の間の接合部に沿って適用され、建物のさまざまな要素を視覚的に違和感がないように繋げます。オプションで、外壁のコーニスの下部領域を液だれ (leak) デカールに置き換え、繊細な風化エフェクトを加えることも可能です。

『THE FINALS』のようなテンポの速い FPS では、高精度のコリジョンがゲームプレイに欠かせません。弾丸、爆発、プレイヤーの動きのすべてが、信頼性と効率性を兼ね備えたコリジョンメッシュに依存しています。本来通るはずの弾丸が壁に遮られたり、見えないジオメトリにプレイヤーが引っかかったりすれば、試合の勝敗に直接的な影響を及ぼします。

しかし、何百という破壊可能な建物のコリジョンメッシュを手動で作成するのは、時間がかかるうえに、反復作業ばかりでミスも起きやすく、環境アーティストの貴重な時間を大幅に奪うことになります。そこで、コリジョンの自動生成を本ツールセットの中核に据えることにしました。イテレーションの時間を短縮できると同時に、アーティストは反復作業よりも高レベルなクリエイティブの課題に専念できるようになりました。

各フィーチャノードは、自身のジオメトリの単純化した平面データを保持しています (通常は非表示)。これらの形状は、後に正確なコリジョンハルを生成するために利用されます。この平面データは三角形化された後、VEX で記述されたカスタムの 2D 凸分割アルゴリズムによって処理されます。この処理は、フィードバックループ内において反復的に実行されます。こうして得られた凸ポリゴンを押し出して 3D 空間にすることで、最終的なコリジョンハルが生成されます。

このショーケースでは、Building Creator ツールセットの一連のパイプラインを紹介します。まず Houdini でベルナルマップの建物を再現し、次に破砕後のセットアップを紹介します。そして最後に、「THE FINALS」のゲーム内で実際に動作する、完全に破壊可能な建物をお見せします。

Building Creator ツールセットは「THE FINALS」以外でも活用されています。その代表例が、「ARC Raiders」に登場する砂にのまれたイタリアの街、Buried City です。このマップでは、ツールはベースとなる建物メッシュの生成のみに使用されました。というのも、「ARC Raiders」は完全に破壊可能な環境を採用していないためです。

「THE FINALS」では、壁が壊れて崩れ落ちるとき、モールディングやドア枠などのディテールも破片と一緒に動くようにする必要があるので、これらをメインの建物メッシュと一体化しなければなりません。しかし、「ARC Raiders」ではその必要がないため、これらのディテールはインスタンス化したスタティックメッシュとして配置する方が効率的でした。「ARC Raiders」の環境アートチームは、生成されたクリーンで一貫性のある建物を出発点とし、視覚的なディテールや装飾の大半をエンジン上で直接追加していきました。

• イテレーション速度：ブロックアウトから粉砕されたアセットまで、1 つの変更につき 4 ～ 6 分。

• 規模：「THE FINALS」と「ARC Raiders」の 2 タイトルを合わせて、100 種類以上の固有の建物を実装。

• コリジョンとオクルーダー：完全自動化。手動作成は一切なし。

ここまで、Houdini のシンプルなブロックアウトメッシュから始まり、「THE FINALS」で完全に破壊可能な建物としてプレイできるようになるまでの、システムの全容を解説しました。このパイプラインの開発を通じて気付いたのは、建物を構築するのはもちろん、そのためのツール作りも同じくらい重要であることです。このプロセスから見えてきた重要な教訓をいくつか紹介します。

人に見せる前に、自分だけで作り込んで完成度を上げようとすると、誰にも使ってもらえないツールになりがちです。そうではなく、使える状態になったツールを早い段階でアーティストに渡し、協力して改良を重ねるようにしましょう。Building Creator の使い勝手を良くしたアイデアの多くは、マップ制作チームからの「こんなことができたら……」という一言から生まれました。Building Creator は 5 年以上にわたり使用され、ブラッシュアップされてきましたが、その成長は現在も同じ、現場の声を聞いては直す地道な積み重ねです。

数年にわたるプロジェクトでは、スキルも目標も進化していくものです。モジュール設計になっていれば、システム全体に影響を与えることなく、個別のノードを入れ替えたり更新できます。大規模なコードベースと同様、システム間をはっきり切り離しておくことで、メンテナンスが容易になります。

Building Creator の開発には、初日からチーム一丸となって取り組みました。Adrian Björkerud 氏がツールセットの設計と開発を主導しましたが、それを形にしたのは「THE FINALS」のマップ制作チームや環境アーティストたちです。彼らは、日々フィードバックを送り、各種機能を徹底的に使い込むことで、エッジケースを洗い出し、最終的に現場で使えるクオリティを実現しました。

ゲームの核となる要素、完全に破壊可能な建物に対して、Embark Studios はプロシージャルなアプローチを摸索する自由を彼に与えました。その信頼があったからこそ、このプロジェクトは実現したのです。

この記事では、システムの基本となる考え方に焦点を当てましたが、その裏側には、さらなるフィーチャノード、Python Panel、LOD タグの設定、破壊のセットアップなどまだ多くの要素が存在します。これらについては、また別の機会に深く掘り下げていければと思います。

ここで紹介したマテリアル、プロップ、アセットのほとんどは、スタジオ全体の共同作業によって生み出されたものです。本ツールセットが架け橋となり、それらの要素を 1 つに統合することができました。