つぶやく
 |
講演では，都市型オープンワールドRPG「NTE: Neverness to Everness」（PC / Mac / PS5 / iOS / Android）の巨大な街を，PCとモバイルの両方でどう動かしているかが紹介された。
ロード画面なしで街を横断し，人混みの中を歩き，街灯の並ぶ通りを車で走る。これをPCとモバイルの両方で実現するのは，非常に大きな技術的課題だったという。
 |
Shi氏曰く，この規模のシームレスな世界を実現する核心は2つある。
CPU側では処理ごとに使える時間を割り振って管理すること，GPU側ではグラフィックスパイプライン（描画の工程の流れ）をうまく組み立てることだ。
前半はShi氏がロード，NPC，グラフィックスパイプラインの全体像を，後半はZheng氏が具体的な描画機能と各プラットフォーム向けの最適化を解説した。
NTEには，ロード画面やマップの切り替えを挟まずに別の次元へ移る体験が多くあり，周囲のアセットが急に現れることもないように作られている。
Shi氏は高速なアセットローダーを自作するアプローチではないと話し，単純な読み込み速度は本当の解決策にならないとも続けた。
 |
仕組みとしては，プレイヤーが立ち止まっている間に，目的地のエリアの準備を裏で並行して始める。
目的地の座標に一時的なWorld Partition Streaming Source（UEで周囲のエリアを読み込む基準点）を置き，プレイヤーが実際に移動する前に読み込みを先に始めておくという。
 |
Streaming Source自体はUE標準の仕組みだ。NTEではロードシステムを作り直すのではなく，事前ロード，準備完了の判定，空間の移動，ゲームプレイの復帰を連携させ，1本のテレポートの流れにまとめた。
 |
テレポートは，ワールド内のステートマシン（段階ごとに状態を切り替えながら進む仕組み）として設計されている。
目的地を準備し，準備が整ったことを確認してから移動し，移動後もワールドとゲームプレイの安定を確認してから操作をプレイヤーに戻す流れだ。
 |
準備完了の判定は，リソース，ワールド，ゲームプレイの3段階に分かれている。ロード完了の通知が返っても，満たされるのはリソースの段階だけだ。
徒歩なら接地，運転中なら車両の物理状態を復元するなど，ゲームプレイが安定して初めてプレイヤーの入力を戻すという。
 |
メモリの面では，出発地を保持したまま目的地を読み込むため，2つのエリアが同時にメモリを使う時間帯が生まれる。
目的地が遠いほど共有できるデータは少なくなるため，読み込む範囲，移動のタイミング，出発地の解放を管理し，合計をプラットフォームごとの上限に収めることが難しいところだという。
 |
あわせて，UEのFast Geometryでエリアのメモリコストそのものも下げている。
開発時のビルドの段階で，条件を満たすアクタを軽量なデータに変換しておき，個々のアクタを生成する手間を省くことで，目的地を有効にするときのメモリとCPUの負荷を抑えられるそうだ。
Shi氏は，Fast Geometryはあくまで負荷の山をならす補助で，テレポートの制御そのものではないと強調した。
 |
Shi氏は，シームレスなテレポートは魔法でもロードゼロでもなく，読み込みの1ミリ秒1ミリ秒を完全に制御下に置くことだとまとめた。
最大の成果は単一のプラグインやモジュールではなく，連続した1つのワールドの中に，制御可能なテレポートの流れを持てたことだという。
 |
目的地の準備が整ったあとは，そこを大量のNPCで満たす必要がある。ここで使われるのが，大量のキャラクターなどをまとめて効率よく動かすためのUEの仕組みMassだ。
 |
ここでいうNPCには，歩行者だけでなく交通車両も含まれる。遠くにいる間は軽いデータとして扱うためコストはごくわずかだが，多数のNPCが同じフレームで，物理やアニメーションを持つアクタに一斉に切り替わろうとすると，メインスレッドが一気に圧迫される。
 |
目的はNPCの数を減らすことではなく，重い処理を時間的にばらすことだという。その手段として挙げられたのが，次の3つだ。
 |
1つめは，LOD（距離に応じて表示の細かさを切り替える仕組み）の計算に使うデータを安定させることだ。
距離やLODの計算をワーカースレッドに任せたうえで，データの写しを3つ用意して順番に使い回すトリプルバッファを導入し，読み取り中のデータが書き換えられないようにしている。
これにより，メインスレッドの負担を減らしつつ，計算に使うデータを安定させているという。
 |
2つめはゲート式のコミット。アクタ化が必要と判断しても，すぐには生成しない。まず要求を記録し，準備状況とそのフレームで使える処理の枠を確認したうえで，アクタの生成や再利用を行う。
条件が満たされなければ，待機や再試行に回す仕組みだ。
 |
3つめは上限のある負荷だ。更新頻度，対象にする範囲，1フレームにアクタ化できる数の上限を共通の枠で管理し，重い処理を1フレームに何回まで実行するかを決めている。
たとえばカメラの切り替えでアクタ化の要求が一気に増えても，枠を確保できなかったNPCは軽いデータのまま残り，アクタ化は後のフレームに回される。
 |
Shi氏は，Massの効率的な仕組みの核は残しつつ，3つの制御ポイントで実行時の処理を作り直したとまとめた。
 |
その効果は負荷テストで検証された。Snapdragon 8 Elite Gen 5を搭載したAndroid端末で，NPC 300体をすべて動かしたまま，1フレームあたりのアクタ化の数だけを制限した。
その結果，同じフレームで生成されるアクタの数は最大242から3に減り，スパイク（処理時間が一瞬だけ跳ね上がること）の出たフレーム数とMassの処理時間も下がったという。
Shi氏はこれを，世界の人口を減らすのではなく，重い表現のために処理の枠を組めばよいという一言でまとめた。
 |
続いてShi氏は，PCとモバイルの描画の流れの全体像を示した。
形状の準備，ライティング，ポストプロセスと出力という流れは共通だが，品質，帯域，消費電力のバランスを取るため，それぞれで工程の組み方を変えているという。
PCでは反射や水面にLumenとSSRを条件に応じて使い分け，超解像はDLSSがデフォルトとのこと。
 |
モバイルでは，AndroidとiOSで同じモバイル向けディファードレンダリングを使っている。たとえば，同じ画素を何度も描き直す無駄の主な原因になる，葉のように切り抜きで形を作る植生だけを先に奥行きの処理にかけ，無駄な描画を避けている。
対応する環境では，ライティングまでを1つのRender Passの中でつなぎ，GBufferの読み書きをGPU内部の高速なメモリで済ませることで，外部のメモリへの読み書きを減らしているという。
ポストプロセスは，消費電力と発熱に最も直接影響する部分だ。モバイルではGPUの処理時間はもちろん，帯域と消費電力も同じくらい重要だとShi氏は話した。
 |
PCでの主なボトルネックはGPUの演算時間で，帯域に余裕があるため画質を優先している。
一方のモバイルは，帯域と発熱，消費電力がボトルネックになる。Shi氏はこれを，PCは演算性能で見た目の上限を伸ばし，モバイルは工程をまとめてハードウェアの限界内に収めると表現した。
 |
後半はZheng氏が登壇し，マルチプラットフォームでのスケーリングについて説明した。PCでは2社のCPUと3社のGPUに対応し，モバイルはSnapdragon 855とiPhone 12 Proまでを公式にサポートしている。
モバイルではピーク性能がすべてではなく，消費電力，発熱，ドライバの違いの影響が大きい。最初の5分は快適に動いても，遊び続けるうちに急激にクロックが落ちることがあるという。
 |
PCではディスタンスフィールドシャドウ，ボリュメトリック，Lumen，ハードウェアレイトレーシングといった重い機能を使う一方，モバイルではそれらを意図的に削っている。
ただ，モバイル版のLumenによる間接光はすでに開発が進んでおり，近く導入される予定だという。
Zheng氏は，モバイル版はPC版の描画を落としたものではなく，帯域，発熱，モバイルのドライバに合わせて一から設計したものだと強調した。
 |
画質設定の仕組みには，UE標準のDevice ProfileやScalability Groupをそのまま使い，NTE独自の作業はその外側に加えている。
GPUや機種ごとのDevice Profileの選択，Lumenやレイトレーシング，超解像，フレーム生成の実行時の切り替えなどがそれにあたる。
 |
これらは1つの画質設定にまとめられており，値が変わると，UE標準の設定と，物理や半透明のライティングといったNTE独自の設定がまとめて切り替わる。
 |
PCでは，起動時にGPUの名前から最も近い専用のDevice Profileを選ぶ。CPUの性能区分は，Device Profileを選んだあと，機能の初期値の判断などに使うそうだ。
 |
モバイルでは機種の完全一致を優先し，Xiaomi 14のような個別の端末の設定にまでたどり着く仕組みになっている。
 |
Device Profileはあくまで出発点だ。
Lumenとハードウェアレイトレーシングは画質設定がEpicとCinematicのときにのみ選べるうえ，GPUのメーカーやランク，CPUの区分といった実行時のチェックをすべて満たした場合にだけ有効になるという。
 |
Zheng氏は，こうした設定や例外は1つも推測で決めていないと話す。端末を等級に分け，決まったルートを自動で走らせて計測し，長時間のプレイで検証してから設定を公開しているそうだ。
 |
たとえば，AndroidではVulkanを標準としつつ，一部の端末ではOpenGL ESに切り替えたり，Vulkanの一部機能をオフにしたりしたほうが安定する場合がある。
現在，OpenGL ESへの切り替えを判断するリストは175件あり，うち115件で切り替えを強制しているという。
 |
アンチエイリアスや超解像，フレーム生成も，この仕組みで端末ごとに切り替えている。
PCではTAA，SMAA，TSR，FSR3，DLSSを使い分け，モバイルではGSRやAFME，Huaweiのハードウェアフレーム補間などに対応している。
 |
最終的には，すべての端末で安全に動く共通の設定を用意したうえで，対象ハードウェアの約90〜95％がGPUや機種ごとの設定に一致すると見込んでいる。
390件以上の独自のDevice Profileと例外の設定によって，既知の端末では妥協のない最適化を提供しているという。
 |
続いてZheng氏は，指向性ライトの影を取り上げた。建物や植生，交通が密集し，描画距離も長い巨大な都市では，影の処理が大きな悩みになる。
さらに昼夜のサイクルがあるため，影をあらかじめ計算して画像に焼き込んでおく手法は使えない。
 |
NTEの昼夜システムでは，24時間を12の時間帯に分け，それぞれの時間帯の中では太陽の位置を固定している。太陽の向きがしばらく変わらないため，シャドウマップを安全に使い回せる期間を作れるという。
 |
PCとモバイルは同じ見た目を目指しつつ，処理の余裕の違いから方針を分けている。
PCでは，一度描いた影を使い回せるCSMを使い，モバイルでは近景だけをCSMにして，遠くの動かない物体の影は新たに作ったLayered Shadow Map（LSM）に任せている。
 |
PCでは，カメラが動いたときに使い回せる部分の影はコピーし，新たに見えるようになった帯状の部分だけを描画する。
ところが，NTEの街はインスタンシング（同じモデルをまとめて描く仕組み）に大きく頼っており，広い範囲に散らばったモデルをまとめて囲む巨大な判定用の箱が，新しい帯の中に実際には何もなくても，重なっていると判定されてしまう。
 |
その結果，わずかなカメラの回転でも使い回しができなくなり，シャドウマップ全体の更新が走って，GPUへの影の描画命令が大量に発生していたという。
 |
そこでNTEでは，カメラに映る範囲をシャドウマップの空間に投影し，今の視点で実際に見える範囲を求めた。
新しい帯がこの範囲の外にある間は更新を保留し，範囲と交わった時点で初めて更新する。画面上の影の品質は落とさず，まだ見えない部分の計算だけを省いているわけだ。
 |
これにより，通常のカメラの回転や移動では，シャドウマップ全体の更新が約90％減った。カメラが止まっている場面でもPCの影のGPU負荷が約20〜30％下がり，ハードウェアによっては0.2〜1ms以上の短縮になったという。
 |
モバイルでは，CSMを遠景まで広げると描画命令が膨大になり，カメラが動くたびに大きなカクつきにつながる。そのため，遠景には更新のペースを厳しく制御できる別の仕組みが必要だったという。
 |
それがLSMだ。LSMはカメラを中心に周辺の動かない物体の影を保存するもので，カメラの向きではなく位置に紐づいている。
そのため，カメラを回しても描き直す必要はなく，プレイヤーが一定距離以上動いたときや，光の向きが変わったときだけ更新する。
 |
更新の際も，影の範囲を複数のタイルに分け，1フレームに限られた数だけを描画していく。描画中は前回完成したLSMを使い続け，すべて描き終えてから差し替える。
なお，遠くでは見た目への影響が小さいため，LSMでは動く物体の影を扱っていないそうだ。
 |
カメラが平行移動しただけで新旧の範囲が大きく重なる場合は，重なった部分の影をコピーし，新しく現れた部分だけを更新する。
 |
コピーした範囲に新しい物体が現れても見落とさないよう，影を描いた物体の情報も引き継ぎ，まだ描いていないものだけを追加で描画しているという。
 |
Androidで4段のCSMを使う方式と，2段のCSMに2層のLSMを組み合わせた方式を比べたテストでは，LSMを使った方式で遠景の更新によるスパイクがなくなり，フレーム時間がより滑らかになったそうだ。
 |
講演では，公開中のバージョンをiPhone 16 Proで動かした映像も流され，遠くまで届く影と近景のくっきりした影が両立している様子が紹介された。
 |
Zheng氏は，PCとモバイルで影を使い回す仕組みは異なるものの，最適化の原則は同じで，使い回しを最大にし，更新は本当に必要なものに限ることだとまとめた。
 |
講演後には，Slidoで寄せられた質問への回答も行われた。
Streaming Sourceの扱いについて問われると，Shi氏は，Streaming Sourceの動作そのものには手を加えておらず，変えたのは呼び出すタイミングだけだと回答した。
早めに動かすことで負荷を分散し，テレポートの前に目的地の読み込みを終えられるようにしているという。
ローエンドのモバイル端末向けの工夫を聞かれると，最も多くの最適化を入れているのがローエンド端末だと答えた。
帯域や描画命令の数を抑え，AOやSSRなど画面全体にかかるポストプロセスを削るほか，TAAにも厳しい制限をかけているそうだ。
チーム内の運用については，エンジン担当とプロジェクトの開発担当を比較的切り離し，性能の計測や処理の枠の配分は基本的にエンジン側で決めていると説明した。
別々の担当者が同じ最適化のアイデアにたどり着くこともあるが，議論を通じてよりよい最適化につながるので，合理的だと考えているそうだ。
