（作成中）「Optimizing UE4 for Fortnite: Battle Royale – Part 2| GDC 2018 | Unreal Engine」の日本語メモ

• （作成中）「Optimizing UE4 for Fortnite: Battle Royale – Part 2 | GDC 2018 | Unreal Engine」の日本語メモです.

PC やコンソール向けの設定

• Movable なディレクショナルライト
  • カスケードシャドウマップ
  • RTDF
• Movable なスカイライト
  • DFAO, SSAO
• ローカルライト
  • ポイントライト，スポットライト
  • デプスシャドウ
  • シャドウのキャッシュ ( “Fortnite’s Real-Time Lighting Techniques and Tools in GDC 2018” の日本語メモ” の最後の方を参考)
• マテリアル
  • 物理ベース
  • サブサーフェススキャッタリング
  • 植物用の両面シェーディング(Two-sided foliage)
• エフェクト
  • ボリューメトリックフォグ
  • ライトシャフト
  • GPU パーティクルシミュレーション
  • フォレッジのアニメーション
• ポストプロセス
  • ブルーム
  • オブジェクトの輪郭線
  • ACES トーンマッパー
• AA
  • Temporal AA

モバイル向けのグラフィックスの設定

• ※ モバイルフォワードっぽいです.
• Movable なディレクショナルライト
  • カスケードシャドウマップ
• Movable なスカイライト
• ローカルライト : なし?
• マテリアル
  • 物理ベースを近似したシェーダ
• エフェクト
  • GPU パーティクルシミュレーション
• ポストプロセス
  • トーンマッパーのみ
• AA
  • MSAA

スケーラビリティグループ

フレームレートのターゲット

• ターゲット FPS は 60 だけど, VSync は 30FPS
  • CPU や GPU を最大限に使うと, 発熱の問題が起きてクロックが下がる, バッテリーを使いすぎる

デュアルコアの iOS デバイス

• 下図は iPhone 6S の場合です.
• 従来的なゲームスレッド(青)と…
• レンダースレッド(紫)
  • Stat_FMobileSceneRenderer_Render : 21.97 msec
    • STAT_InitVIewsTime
    • STAT_BasePasssDrawTime : 14.71 msec
• 1 個タスクスレッド(赤)が非同期タスクを処理する, 主にストリーミング用
• iPhone7 は速い2コアと, 効率重視の2 コアがあるけど, そのうちの 2コアしかアクティブにならない

4コア以上の iOS デバイス ( iPhone8, iPhoneX)

• 下図の数値は iPhoneX の場合
• スレッド構成
  • GameThread : 青
  • RenderThread : 水色
    • FDrawSceneCommand : 11.24 msec
    • STAT_EventWait : 17.98 msec
  • TaskGraphThreadNP0
  • TaskGraphThreadNP1
  • TaskGraphThreadNP2
  • TaskGraphThreadNP3
  • AudioThread
• iPhone8 と iPhoneX は速い2コアと効率的な4 コアがある
• なので, 3 個のタスクスレッドを追加して以下の処理をしている
  • アニメーションの Eval の並列化
  • パーティクルシミュレーション
  • 物理タスク
  • 非同期のシーンクエリ
  • テクスチャストリーミング
  • シーンのカリングやレンダリング
• それと Audio スレッド (一番下の黄緑)

Android デバイス

• 下図は Samsung Galaxy S8 と Adreno GPU の場合
  • 4 コアあって, 2 コアが大きい?(big), 2 コアが小さい?(little)
• スレッド構成
  • ゲームスレッド
  • RenderThread
  • RHIThread
  • TaskThread NP0
  • TaskThreadNP1
  • TaskThreadNP2
  • TaskThreadNP3
  • AudioThread
• OpenGL コマンドのサブミットに RHI スレッドを使っている
  • OpenGL のドライバの遅さがネックになっているので, RHI スレッドが有効な場面
  • RenderThread で抽象化コマンドを作る(OpenGL に関係なく, 描画の抽象化コマンドの並列生成が可能)
  • その後, RHI スレッドで抽象化コマンドを元に OpenGL API を叩く
    • RHI スレッドがフルで働いている状態
• ※ Android 対応は進行中(WIP)

ドローコール

オクルージョンカリング

• モバイルデバイスでは（デプスプレパスがなくて）ベースパスだけでメッシュは 1 回描画とのこと.
  • モバイルフォワードレンダリング

Destructable HLOD

• 「Destructable HLOD」を追加するために, HLOD ツールにテコ入れをした
• 一番下の LOD のメッシュをマージして, テクスチャアトラスを作って 1 ドローコールにした
• 頂点カラーに ObjectID を仕込んで, 破壊されたオブジェクトは隠した(詳しくはテクニカルアートのセッションで)

プレイヤーが組み立てる壁

• ポリゴン数が多く, 従来的な LOD だとうまくいかない
• プレイヤーが組み立てる壁にはカスタム LOD を使っている
• ポリゴン数の削減が主な目的
• ハイエンドでは頂点アニメーションだが, モバイルでは完全なモデルを用意してマスクマテリアルを表示・非表示を切り替えて, 完全にできたら不透明シェーダに差し替える

UE4.20 でのモバイル向けの機能の予定

キャラクターの LOD

ドローコールの最適化

• 典型的な都市の建物は 300-400 個の破壊可能なピース
• 全てのライティングは動的で時間変化がある, ベイクはなし.
• Tilted Towers(マップ名?)は 15 の建物で( シャドウなし?で) 大体 2000 ドローコール
• 通信プレイ(協力や対戦)ではプレイヤーが建物の裏に隠れるので, アグレッシブなカリングはうまくいかない

HLOD を超えて

• 建物の破壊中のドローコールを 1 個に減らすのが目的
• それぞれの建物の破片は かなりの低品質(Ultra Low)でシルエットが一致する手作り LOD (500 破片以上)が飛鳥だった
• シェーディングの見た目を保つために, カスタム編集の法線を可能限り使っている

DHLOD : エンジンの設定

• ワールドごとに HLOD+ の設定として HLODSetupAsset にコンテナとして定義がある
• 2つ目の階層を追加して, 「0 レベル目の Simply Mesh 」を無効にすると, DHLOD が有効になる
• MergeSettings の下の Merge マテリアルをセットして, 破壊用のオーバーライドのマテリアルをを設定する必要がある

破壊の可視化

• それぞれの破片は頂点カラーによって一意な 2D のインデックスが割り当ててられている
• 建物ごとに, G8 フォーマットのレンダーターゲットを作っている
• 破片を破壊するには, 破片のインデックスの箇所に黒のテクセルを描画している
• 頂点カラーを UV として変換して,レンダーターゲットの値を読んで頂点シェーダでを縮退している

DHLOD の比較

• 左: オリジナルのメッシュ, 70000 トライアングル, ストリーミング
• 真ん中 : HLOD0(DHLOD), 5462 トライアングル, ストリーミング
• 右 : HLOD1(ProxyHLOD), 1150 トライアングル, 常にロード