2018年7月25日

アンリアル エンジン 4.20 の Proxy LOD ツールの詳細

作成 Sam Deiter

アンリアル エンジン 4.20では、新しいプロキシ LOD ツールが導入されました。フォートナイトのモバイルリリースで必要不可欠なツールでした。プロキシ LOD ツールを使うことで、ポリゴン数、ドローコール、マテリアル複雑度によるレンダリングコストを削減して、大幅にパフォーマンスを増加することを可能にします。モバイルとコンソール向けにコンテンツを最適化する際にも非常に役に立ちます。 

この記事では、エピック ゲームズのテクニカルアーティストとエンジニアがどのようにこの素晴らしいソリューションを開発したかについて説明します。フォートナイト バトルロイヤル (以下 FNBR) の建築と破壊がどのプラットフォームでも同じような外見で機能することを支えているのはこの機能です。
Fortnite_ProxyLOD_Pic1.jpg

一貫性が大事

夢の砦を建てるために車を壊して資材を集める時も、敵の攻撃を避けるときに壁を片っ端から建てる時も、常に建築と破壊は FNBR の欠かせない特徴になっています。 

クロスプレイを実装する際に、どのプラットフォームのプレイヤーも公平に勝利のチャンスを得ることができるようにすることが必要不可欠でした。そのために、フォートナイトチームはドローコール数を削減したり、一度に画面に表示されるオブジェクト数を削減する方法を探す必要がありました。オブジェクトの建築と破壊という 2 つの最も大事な FNBR のメカニズムでのパフォーマンス問題を克服するためです。 

モジュラー構造のワールドの構築

プレイヤーによる破壊によって起きる問題を理解するには、まず FNBR の建物がどのように構築されているかを理解する必要があります。FNBR の各建物は、お互い簡単に「スナップ」し、必要に応じて構造を作成できるモジュラー構造のピースの組み合わせで作られています。このモジュラー構造のアプローチを取ることによって、建物に必要となるユニークアセットの数を削減し、メモリといった貴重なリソースを節約できます。様々なモジュール構造のピースは、マテリアルやテクスチャも変更して使い回すことができます。これによって追加のオブジェクトをメモリに読み込むことなしに、無限の建物バリエーションを作ることができます。モジュール構造によって実現できるバリエーションのサンプル画像が以下になります。 
Building___Modular_Assets_00.png
上の画像の左側の建物は、建物内部の家具や縁取りを除くと、画像右側にある 9 個のスタティック メッシュ アクタから構築されています。このように建物を構築することで、プレイヤーによる破壊を表示することも非常に簡単になります。破壊を表現するには、破壊されたピースのレンダリングとコリジョンを無効にすればいいのです。この破壊表現は PC でもコンソールでもうまく機能するのですが、モバイルといったパワーが足りないプラットフォームでは問題になります。FNBRの建物を構成する 350 から 400 の個々のピースをレンダリングするコスト自体が問題になってしまうのです。下の GIF 画像では、典型的な建物を構成しているピースがいかに多いかがわかります。
BuildingExplode.gif
このことはPC でもコンソールでも問題にはならないのですが、シーン全体のピース数を 1000 以下に抑える必要があるようなスマートフォンでは大問題です。 

全体としての建物の次には、各コンポーネントと、破壊表示での役割を見てみましょう。以下のフローチャートの順番に説明をします。
ProxyLOD_InDepth_Overview.jpg
少ないことはいいことだ(最適化) 

FNBR はモジュール構造アプローチを使っていますが、やがて一画面に同時に存在するオブジェクト数のハードリミットに直面することになります。このハードリミットはドローコール数です。各プラットフォームで一度に表示が可能なドローコール数は異なっているため大きな問題になります。FNBR が各プラットフォームでスムーズで安定したフレームレートになるように保証するには、 FNBR で使用される各スタティックメッシュに複数のレベルオブディティール(LOD)スタティックメッシュを持たせる必要があります。LODは一般的にビデオゲームで使用されている最適化テクニックで、スタティックメッシュがカメラから距離が離れている場合に三角ポリゴン数が少ないバージョンのスタティックメッシュを表示することで最適化を行います。 
Mesh_With_LOD_s_Wireframe_00.jpg

上の画像は FNBR の建物で使用されているモジュラー構造の壁の一つです。壁に非常に近い位置にいると、画像の一番左側のスタティックメッシュが表示されます。カメラが壁から離れると、下の GIF 画像のように別のLODモデルが表示されていくようになります。

LOD_Transition_00.gif

この最適化手法を建物全体に適用すると、以下の画像のような表示になります。
Building_OrginalGeo_VS_LODGeo_00.jpg
上の画像の左側は元々の建物です。右側は最後の LOD だけを使用した建物です。 右側の建物は望ましいのですが、それでも一部のプラットフォームでのレンダリングにおいてはピース数が多すぎます。この問題に対応しつつ、プレイヤーによる破壊を表現できるようにするには、新しいツールと共に、「昔ながらの」スタティックメッシュ制作テクニックが必要になります。 

「昔ながらの」やり方

プレイヤーによる破壊表現について詳細を見ていく前に、まず一番最後の LOD についてもう一度確認しましょう。これは特別な方法で作成されたものです。UE4 の スタティック メッシュ エディタでモジュラー構造ピースを開いて、最後の LOD を強制的に表示されると、以下のような表示になります。
Last_LOD_In_UE4_00.png
よくあるスタティックメッシュのように見えるかもしれませんが、三角メッシュ数は 12 で、頂点数は 18 というところに注目してください。この数字はただ小さいものに見えると思いますが、実はデジタルコンテンツ制作ツール(DCC)で同じ大きさのキューブを作成した時よりも低い値になっているのです。次の画像では、同じモジュラー構造のピースをDCCで作成しUE4にエクスポートしています。作成されたスタティックメッシュはまったく同じ大きさと形状ですが、頂点数が 6 個増えています。
Last_LOD_In_UE4_01.png
頂点数が 6 個くらい増えてもそんなに変わらないと思うかもしれませんが、この差分は累積していきます。たとえば、このピースが建物で 30 回使われると、建物一つに 180 個の追加の頂点が増えてしまいます。建物が 100 回使用されていると、この 180 個 がレンダリングが必要な 18,000 個の追加頂点になってしまいます。こうした追加の頂点を取り除くために、モジュラースタティックメッシュでは以下の調整を行っています。
  • まず、スムージンググループを使わなくてよいピースではスムージンググループをまったく使わないように設定します。
3dsMax_NoSmoothingGroups_00.jpg
 
  • 次に、スタティックメッシュの UV はアイランドができる限り少なくなるように設定します。このピースの場合、箱の正面と背面は 0 から 1 のUV空間全体にマッピングされています。それから、側面部分はすべてウェルドで接続し現在のピースの設定に合う縮尺にします。
3dsMax_UVLayout_00.jpg
  • 最後に、垂直面のスムーズ化アーティファクトができる限り起きないように法線を調整します。
3dsMax_NormalFix_00.jpg
これらの調整が終わったら、修正済みのピースをエクスポートします。既存のピースを上書きするように修正済みピースをインポートします。FNBR では同じプロセスがすべてのスタティックメッシュの最後の LOD に対して適用されています。 

次のセクションではプレイヤーによる破壊表現のためにどうしてこれらが必要なのかを説明します。

ジオメトリに「何」をした?

できる限り三角ポリゴンを減らした LOD を建物を構成するすべてのモジュラー構造パーツに適用した後に、 Hierarchical Level of Detail ツール (HLOD) を使用して、新しいバージョンの建物を生成します。以下の画像のようなものです。
pasted-image-0-(1).png
この建物の新しいバージョンをMedium HLOD あるいは MHLODと呼んでいます。最後の LOD を単一のスタティックメッシュとテクスチャにまとめたものです。建物表示に必要な三角ポリゴン数を大幅に削減できます。例えば 50,280 ポリゴンから 2,880 ポリゴンになります。これはスマートフォンといった比較的ローエンドのデバイスでは大幅な改善になります。このバージョンの建物は、ローエンドのデバイスで、建物から約 30 メートルほど離れた時のみ表示されます。建物が使用するマテリアル数も削減できます。建物をレンダリングするのに必要なリソース数をさらに削減できます。

さらに遠くへ

これから説明する内容はプレイヤーによる破壊とは関係ありませんが、それでも役立つ内容です。FNBR をプレイ中に、非常に遠くの建物をみると、破壊の様子が表示されていないことに気がついたかもしれません。ここで見えている一番最後の LOD は Proxy Geometry ツール を使って生成されたものだからです。Proxy Geometry ツールは Simplygon の代替としてインハウスで開発された新しいツールで、建物の三角ポリゴン数を MHLOD からさらに削減するために使用されています。ここで生成された建物はプレイヤーによる破壊を表現していませんが、カメラから非常に離れた場合の建物のレンダリングコストを削減するためには重要になります。建物の MHLOD モデルに Proxy Geometry ツールを使うと、この例では建物の三角ポリゴン数が 2,880 から 412 になります。もちろん、以下の画像のように、412 ポリゴンだけではよい見た目にはなりません。
pasted-image-0.png
ただこの 412 ポリゴン版の建物は非常に遠い場所から見ることになるので、プレイヤーから見て実は上の画像のようだったと判別するのは非常に難しいでしょう。以下の GIF を見てください。このGIFでは、プレイヤー視点で、建物が一番多いポリゴン数のバージョンから単純化したものまで切り替わる様子を見ることができます。 
Base_MHLOD_Proxy_Example_00.gif
建物の構成と使用しているツールを、そしてなぜツールが使われているのかを理解したので、これらをどのようにプロダクションで使用できるツールとしてまとめたのかについて話し始めることができます。

テクニカルアーティストの出番

建物の構成がわかったので、次は MHLOD メッシュが表示されている時にどうやって破壊を表現するかを見ていきましょう。ここで重要なことは、MHLOD の建物を変更せずにプレイヤーによる破壊を表現しないといけないということです。プレイヤーによる破壊に合わせて表示するピースを変更したり置き換えたりすると、建物の MHLOD がある利点がなくなってしまうからです。 これは複雑な問題です。特別な種類の開発者の助けが必要になります。ここでテクニカルアーティストの助けが必要です。

テクニカルアーティストという職種に馴染みがない方向けに説明すると、テクニカルアーティスト(TA)はアーティスト、プログラマ、デザイナーが一人にまとまっているような人です。複雑なマテリアル問題の解決からブループリントのデバッグまで、TA は開発中に湧き上がる多くの問題を解決することができます。複雑な問題に対しての解決方法を探すために TA が呼ばれるのには理由があります。TA は一般的にビデオゲーム制作で必要なすべてのシステムとツール、そしてそうしたシステムの繋がりをよく理解しているからです。 今回の課題では、問題を最小要素に分解し、シンプルでかつ柔軟な解決方法を作り出すために TA の助けが必要でした。

分解と破壊

こうした問題への解決策を探す時には、まず問題を基本的な構成要素に分解する必要があります。関係している要素について理解を深めることで、少しずつ成功に近づくことができます。こうしたことを念頭に、TA は MHLOD での破壊表現の問題を以下の要素に分解しました。 
  1. まず HLODDestructionIndex という新しいプロパティをすべての建物が使用している BuildingWall クラスに追加しました。
  2. 次に、HLOD を作成する際に、建物を構成しているアクタに順不同のインデックスを割り当てました。
  3. そして、各建築基盤に破壊可能なピースごとに 1 テクセルを割り当てられるほど大きなレンダーターゲットを用意します。
  4. これらを用意した後、HLOD で使われる メッシュマージを調整して、 Max LODのコピー機能と、生成されたスタティックメッシュにカスタムの頂点カラーを追加する機能を追加しました。
    • 注意 頂点カラーはR、G、B成分で 65000 の値を持つことができて、ここでは必要以上の量のはずです。
  5. 壁や床といった建物のパーツが壊されたときには HLODDestructionIndex の値を読み込んで、対応した値をテクセルに書き込みます。これで HLOD メッシュの状態を変更せずに建物パーツを破壊します。破壊イベントごとに 1 ピクセルのドローイベントを行うだけです。
  6. 最後に、マテリアルで頂点カラーにパッキングされた ID を読み込み、破壊テクスチャを探して、もしテクセル値が 0 の場合(破壊された)は頂点を原点に集約(例 0 倍スケール)します。

TA はこのプランのもと UE4 でプロトタイプを作って検証を行いました。思ったとおりに動くのか、またアイデア段階に戻る必要があるのか確かめるためです。 

幸運にもこのアプローチは魔法のように成功しました。追加のレンダリングオーバーヘッドなしに MHLOD スタティックメッシュが破壊される様子については下の GIF をご覧ください。 
MHLOD_Building_Destruction_17MB.gif

TA のプロトタイプが動作したので、次はツールプログラマに渡して制作で使用できるツールにしてもらいます。

ツールとして再構築

プロトタイプを作り、テストして、何度も調整してもとのアイデアそのものの動作をするようになったところで、ツールプログラマに渡して C++ で再構築してもらいます。 高速な実行、最適化のために、C++ で再構築する道を選びました。C++ でツールを作り直すことで、必要なプロパティを既存の UI の中にまとめて追加することも可能になりました。再構築がおわると、下の動画のようにゲーム内でテストできるようになりました。
 

利用可能なツール

この記事によって、クロスプレイの導入による破壊問題にエピック ゲームズのテクニカルアーティストとエンジニアがどのように取り組んだかについて理解が深まったのなら幸いです。彼らの素晴らしい解決策がなければ、 FNBR でプレイヤーが繰り広げる破壊のシンフォニーは不可能だったでしょう。 

なにより素晴らしいのは UE4 の 4.20 リリースにこの記事で紹介したツールが含まれているということでした。アンリアル エンジンのコミュニティがこれらのツールを活用するのを非常に楽しみにしています。 

ツールの詳細については以下のドキュメントを参照してください。
 
Proxy Geometry Tool - Proxy Geometry ツールセットは、ビジュアル品質を保ちつつアンリアル エンジン 4 プロジェクトのパフォーマンスを向上させる方法として開発されました。 

Hierarchical Level of Detail - Hierarchical Level of Detail(HLOD) ツールはシーンでレンダリングされる必要のあるアクタ数を削減します。毎フレームのドローコール数を減らすことでパフォーマンスを向上します。