Ghostwire: Tokyo™開発事例：ノンリニアな東京の街を表現する【UNREAL FEST EXTREME '22 SUMMER】

Ghostwire: Tokyo™開発事例 ノンリニアな東京の街を表現する Tango Gameworks(ゼニマックス・アジア株式会社) 奥川 剛

はじめに Ghostwire: Tokyo™は、2022年3月25日にPS5/PCで発売された箱庭型FPS スタジオ初のノンリニアなプレイスタイルのタイトル 都市型なので自然地形は少なく、ビルの屋上など縦方向の探索もあり 本セッションでは東京の街を表現するために行った事例を解説。 2

目次 ・自己紹介 ・UE概要 ・背景 ・VFX ・動画 ・HDR 3

自己紹介 Tango Gameworks(ゼニマックス・アジア株式会社)在籍のプログラマー Ghostwire: Tokyo™では、描画/システム班とアプリ班の中間の仕事を担当 背景関連、VFX、描画の一部など Epic様はじめ、外部の会社とのやり取りも 4

使用しているUEについて 最終的に使用したUEは4.27系の最新版 ミドルウエアはWWise、InstaLOD、FaceFX、OodleTextureなど 最適化中心に改造は行っているが、互換性がなくなるような大きな変更はやっていない 描画班がTSRをUE5から独自にポーティング ※注）要Epic社とのライセンス契約 5

背景について 6

背景 ・概要 ・階層レベルLOD ・インスタンスレベル ・配置物 ・ナビ 7

特徴 ・自然地形はほぼ存在せず、ビルとアスファルトで構築された都市型の地形 ・時間変化があるので、ベイクしてる物は無い、GIはSSGI ・1歩歩いただけで何かのレベルが読まれ、何かのレベルが捨てられる ・負荷 レベル読み込み時の初期化とGC InitView PSOコンパイル(特にNiagaraのComputeなど) ※ドライバのキャッシュ問題があるので注意が必要だった(DDUを使って完全削除からの確認などが必要) 8

ベースはワールドコンポジション ・サブレベル登録数は2100、ランドスケープは未使用 9

背景の構成 ワールドコンポジション サブレベル パーシスタントレベル スタート ポイント ナビボ リューム ビル、施設アクター インスタン スレベル 配置物 階層レベルLOD 配置物 階層レベ ルLOD 階層レベルLOD 階層レベル LOD 階層レベル LOD 配置物 10

階層レベルLOD ・ワールドコンポジションを監視しながら、担当する地区のレベルとマージされたメッシュの表示切替の管理 を階層的に行うアクター ・HLODやワールドコンポジションのレベルLODでは、あくまで1レベル内で完結している為、最小単位がレ ベル数以下にはならず、オブジェクト数が一定以下には減らない。 ・都市型の広いマップを再現するにあたって、距離が遠くなったら最終的にモデルが消えるのはNG、どんな に遠くても建物が見える必要があった 11

レベルを丸ごとProxyMesh化 画像左 ゲーム中最小単位のレベル 画像右 右のレベルをProxyMeshで1Mesh 1Materialにしたもの(DiffuseとEmissive、2048*1024) 12

出来上がったメッシュの周辺区画をまとめてさらにProxyMesh化 13

Jenkinsで一括生成 当初はすべて作り直すのに2週間ほどかかっていた(PC1台) Epic側でタイミングよく最適化が入ったのと、こちらでも最適化したため、最終的には24時間以内に短縮 全階層合わせて600個程度 変更部分に関わるものだけ作ることも可能 14

自動だからどうしても汚い ・UVは汚いし、ポリゴン数も無駄が多い ・レベル一つを修正しただけで階層的なLODモデルを全て修正するのは現実的ではない 15

ランドマーク的な建物だけ手動作成 16

適用結果 画像左 ワールドコンポジションの実レベルだけ 画像右 階層レベルLOD込み 17

階層レベルLODのライティング 階層レベルLODの周辺では、街灯はじめ、ライ トが読み込まれていないので暗く停電したよう に見えてしまう エミッシブだけでは不十分 18

夜景シェーダー ポストプロセス上で、Gバッファを参照しながらリライト処理を行い、1パスでLODすべてに街灯など町明か りを模した下方向からのライティングを行った。 19

リライト結果 左リライト前 右リライト後 20

元は妖怪などの表現用 UEのライティングモデルに囚われず表現可能、スペキュラとディフューズを別出力するバージョンもあり 21

階層レベルLODの効果 ・レベル内のアクターだけでなく、階層的にレベル同士もマージさせているので、大幅に描画投入量が削減し、 実装前のおよそ半分に減った。 ・マテリアル数も大幅に減らすことが出来た。 ・導入前は出来ていなかった全ての建物の表示を達成した。 将来機会があればNaniteと組み合わせて使ってみたい LODにポリゴン数のバジェットを大幅に上げる事が出来る 遠景のマテリアル簡略化と削減によって高速化が見込める 22

インスタンスレベル コンビニや神社室内などの使いまわせるレベルはインスタンスレベルを使用 プレイヤーが近づいたら読み込まれる仕組み 23

作成方法 いくつかのサブレベルを持っている独立した作業用レベル上で作成(PLにはデバッグ用以外何も置かない) そこからサブレベルを収集してインスタンスレベルとして読み込む為のアクターを作成 サブレベルを差し替えるだけで、間取りが同じで配置が違うバリエーションなどを作成 24

ドアにインタラクトしてワープする室内もインスタンスレベル ・暗転を挟む移動先も、PLを移動せず、地下にインスタンスレベルを呼び出して、そこへワープ ・地上と屋内でライトチャンネルが分かれている 25

インスタンスレベルの効果 リソース量の軽減が出来た コンビニ店内などを一点物で数百作る必要が無くなった バリエーション違いにもうまく対応できた。 構造と配置物を分けるなど細かくレベルを細分化する事で、効率的に運用出来た。 26

配置物 本タイトルにおいて、配置物でピュアなBPはほぼ存在しない ビル、神社などの建物から、車、樹木まで、すべてプログラマが用意した基底クラスを使用、もしくは完全ネ イティブ化 27

プログラマ外が書いたBPはバグ、高負荷の温床 例えばこのような 他にも、BPだけだとWITH_EDITORONLY_DATAで囲えないので、コンストラクションスクリプトでしか使っ てないメンバがパッケージ版に無駄に残っていたり、など 28

しかしながらプログラマ以外にそれを求めるのは厳しい ・風呂敷を広げる段階までは好きにやってもらう。 ・ある程度の時期になったらプログラマが引き取って作り直す方式に ネイティブ版作成後はエディタユーティリティーでツールを作って配置し直し＆プロパティをコピー 29

最もシンプルな配置物の基底クラス アクターに刺しているライトやメッシュのコンポーネント群に一括して設定を行う ・bGenerateOverlapEventsDuringLevelStreamingやTickの強制設定 ・チャンネル設定(ライト、メッシュ) ・クラスター設定 ・カリング距離 ・レイトレ設定 ・シャドウ設定 ・ボディセットアップ 30

ビルアクター あらかじめ用意したパーツとマテリアルを組み合わせてプロシージャルにビルを作成 同じアクターでも配置場所によって見た目が変わる仕組み 31

ビルアクター あらかじめ指定したフロアの基本形状、マテリアル、壁面パーツ、屋上オブジェクト、1Fテナントを組み合 わせてバリエーションを作成 32

ナビ ・DynamicModifiersOnlyはレベルストリーミ ング時のマージ負荷が高いので、レベル、バ トルチームと相談してStaticを選択。 ・メモリ消費量を最小限にするために TileSizeUUは最大の8192 ・Agentは通常キャラクターと大型キャラク ター用の2種類 ・毎晩jenkinsでWCやインスタンスレベルで ナビに必要な物をすべてロードして自動更新 33

背景まとめ アクターひとつは小さくても、とんでもないオーダーのオブジェクト数が投入されるので、一つ一つ丁寧に精 査して作る必要があった。 システム班、描画班、アプリ、レベル、アーティスト全員で徹底した結果、秒間数フレームしか出ていない状 態から、発売までこぎつける事が出来た。 34

VFX 35

VFX なるべくプログラマの実装を介さずに実装できる事が目標 ・FO ・環境VFX ・VAT ・天候 ・MPC ・Niagara ・光過敏症対策 36

FxObject 通称FO ・エフェクトのインターフェースとなるアクター ・エフェクトに関わるコンポーネントを統一して管理し、パラメータ操作などを極力アーティスト側で制御で きるようにしたもの。 ・アプリプログラマやレベルデザイナはNiagaraや音を直接さわらず、このインターフェース越しにアニメー ションをを呼ぶ。 ・複数のアニメーションを持つ事が出来る ・ゲーム中平均300~400個同時に動いている 37

使用するユーザーは何を制御しているのか知らなくていい ・ユーザーはアニメーションを指定するだけでいい 先にアニメーションの枠だけ作ってしまえば、中身がなくても実装でき、作業の平行化も見込める ・例えば3つのアニメーションを持つFOがあった場合 StartEffect(仮) ChangeColor(仮) • Niagara再生 • 音再生 • マテリアルアニメーショ ン再生 • マテリアルアニメーショ ン • Niagaraパラメータアニ メーション StopEffect(仮) • • • • 音停止 Niagara停止 Niagara再生 マテリアルアニメーショ ン 38

FO実例 39

Animation Notifyでの使用も可能 FOを指定して、さらにFO内のどのアニメーションを再生するか指定 40

FOで作れるトラック Niagara/カスケード : 再生/停止などの操作 Niagara/カスケード : パラメータアニメーション Niagara /カスケード : スプライン、メッシュなどの連携 Niagara /カスケード : データ内イベント発生時の音との連携 マテリアル: パラメータアニメーション MPC: パラメータアニメーション Wise: 再生/停止などの操作 振動: パラメータアニメーション タイマー: スローモーションパラメータアニメーション リレイ： 自身や他FOが持つアニメーションをディレイ/再帰再生 アクティビティ: ゲームの進行操作命令 ※(サーフェース、ポスト、ライト、デカール) 41

FO特徴 アニメーション ・区間ループ再生 ・アニメーションの尺スケール 1秒で作って状況によってスケールをかける作り 42

FO特徴 マテリアル ・マテリアル内の特殊変数 ポスト アクター位置、アクター2D位置を使用可能 デカール バウンディング情報を取得可能 43

マレビト「白無垢」の範囲攻撃 44

穢れ樹木 45

お札 46

マレビト「雨童（あめわらし）」に発見された時 47

FOの特徴 外部アクター/コンポーネントへの操作 ・自身が持つ物以外にも、外部のアクターが持っている物に対して操作を行う事が可能 一括設定にも対応 MeshComponentをFOのSetMesh関数に渡すだけでNiagaraとマテリアル操作へアタッチ 48

敵死亡演出 49

FO デバッグ機能 ゲーム実行中に割り込んでの操作が可能 50

FO まとめ 想定通りの結果を出すことが出来た アーティストだけで完結した複数の要素が絡んだ演出の作成 プログラマの実装、メンテナンスコスト減 歴史的経緯から正式な名前はFxProp パーティクルと音をタイミング合わせて再生するだけのクラスだった 51

環境VFX ワールドコンポジション内をトラバースし、テーブルで指定したメッシュコンポーネントを検索 見つけた場所に自動でレベルを作成、音とパーティクルを配置。 近隣数十メートル単位で一つのアクター、SignificanceManagerでTickなど管理 52

VAT(VertexAnimationTexture) Alenbicなどのジオメトリキャッシュに比べ、安定 ストリーム負荷がない 出力の差※1で負荷の場所が変わるような事がないので予測がつけやすい ※1デフォームでやってるのか、純粋なキャッシュなのかなど 主に二つのシチュエーションで使用 スケルタルメッシュを大量に使うには重すぎるシーンで使用 水などの表現をする場合 53

VAT 残留思念 54

VAT 地下演出 55

VAT カラス 56

VAT 水の印 57

VATのレギュレーション ・5000ポリゴン以内(本当は頂点数指定の方が正確) ・30fps ・4秒以内 ※ポリ数＊FPS＊尺の値が下回ればOKなので、1万ポリ＊ 30fps ＊ 2秒や5000ポリ＊ 15fps ＊ 8秒などもOK ※法線テクスチャを使わずに、頂点テクスチャのaに格納する場合は倍 58

一部例外もあり 表現上重要な部分に関しては例外的にオーバーしている 59

VAT まとめ ・既存のスキニングやモーフでは表現できない事が表現できる。 ・サイズや負荷には気を付けなければならないが、既存のシステムを使うより高速な場合がある 60

天候 61

霧 近景、遠景、雲海の3種類で表現 3種類共通して、霧の開放状況を描きこんだ“霧マップ”を参照 62

近景霧 プレイヤーカメラに追従するボリュームフォグパーティクル 63

遠景霧 近景霧の範囲外をポストプロセスでレイマーチをして表現 64

雲海 高いところから見下ろした時専用で動く。レイマーチで表現 65

霧マップ 上空から見たマップ全体のXYの霧の発生状況をテクスチャに投影したもの レベルデザイナーが円と矩形を組み合わせて配置 内円と外円でフェード幅指定可能 プライマリ、セカンダリ、演出バッファを持つ 独自描画コマンドを解釈して4~5フレームかけて描画 描画が完了したらプライマリとセカンダリを入れ替え 66

霧マップの演出 ・開放時の演出やプリミティブ感を消すノイズなど、リアルタイム性が高い物について プライマリバッファを参照しながら演出バッファに毎フレーム適用、 あくまで演出なので実際のゲーム的な効果は無い 開放演出をやっている間にセカンダリバッファの描画を終わらせる 67

雨、雪 カメラ周辺にだけパーティクルを降らせている 霧マップのように屋根マップが存在するがスタティックな物 68

MPC ゲーム中、多くのマテリアルに関わる仕様のパラメータを中心に使用 ダイナミックなマテリアルを無駄に増やしたくない場合やマテリアル内だけで完結したい場合に使用 ひとつのマテリアルで参照できるMPCは2個までなので、野良MPCは禁止 予め用意した以下2つのどちらかを使用する ゲームプレイにまつわるパラメータ システム、環境にまつわるパラメータ 69

MPC 敵の位置 常に近い敵8体分と、ノーマル位置8か所を知る事が出来る。一番近い敵との距離も取得可能 70

MPC 予兆演出 点滅やシャッターはすべてマテリアル内で完結 71

MPC 濡れ 72

MPC 波紋、水たまり 73

MPC 波紋、水たまり 74

MPC 停電 75

MPCまとめ 物量の多い本タイトルにおいて、全体に通知したいパラメータを使うのに重宝した。 2個制限があるので、MPCの乱立防止など最低限の管理は必要 76

Niagara 当初Cascadeだけで運用 次第にNiagaraでしか表現できない事が増えてきたので導入 Cascadeでも表現できるものはCascadeで、それ以外の物をNiagaraへ 作成したモジュールをいくつか紹介 77

メッシュ参照モジュール 標準である物を必要最低限の実装にして軽量化した物 オフセットとして、位置、回転、回転前のスケール、回転後のスケールの設定ができる 78

スプライン参照モジュール UNiagaraDataInterfaceSplineのUserDataの受け渡しのC++関数がみあたらなかったので自分で作成 寿命と連動させてパーティクルの位置や方向を更新するなど3~4種類のモジュールを作成 79

その他 基本的には標準でできる事をまとめた物が多い 80

Niagaraまとめ プロジェクト途中での導入だったが、FOを介して使用したのでプログラマ側の負担は最小限だった。 カスケードの資産はそのまま使ったので、変換コストなどはかからなかった カスケードではできない表現が出来たので、導入の価値はあった。 81

VFX 光過敏症対策 特にグローバルなタイトルでは対応必須 QAが走る段階で判明する事も多い 82

光過敏症対応 敵予兆演出 カメラドアップの時は点滅しない 83

光過敏症対策 ビル密接飛び降り対応、一定以上の落下スピード+カメラとの距離で窓の明かりを消す 84

光過敏症対策 光る貨幣、カメラに近づくと発行を消す 85

光過敏症対策 なるべく表現を落とさないように カメラが寄ったときなど、チェックに引っかかるシチュエーション時にだけ限定して対策 なるべく負荷にならないように 全ての対策をマテリアル内で対応、処理をGPU側で完結 できるなら最初から仕組みを入れておいた方がいい 86

動画 ・WebM/VP9を採用 ・本タイトルのPC版はDx12 Dx12ではUE4のMediaPlayerはハードウェアデコードが出来なかった ※現在はmp4のみElectraで可能 VP9であればmp4のおよそ半分のビットレートで同じクオリティが出せるので負荷に優しい 動画毎に4K版と1080p版を用意 WebMMediaではなく、WmfMediaを使用(要コーデックインストール) ・音声トラックは持たない Wwiseを同期して再生 87

MediaPlayerの問題 ・Prepare完了後にPlayしてもすぐに再生が始まらない ハイエンドPCだとわかりにくいが、遅いPCで顕著 リアルタイムシーンとのつなぎや、字幕、Wwiseとの同期が難しい ・一度処理落ちするとタイマーが信用できなくなる ずれたままになるので、同期の基準がわからなくなる 絶対に落ちないようにする必要あり、裏でロードや初期化をしている場合注意が必要 ・対処 動画中60fpsを死守するようにした。 ポーズ時やずれが大きくなった時にシークし直しを入れた ・結論 シビアなタイミングが必要な場合はBinkなどの動画ミドルウエアを使った方が無難 88

HDR ・スタジオ初のHDR対応タイトル ノウハウが溜まっているわけではないので最低限の対応をする方針 ・テクスチャなどの素材はsRGB/Rec709のまま 2020で作ると綺麗だがプログラマ、アーティスト共にノウハウ不足 どうクリッピングするかなどSDRへの変換への不安もあった ・最大輝度はオプションで1000と2000から選択 89

HDR 出てきた問題と対処 ・HDR有効にするとどぎつい色が出る 原因 道路標識の赤を(1,0,0) 表現するような物が多かった。 シェーダーの計算結果が色域外になっていた、など 対処 アーティスト側でカラーチャートや計測した値から色を設定するように周知 色域外やずれが大きくなりそうな色をチェックするチェッカーを作成 ・UIのトーンがおかしい UE4のバグでリニアへの変換忘れあり、UDNで指摘済み、1行の修正で解決するので対応をお勧め udn: https://udn.unrealengine.com/s/question/0D54z000070CDPMCA4/ issue: https://issues.unrealengine.com/issue/UE-117936 90

• https://udn.unrealengine.com/s/question/0D54z000070CDPMCA4/
• https://issues.unrealengine.com/issue/UE-117936

HDR 出てきた問題と対処(をうまくできなかったところ) ・製品と同じ絵を確認できる環境が実質パッケージだけなので、チェックのイテレーションが厳しい 出力フォーマットと色域がゲーム実行の仕方で変わってしまう エディタ:HDR非対応 スタンドアロン:ScRGB パッケージ:rec2020 最後まで適切な対応できず、日に数回定期的にできるパッケージで確認していた。 ・白飛びしてほしい所で飛ばずに色が濃く出ている 意図的に白飛びさせたはずの絵が飛ばずに濃い色が出てしまう 地道に確認、修正 ・全員がいいモニタで確認できるわけではない 同じシリーズでもインチが違うだけで全然違う見た目だったりした 最終的には各セクションのマネージャー判断になった。 91

HDRと動画 動画はSDRのみ用意 HDR時にはレンダリング時に変換 UIのバグに気づく前に実装したので、出力がおかしいUIではなくポストプロセスで動画を描画 シェーダー内で最大輝度に合わせたACESの変換とリニア→Rec2020まで変換 ペーパーホワイトは300nitsに設定 92

HDRとグレーディング ただHDRを有効にしただけの撮って出しの状態だと眠かった HDR時にだけ適用されるポストと、グレーディングノードを用意 Gradeノード、RGB↔HSV変換、色温度、暗部/ミッドトーン/明部のレンジ指定など アーティストの目でnukeライクにポストマテリアルでノードをつなげて調整 結果、暗部を少し下げて色温度を寒色よりな設定になった。 93

HDRまとめ ただ有効にしただけの物に比べて格段にクオリティを上げる事が出来た。 次の機会があれば2020への挑戦やHDR→SDRの変換なども挑戦してみたい。 94

最後に UE4末期タイトルとして、入れれる要素を全て入れ込んだようなタイトルになった 縦方向にも探索できる広い都市型の背景表現 VFXではアーティストだけで完結して演出を作れる環境を用意 HDR、レイトレーシング、VRR、高リフレッシュレート対応など、トレンドの仕様の導入 予定があるわけではないが、今後はこれらを元にUE5の検証などもやっていきたい 95

ご清聴ありがとうございました 96

アンケートへのご協力をよろしくお願いします https://forms.gle/bAZF1zssSWE9hMwo7 97

• https://forms.gle/bAZF1zssSWE9hMwo7