昼夜の変化のある「ビッグワールド」の町の実現のための実用的な技術の紹介／Practical technologies to create Big World city with time-of-day

昼夜の変化のある「ビッグワールド」 の町の実現のための実⽤的な技術 Practical technologies to create Big World city with time-of-day Unity Game Studios 2023

講演者紹介 イ‧ナンホ Nanho Lee イ‧テフン Tei Lee 南 相培 Sangbae Nam Senior Graphics Engineer Lead, Technical Art Manager, Software Engineering

Agenda → バックグラウンド → Mega Objects → Time Of Day → まとめ

バックグラウンド

プロジェクトコンセプト ゲーム市場のトレンドを反映 → モバイル = 最も⼤きいゲームプラットフォーム → 広いワールド → 昼夜の変化 (time-of-day ) → 広くて密度の⾼い都市

デモ

技術的な難題 → → → モバイルプラットフォームの制約 ‒ 低い帯域と⼩さいサイズのメモリ ‒ 遅い速度と⾮対称のコア ‒ サーマルスロットリング 商⽤ゲームエンジンの制約 ‒ 広いワールドのためにシーンのストリーミングが必要 ‒ 昼夜の変化のため動的な GI とシャドウが必要 ⼈的リソースの制約 ‒ 効率のいいレベルデザインが必要 ‒ アセットの再利⽤が必要

Mega Objects アート

アートコンセプト 広くて密度の⾼い都市 → 古代のギリシャ → 峡⾕、島、盆地 → 旅とランドマーク → PBR 寄り "Panorama view of Dubrovnik, Croatia" by "acediscovery" is licenced under CC BY 4.0.

• https://upload.wikimedia.org/wikipedia/commons/0/08/Panorama-Dubrovnik.jpg
• https://commons.wikimedia.org/wiki/User:Acediscovery
• https://creativecommons.org/licenses/by/4.0/

⾼低差のある地形 → 単調さの緩和 → 興味の誘発

密度感を⾼める配置 同じ量のオブジェクトでももっと⾼い密度感

密度感を⾼める配置 不規則に⾒える配置

制約 → 時間 → ⼈的リソース → コンセプトよりも技術の選定が先⾏ ‒ 密集した⼤量のオブジェクト ‒ モジュール式のオブジェクト ‒ プロシージャルなキットバッシュ

Mega Objects テレイン

レベルデザイン テレインだけど、テレインじゃなかった → モックアップからテレインを作成 → 最終的にはテレインをメッシュに変換 → 更にストリーミングのため分割

テレインのデザイン → ⼀般的にはテレインのデザインが先だが、今回はレベルデザインが先⾏した → テレインのデザインは Unity Editor でメッシュを組み合わせたモックアップになっている ‒ ハイトマップのテレインはモックアップに合わせるのが難しい ‒ Houdini を利⽤して合わせた

ワークフロー 1. Unity でモックアップを作る 2. FBX Exporter でモックアップシーンをエクスポートする 3. Houdini に FBX をインポートして編集する 4. Unity にインポート後、必要におじてブラシで編集する Unity でモックアップ作成 Houdini にインポートして編集 Unity にインポートして仕上げ

結果

Mega Objects ストリーミング

サブシーンストリーミング → 広いワールドをストリーミングするために適切に分割する必要がある → ワールドを DOTS の SubScene に分割し、ランタイムで SubScene 単位でロード‧アンロード → DOTS SubScene の利点 → ‒ ロード‧アンロードが速い ‒ ロード‧アンロードのとき「ガーベジ」をほとんど残さない ‒ 複数のセクションに分け、セクション単位でロード‧アンロードできる ほかのエンジンでは代替機能を利⽤するか⾃前で実装すればいい

セクターへの分割 ● SubScene の仕組みに合わせワールドを分割したパーツ ● 分割処理はスクリプトで⾃動化

セクション ● オブジェクトの種類によってレイヤーで分類 ● レイヤーに沿ってセクションに分割 Default Sections Default + Building Sections Default + Wall Sections

セクターのストリーミング ● 「プレイヤーの半径 + カメラの視錐台」に含まれるセクターだけをロードする ● セクションによって違う半径と視錐台を使⽤する Building Section Foliage Section

セクターのロード ● 実際はカメラよりも広い視錐台を利⽤ ● 重要なセクションを先にロードするように優先度付け

セクターのアンロード → → 視錐台の外に出てから⼀定時間後アンロード メモリチャンクの解放が主になるためアンロードも ⾮常に軽量 全セクションのアンロードの所要時間: 17.78 ms (Galaxy Note 20, Dev Build)

ロード時間の実測結果 → → ロビーからゲームシーン ‒ Galaxy Note 20: 6.4 秒 ‒ iPhone 14 Pro Max: 2.2 秒 カメラの向きを 180 度転換 ○ Galaxy Note 20: 1.9 秒 ○ iPhone 14 Pro Max: 1.2 秒

ストリーミングによるメモリ使⽤量の削減効果 ストリーミング無効 ストリーミング有効 iPhone 14 Pro Max, Dev Build

Mega Objects インスタンシング

効率の良いキットバッシュ → インスタンシングの効率 → 制作過程の効率

アセット → ⾯積、体積によるモジュール数の制限 ‒ 32.7 個 / 100 ㎡ ‒ 6.2 個 / 100 ㎥ → モジュールで構成された建物: 14 種 → モジュールでない⼩物: 236 種 → フォリッジ: 9 種

プロシージャルテクスチャ プロシージャルなグローバルテクスチャ

ワールドマスクマップ → 「ワールドテクスチャ」をマスクとして利⽤してブレンドする → インスタンシングを維持しながらモジュラーによる単調さを減らすことができる

ワールドマスクマップのシェーダープロセス Vertex Colour Diffuse Add World Mask Multiply Height Map Mask Normal Specular

インスタンシングの要件と既存の⼿法の⽐較 要件 Indirect Rendering ● アセットに対する追加作業やベイ クのような前処理が不要である ● GPU メモリをたくさんたくさん 消費する ● 少ないメモリで動作する ● レンダーパイプラインでの前処理 が複雑になる ● ストリーミングとの親和性が⾼い ● 可視オブジェクトを速く集め、ま とめて描画できる ● ジオメトリやマテリアルなどが同 じものでバッチ処理される ● ストリーミングとの親和性がよく ない HLOD ● メモリをたくさん消費する ● アセットに対して追加作業が必要 である ○ ワークフローが複雑になる ○ ⾃動化も難しい

データ指向インスタンシングの概要 各セクション内で同じ種類のオブジェクトが同じチャンク内に並ぶ ① ② ① ① ② ① ② ②

バウンディングボックスボックス チャンク単位でバウンディングボックスを作る

カリング ● チャンクのバウンディングボックスで視錐台カリングをする ● バウンディングボックスが境界にかかるときはインスタンス単位で判定する ● インスタンス単位の判定の際も連続するメモリにアクセスするためキャッシュヒットしやすい

GraphicsBuffer ● チャンク単位で GraphicsBuffer を作成する ● GraphicsBuffer にはチャンク内のそれぞれのインスタンスに必要な情報を格納する GraphicsBuffer Instance 0 Instance 1 Instance 2 Instance 3 Material Property Material Property Material Property Material Property Transform Transform Transform Transform etc. etc. etc. etc.

メタデータ カリング結果を反映してドローコールに必要なメタデータをチャンク単位で作る 3 2 3 1 0 2 0 1 GraphicsBuffer GraphicsBuffer Culled Instance 0 Instance 1 Instance 2 Instance 3 Material Property Material Property Material Property Material Property Culled Transform Transform Transform Transform etc. etc. etc. etc. Index 0 Index 2 Metadata Index 3

ドローコールのバッチ → → 3 2 3 1 0 チャンク単位でドローコールで構成する 結果として GPU に優しくバッチ処理される 2 0 Constant Buffers GraphicsBuffer Culled 1 Slot 0 0 2 3 … … … Culled Culled GraphicsBuffer Slot 1 0 1 … … Culled … 1 Culled … GraphicsBuffer Slot N 3 … … … 2 1 3 Draw Instanced 3 GraphicsBuffer 2 Culled 0 Set Resource Set Resource Draw Instanced …

結果 ジオメトリーだけが変わる場合 240 Event 240 Event 245 Event 293 Event 299 245 テクスチャだけが変わる場合 293 299

結果

エンティティとモジュールの数

Mega Objects オクルージョンカリング

Occlusion Culling Probe の概要 ⾒えないオブジェクトのレンダラーを先に除外する ことで不要なレンダリング処理を省く → 各グリッドはプローブを持っている → 各プローブは⾒えるオブジェクトの情報を持つ → プローブは事前にベイクする → 視錐台カリングよりも前に除外することで CPU や GPU の処理を削減する A C D B A C D

Occlusion Culling Probe の適⽤ → オブジェクトがボリュームと同じサブシーン内 になくてもレンダラー ID で参照できる → ボリュームコンポーネントだけのサブシーンを ⽣成してメインシーンに含める → サブシーンがロードされると、サブシーン内の オブジェクトコンポーネントがカリングの対象 になる

計測結果: CPU 条件 結果 → メッシュレンダラーの個数は 20,073 個 → 正⾯の建物による遮蔽が⼤きいシーン 無効 → → メモリ使⽤量: 約 80 MB増加 PlayerLoop: 約 3.6 ms 減少 (6.86 % 改善) 有効 Profile Analyzer での性能⽐較 (Galaxy Z Fold3)

計測結果: GPU 無効: 77 ms 20.78 % 改善 有効: 61 ms Snapdragon Profiler での GPU の性能⽐較 (Galaxy Z Fold3)

Mega Objects ツール

道路の⽣成 ベジエ曲線を編集して道路を⽣成する

プロシージャルなオブジェクトの配置 道路のベジエ曲線に対する平⾏曲線に沿ってブラシでプレハブを配置

プロシージャルなフォリッジ シミュレーションでフォリッジを⽣成

ワールドマスクマップのペインター ワールドマスクテクスチャをシーンで直接ペイントできる

Time-of-day 空

Sky Lighting Hillaire ⽒の 2020 年度の論⽂*をベースに実装 Transmittance 256x64 → ⼤気散乱 ‒ → ルックアップテーブルの更新 ‒ → レイマーチングの結果をルックアップテーブルに保存 テーブル別に周期を分けて更新 (プリベイク、タイムスライス) ⼣焼けによってオブジェクトが⾚く⾒える現象 ‒ SkyView 192x108 オブジェクト専⽤の透過率のルックアップテーブル (256x1) * Hillaire, Sébastien. “A Scalable and Production Ready Sky and Atmosphere Rendering Technique”. Eurographics Symposium on Rendering 2020. Multi-Scatt 32x32 Aerial Perspective 32x32x32

Sky Rendering 雲 → モバイル向けであるため軽量な 2D テクスチャベース → 昼夜の変化のため⼀定周期でテクスチャを更新 → 太陽と⽉が隠れるときの不⾃然さを別途補正 夜空 → ⽉: 2D テクスチャ → 星: キューブマップ → 時間の変化による星の回転 補正前 補正後

Smooth Day Transition → → → 昼から夜に変わるとき不⾃然に⾒える問題がある ‒ ⽇の出と⽇没の直後空が暗すぎる ‒ ⾃然に⾒せようとすると演算が増える 原因 ‒ 現在のモデルの特性から 1 個のライトでテーブルを⽣成 ‒ ⽉の明るさが反映されない Default Night 192x108 解決策 ‒ 事前にベイクした夜空のテーブルをブレンド ‒ 雲にも類似⼿法を適⽤ ‒ オブジェクトには太陽の⾼度によるフェードも適⽤ Default Cloud 512x256

設定の構成 可能な限りアーティストに優しい構成にする → 全域で共通のコンフィグを利⽤して管理する Scene (as component) Config Controller Renderer ┗ Config ┗ Atmosphere Profile Render Feature ┗ Time Profile ┗ Atmosphere Layer ┗ Orb Profile ┗ Cloud Layer Static ┗ Star Layer ┗ Moon Layer …

Orb Profile (軌道) → 太陽と⽉の軌道を管理 → ⾓度、⼤きさ、時間による位置などを調整

Time-of-day グローバルイルミネーション

グローバルイルミネーションの⼿法の⽐較 ライトマップやプローブベースの⼿法 ● 昼夜の変化に対応するには各時間帯のライト マップをベイクし補間する必要がある ● 枚数に⽐例してベイク時間とストレージ使⽤ 量が増加する ● ベイク時間とストレージ使⽤量はワールドの ⼤きさにも⽐例して増加する SDF 及び BVH を利⽤する⼿法 ● メッシュ単位で SDF をベイクすることでシー ンの構成が変わる度にライトをリビルドしな いといけない問題を回避できる ● シーンに存在するメッシュのバウンディング ボックスを利⽤することで BVH を速く構成で きる ● このように作られた SDF シーンを利⽤してイ ンダイレクトイルミネーションをリアルタイ ムで計算する

メッシュの SDF の⽣成及び BVH の構成 → シーン内のメッシュを収集し SDF を⽣成後、アトラステクスチャにパックする (GPU driven) → メッシュの AABB を利⽤して BVH を構築する (CPU or GPU driven) → BVH をレイトレーシングして適合する AABB を⾒つける → ⾒つかったメッシュの SDF をレイマーチングして衝突を検出する

Real Time Sky Lighting → → 空を IBL のソースとして扱うことで空からの拡散反射光を計算する ‒ L(⍵) : ⍵ ⽅向から表⾯に到達する sky radiance ‒ V(⍵) : ⍵ ⽅向の空が遮蔽されているかどうか (0 or 1) Sky Lighting の積分を分離できると仮定して近似する ‒ Sky irradiance はスカイボックスのキューブマップを ambient convolution 後 SH エンコード ‒ Sky visibility は距離制限のない AO のようなもので、SDF シーンを利⽤して計算

Real Time Sky Visibility 1. Trace Rays: 半分の解像度で空の遮蔽を計算 (ノイズのある状態) 2. Temporal Reprojection: 前のフレームの計算結果と合成 3. Denoiser: 境界を越えないでブラーフィルターを適⽤してノイズを除去 Trace Rays Temporal Reprojection Denoiser

違う時間帯の Sky Lighting の視覚化

最終結果 空の遮蔽を無視して間接光を適⽤ 空の遮蔽を適⽤して間接光を適⽤

Time-of-day シャドウ

カスケードシャドウマップの問題点 → オープンワールドのような広いスペースで適⽤しようとすると近景の影の解像度が落ちる → 解決するにはカスケードを増やすか、シャドウマップの解像度を上げる必要がある CSM 200m CSM 2000m

各⼿法の⽐較 Voxelized Shadow Map 8 CSM + Interleaved Update CSM + Contact Shadow Updated via interleaving ⾼解像度のシャドウマップを ボクセル化 Unite Seoul 2019 近距離の 4 つのカスケードは毎フ レーム更新し、遠距離の 4 つは 1 フ レームに 1 枚更新 Unite Seoul 2020 近距離: CSM 遠距離: Contact Shadow

各⼿法の⽐較 Voxelized Shadow Map 8 CSM + Interleaved Update CSM + Contact Shadow 利点 利点 ● 低コスト ● ⾼解像度の影が利⽤できる ● モバイルに使えるシャ ドウマップの⼤きさ ● ⾼解像度の近景の影 ⽋点 ⽋点 ● ベイクが必要 ● TOD のためには⾓度別 にベイク Unite Seoul 2019 ⽋点 ● シャドウマップマップ が⼤きくなる ● コンタクトシャドウ よ りドローコールが多い Unite Seoul 2020 ● SS 上の計算であるため 影の精度が低い

Contact Shadow → スクリーンスペースでレイマーチング → 深度テクスチャとサンプルポイントの Z を⽐較 → 解像度とサンプリング数以外は性能への影響は 少ない Depth - SamplePoint.z > 0 Depth - SamplePoint.z < 0

⽐較: 近景 CSM 800m CSM 100m + Contact Shadow

⽐較: 遠景 CSM 100m + Contact Shadow CSM 800m

まとめ

まとめ → バックグラウンド → Mega Objects → Time Of Day

今後の課題 → もっと広いワールド → グローバルイルミネーションのクオリティーの向上 → ネットワーク対応

質疑応答