エピック ゲームズ ジャパンが主催するアンリアルエンジンの大型勉強会「UNREAL FEST 2023 TOKYO」が、2023年6月2日（金）、3日（土）の2日にわたりベルサール秋葉原で開催されました。
初日には「『Hi-Fi RUSH』開発事例 グラフィックスと最適化紹介」と題する講演がありました。登壇したのは『Hi-Fi RUSH』の開発者であるTango Gameworks（ゼニマックス・アジア）のプログラマー、田中 康介氏と駒田 喬氏。
「リズムアクションゲーム」というジャンルゆえグラフィックスによる遅延が許されない状況で、いかにトゥーン表現を実現する描画パイプラインを構築したか、またいかに64,000枚ものコインがGPU物理シミュレーションで舞うステージを実現したのか、『Hi-Fi RUSH』の特徴的なグラフィックス技術の裏側に迫ります。
TEXT / 田端 秀輝
EDIT / 神谷 優斗
本セッションは『Hi-Fi RUSH』のゲーム紹介とグラフィックスに求められたスペックの紹介から始まり、田中氏による描画パイプラインの解説、駒田氏によるNiagaraによるGPU物理シミュレーションの解説が続きました。
キャラクターはトゥーンでも背景はPBR（Physically Based Rendering）で表現されるタイトルが多い中、『Hi-Fi RUSH』はキャラクター、背景、VFXなど、ゲームの中で描かれる世界のすべてが独自のトゥーン表現で描画されています。加えて、カットアウト（色数の削減）、Halftone、斜線ハッチングによるスタイライズ表現が特徴です。
『Hi-Fi RUSH』はリズムアクションゲームであるため、入力遅延の小ささが求められます。それゆえ、グラフィックスでの遅延は許されません。
ディレクターからは「絵のクオリティよりも60FPSを優先する」と開発初期から言われてきたとのこと
そこで、開発ターゲットであるXbox Series S、Xbox Series Xの想定解像度で60FPSが出せることが、本作のトゥーン表現の目標に設定されました。
※ なお、本作はWindowsでもプレイ可能
目標解像度はXbox Series SでWQHD（1440P）、Xbox Series Xで4K。最終的には、Steam Deckでも60FPSが出るパフォーマンスが実現できた
本作はUnreal Engine 4（以下、UE4）で開発されており、最終バージョンは4.27.2。60FPSを保ちつつ世界全体をトゥーンで表現する目標を実現するため、本作がどのようにDeferred Toon Renderingを実装したのか、見ていきましょう。
『Hi-Fi RUSH』ではエンジン改造を施し、UE4標準のディファードレンダリングの描画パイプラインを、以下のように拡張しています。
本作独自の描画機能。黄色い部分はUE4既存機能を独自にカスタマイズして実装した
なお、エンジン改造にあたってはマージ問題やプラグインの互換性を考慮して、以下の方針をとったとのこと。
本セッションでは、下記画像のシーンを例に描画パイプラインの説明が行われました。
上図のシーンでDeferred Toon Rendering用に生成される描画バッファ
上図のシーンにおけるGPUキャプチャ
Depth Prepassでは、シーン全体の深度バッファ（Depth Buffer）を生成します。
なお、Depth Prepassは、DBuffer Decalを有効化することで実行されるUE4標準のパスです。
Deferred処理では、複数の描画パスでワールド座標の計算に深度バッファが用いられる
UE4標準の影描写パスです。Dynamic Shadowを有効にしたライトごとにShadow Depth Textureを生成しています。
本作では、後述する影OnlyLightのSpotLightによるDynamic Shadowや平行光源のCascade Shadow Mapがここで描画されます。
パフォーマンスを考慮すると、Dynamic Shadowの使用は最小限に抑えるべきです。本作では、SpotLightのDynamic Shadowは専用の「影OnlyLight」でのみ使用できるようにしています。影OnlyLightを設置する「影LightActor」は、処理負荷に余裕があり、配置が効果的なシーンでのみ使用が許可されます。
影OnlyLight以外のSpotLightでは、Dynamic Shadowを無効にしている
影OnlyLightはShadowをCastする対象を制限できる。例えばプレイヤー用影OnlyLightでは、プレイヤーキャラクターであるチャイのみの影をShadow Passで描画する
最終描画結果では、プレイヤーであるチャイの影（中央）は斜線ハッチング表現でスタイライズされる。背景から落ちている影（左）は、Dynamic Shadowではなく後述するStatic Shadow Mapによるもの
モーションブラーやTAA（Temporal Anti-Aliasing）で使用されるVelocity BufferがVelocity Passで作成された後、Base Passが描画されます。ほとんどのマテリアルは、このBase Passで描画されます。UE4のディファードレンダラーにおけるGeometry Passに相当する、重要なパスです。
本作のBase Passは、主に「Deferred Toon Renderer用のG-Buffer作成」と「Forward Lighting処理のToonのLit/Shade決定とForward Lightによるライティングを行う」という2つの役割を持っています。
『Hi-Fi RUSH』のG-Bufferは、RGBA8 ×3枚（G-BufferA、B、C）の標準的な構成です。処理負荷の増加を考え、Deferred Toon Renderer用の追記情報についてはBufferを増やすのではなくG-Bufferのチャンネル用途を変更することで対応しています。
本作のトゥーン表現ではMetallicとSpecular、G-BufferAO情報は不要だったため、その中でも修正箇所が少ないであろうSpecular、G-BufferAOをDeferred Toon Renderer用追記情報の格納に使用した
追記情報を格納する手段としては、UE4の「Custom Stencil」機能も選択肢となりますが、この機能を使用したオブジェクトには新たにCustom Stencil用の描画パスが追加されるため、処理負荷が増加します。
本作ではCustom Stencilを、回復アイテムを取得したときのハイライト処理など、オブジェクト単位に設定するものや使用頻度が低いものに使用した
そこで、本作では前述した不要なG-Bufferのチャンネルを、Stencil Bitとして扱うよう改造しています。この「G-Buffer Stencil」と呼称される機能により、Stencil機能をMaterial単位でかつ処理負荷を気にせず使えるようになりました。
G-BufferAOのG-Buffer Stencil Bitフラグ。キャラクター判別やPost Process Outlineの処理スキップに使用
SpecularのG-Buffer Stencil Bitフラグ。平行光源や影OnlyLight、各種ライティング効果の適用Skipに使用
なお、G-Buffer StencilはG-Bufferを持たないUnlitやTranslucentマテリアルには使用できませんが、これらのマテリアルはそもそもDeferred Toon RendererによるToon処理を行わないため問題にはならなかったそうです。
メインのLighting処理はDeferred Passで行われますが、Forward LightingはBase Passの段階で計算されます。Forward Lightingを導入したのは、Base Passでの処理ゆえエンジン改造が不要であり、ライティングの試行錯誤がしやすかったからだそうです。
Toon処理におけるLit/Shade状態はBase Passで計算します。Lit ColorはG-BufferCのBase Colorに格納しています。Shadow ColorはIsShadeMaskフラグをG-Buffer Stencilに格納し、実際のShadow Colorはフラグを用いてDeferredで後続のPassで決定しています。
上記画像は室内のシーンなので全面でIsShadeMaskフラグが立っており、Shadow Colorで描画されている
上記画像のシーンではForward LightingのCutout機能を使用している。専用Forward Lighting Actorを配置してシーンをライティングしている
Forward Lightingの計算結果によりマイナスライトになった場合、後続のDeferred処理が暗くなりすぎる問題が発生したが、G-Buffer StencilにIsForwardLitビットを追加し後のパスで調整している
Base Passまでが完了し、ここまでで深度バッファ、Shadow Depth Texture、G-Bufferが生成されています。
左上が深度バッファ、左下がShadow Depth Texture。上段右から3つがG-Buffer×3
Base PassのあとにはUE4標準のSSAOでAmbient Occlusionを描画するパスが続きます。
SSAOの描画結果。光り具合などの調節はPostProcess Volumeなどで行っている。この段階ではキャラクターやEmissiveにもSSAOが描画されている
最終描画段階では、G-Buffer Stencilを利用してキャラクターやEmissiveにはSSAOがのらないようにしている。また、後述するパスによりSSAOに斜線ハッチングのスタイライズ表現が適用される
上記画像の拡大部分にも斜線ハッチングが使用されている。距離によるフェードを導入することで主張しすぎないよう調節した
Capsule ShadowもUE4標準のものを使用しています。
前述の通り、Dynamic Shadowは処理負荷の高さから使用を制限しています。本作では処理負荷の低いCapsule Shadowを使用することで、シーンのライティングに関わらず常にNPC、Partner、敵キャラクターの影を落としています。
Capsule Shadowの描画結果。UE4標準ではSSAOと同じRender Targetで描画されるが、本作ではエンジン改造により独自のRender Targetで描画される
Capsule Shadowにも斜線ハッチングをかけている
World Volume Lighting Passは、UE4のVolumetric Lightmapを改造したProbeベースのGlobal Illumination（GI）パスです。
UE4標準のVolumetric Lightmapではレベル単位でベイクされますが、World Volume Lighting PassではActor単位です。
画像中央にあるデータスフィアを囲むようにWorld Volume Lighting Volumeが配置され、Volume内の空間限定でVolumetric Lightmapがベイクされている
これにより、ベイクにかかる時間を短縮できるほか、球面調和関数によるAmbient情報のみを保存するように改造したためデータも軽量化。また、描画範囲をVolumeの空間内に制限できるため、描画処理が高速化します。
可視化したProbe（画像中の黒いSphere）。配置された複数のWorld Volume Lighting VolumeそれぞれでProbeが生成されている
World Volume Lighting Passの描画結果。Static LightやEmissiveによるDiffuse GIが反映されているのがわかる
World Volume Lightingの最終描画結果
AO Volume Passは今回新規で追加した描画パスです。
物体との距離が遠くCapsule Shadowの影が届かないときの丸影を描画します。主人公チャイの周りで浮いている猫型ロボット808や浮遊している敵などは地面から離れているため、このパスで影が描画されます。
AO Volume Passによる影にも斜線ハッチングをかけている
UE4の標準ディファードレンダリングのShading PassにあたるLighting Passは、エンジン改造により、独自Deferred Lightの描画と、影OnlyLightのタイプ情報を描画するPassになっています。
32-bit HDRについて見ていきましょう。本作ではパフォーマンスの都合からr.SceneColorFormatをデフォルトの64-bit HDR Scene Colorではなく32-bit HDR Scene Colorにしています。
ただし、32-bitにするとR11G11B10形式となり、Alpha Channelがなくなってしまいます。ライティングの結果に影タイプの情報を書き込むのにAlpha Channelが必要だったため、新規追加した独自描画パスで32-bit HDRのSceneColorを64-bit HDRの新たなLighting Bufferにコピーしています。
続いて影有りライトに対し、UE4標準パスのShadow Projectionパスを実行します。
今回のシーンでは、プレイヤー用の影OnlyLightのShadow Mask Textureを描画。Shadow Passで生成したShadow Depth TextureをScreen Space投影している
次のパスで実際にDeferred Lightを描画します。なお本作ではエンジン改造しているため、Deferred Lightではなく、独自のDeferred Toon Lightを描画しています。
例に挙げたシーンでは、プレイヤーの影OnlyLightがDeferred Toon Lightとして処理されている。影OnlyLightにはShading処理は行われず、Alpha ChannelへのShadowのタイプ情報の描画のみ行われる
Deferred Lighting Passの描画結果。Lighting BufferのRGB Channelにはライティングの結果が描画される
Lighting PassのAlpha Channel。Shadowのタイプ情報が書き込まれている。上記の場合、プレイヤーの足元に描画されている影がプレイヤーの影であると識別する情報が書き込まれている
下記画像がLighting Passでの生成バッファです。
左上からSSAO、Capsule Shadow、AO Volume Pass。右下からWorld Volume Lighting、Lighting PassのAlpha Channel、そしてLighting PassのRGB Channel
Lighting Passの次はReflection Passです。ReflectionにはUE4標準のScreen Space Refrection（SSR）を使用しています。パフォーマンスを考慮して、SSRの品質はmedium（no glossy）設定を採用しています。
次は、本作独自の「SSR Mipmap」生成パスです。本作ではGlossy表現をMipmapのボケを使用した簡易的な表現で独自実装しています。
Reflectionの最終パスで、先ほど生成したSSR Mipmapを用いたGlossy計算とトゥーン調のスタイライズ処理を行います。
Roughness値が高いほど低解像度の（よりボケが強い）Mip Levelを参照することで、処理負荷の軽い簡易的なGlossy表現を実現しました。
Glossy計算はSSR Mipmapを参照し、アーティストが作成したRoughness – Miplevel変換テーブルを使用して行う
スタイライズでは、4段階にGlossy SSRの色情報を単純化するPosterize Cutout化と、SSRの輝度に応じてサイズを変化させるScreen Space Halftoneを施しています。
Reflection Passの処理をすべて反映したもの
Static Shadow Map Passも新規追加した描画パスです。アーティストが影を利用できるよう、静的影をベイクできる仕組みとして用意されました。
Static Shadow Mapには2つのメリットがあると田中氏。ひとつは、Depth Pass不要である点とVolume内に描画範囲を制限できる点による負荷の低さ。
もうひとつが、アーティストが狙った位置に狙った影を落とせる、2D的な絵作りとの相性のよさです。
Static Shadow Map Passの描画結果
上記画像では、プレイヤー以外の影はすべてStatic Shadow Mapによる静的影。アートディレクションによりStatic Shadow Mapには斜線ハッチング表現をかけないケースも多いが、上記画像の拡大部分のようにかけることもできる
Decal Light Passも新規追加した描画パスです。
Decal Lightはシェーディング計算は行わず、狙った形状のライトをオブジェクトに投影する投影ライトとして使用しています。
星のような形状のライトを地面に投影している
投影範囲を指定するDecal Light Decal Volumeを使用することで描画面積を減らすことができる。上記画像のように地面に薄くVolumeを配置すれば、Decal Lightは壁などには描画されず、地面の部分でのみ描画される
Render Target別のDecal Light Passの描画結果。こちらはDecal LightのLighting Buffer
こちらのRender Targetには、後述のDeferred Toon Rendering Shading PassでBase Colorが調整できるよう、RGBにはRGB調整色を、AlphaにはDecal Lightの最終計算結果のBlend率を入れている
Post Process Outline Passも新規追加した描画パスです。トゥーンレンダラーに多用されるアウトラインを生成するためのパスです。
本作ではポストプロセスによるアウトラインはキャラクターには採用せず、背景にのみ使っています。Depth Outline、Normal Outlineを計算し、画面内のメッシュが占める領域の内側に描画しています。
一方、キャラクターのアウトラインには背面法を採用しています。というのも、メッシュの内側に描画するアウトラインでは、カメラを引いた時にキャラクターがアウトラインで黒つぶれしてしまうためです。
なお、キャラクターと背景はG-Buffer Stencilを利用して判別している
Post Process Outline Passでの描画結果。キャラクターには使用していないため、キャラクターのアウトラインはここでは表示されない。また、遠方の背景も描画しないように距離フェードが反映されたAlpha値も格納している
下記画像がLighting Pass後からPost Outline Passまでの生成バッファです。ここまでで、Deferred Toon Rendering用の入力バッファはすべて生成されました。
左上から、Reflection Pass、Static Shadow Map Pass、Decal Light Pass × 2、Post Process Outline Pass
Toon Post Process Passは、Deferred Toon RenderingにおけるShading Passです。これまで計算してきたG-Bufferやその他の描画結果を利用して最終的なトゥーンシェーディング処理を行います。
Toon Post Process Passが利用する描画バッファ。Toon Post Process Pass単体のパスで最終描画まで行うことで、プレイヤーの動的影がStatic Shadow Mapの影と重なった時にどうするかなど、各要素の相互影響を考慮に入れて描画を行うことができる
Toon Post Process Pass実行前（左画像）と実行後（右画像）のScene Color
通常のディファードレンダリングのShading PassではライトをライトのGeometryで描画します。
通常のディファードレンダリングでは、Point LightならSphereを描画、Spot LightならばConeを描画する
それに対し、Deferred Toon Post Processでは、Box形状のDeferred Toon Post Process Volumeで囲まれたGeometryに、同Volumeで指定されたパラメーターに基づいてToon Post Processを適用します。
例えば上記画像において、Deferred Toon Post Process Volumeの中と外では、Toon Color、Ambient Color、SSAOの乗り具合が別パラメーターで描画されている
これにより、ポストプロセスのパラメーターを空間単位で調節でき、より柔軟なトゥーン表現が可能となります。
上記画像では、エリア全体を囲むVolumeのほか、中央にあるデータスフィア付近にもVolumeを重ねて配置し、場所ごとに雰囲気を調整している
Deferred Toon Post Process Volumeの重なりは、描画済みかどうかを判別するフラグをCustom Stencilのbit0に格納し、描き込み時にフラグをチェックすることで、同じピクセルに対し複数回の描画がされないよう最適化しています。
UE4におけるCustom Stencilのbit0は、Sandbox Stencilとしてシェーダー内で自由な使い方ができる
Lit Base ColorはBase Passで決定される一方で、Shadow ColorはDeferred Toon Post Process Passで決定されます。
空間に対する色情報を格納した3Dテクスチャを変数として持つShadow Color Volume Actorをシーンに配置することで、空間単位でShadow Colorを調整しています。
画像右にある3Dテクスチャの色がシーンに適用されている
また、6方向のAmbient Cubemapを使い、3D空間に対して大まかな陰影づくりをしています。
3Dのように見えるのを避けるため、グラデーションが目立たないように調整されたテクスチャを使用している
画像右のCubemap Textureが、メッシュのそれぞれの面に対してAmbient Lightとして適用されている
なお、Shadow Color VolumeやAmbient Cubemap Volumeの処理は負荷軽減のため独自描画パスを追加せず、このToon Post Process Passで行っています。
ここまでのパスでのライティング結果がこのToon Post Process Passで最終描画結果に適用されます。まだスタイライズが行われていないパスに関しては、Litに対してはHalftone、Shadowに対しては斜線ハッチングを適用する処理が行われます。
SSAOの斜線ハッチング（下の拡大部分）やWorld Volume LightingのHalftone（上の拡大部分）などはここで適用される
ここまでで紹介したように描画パスを拡張しつつ、それでも60FPSの目標が実現できたのは「技術の採用の段階でパフォーマンスを意識したこと」と「軽い処理負荷でトゥーン表現の3D描画処理をどう実現するかを考えたこと」が大きかった、と田中氏。あらためて拡張方針を振り返り、描画パイプラインについてのパートを締めました。
※ 以下、ゲーム終盤のシーンの紹介が入りますのでネタバレにご注意ください
ここからは、駒田氏がNiagaraによるGPU物理シミュレーションについて解説しました。
本作では、床にコインがギッシリ配置された部屋で戦闘するシーンがあり、シーン内では、キャラクターやギミックの動きに応じて飛び散るコインのエフェクトが発生します。
開発においては制作コストを考慮し、手付けではなく物理シミュレーションでコインの飛び散りを表現しました。
床に配置されたコインが飛び散るシーン（ゲーム終盤のシーンのため、ネタバレにご注意ください）
コインのエフェクトには、以下の要件が求められました。
そこで、簡易な剛体シミュレーションをNiagaraで実装し、GPU上でシミュレーションを実行する方針をとりました。
当該ボスと戦闘するシーンでは、シミュレーション範囲を指定するボックス形状のVolumeが配置されており、その底面に64,000枚のコインパーティクルがスポーンしています。配置されたコインは、キャラクターやギミックとの衝突により飛散します。
コインは碁盤目状に配置されると飛散軌道に不自然な対称性が出てしまうため、ランダムに配置しています。
実際のVolumeの底面はコイン床のスタティックメッシュに覆われているため、パーティクルのコインはコイン床メッシュから飛び出たときのみプレイヤーの目に触れます。動かない大量のコインで覆うことで、少ないコインを飛び散らせるだけでも見栄えがするとのこと。加えて、飛散していないコイン同士のめり込みを隠せるため、コイン同士のコリジョン判定を計算する必要がなくなります。
Volumeを実際の床から少し浮いて配置することで、コインの飛散が上方向になり見栄えがよくなる
コインは、Volumeのほか、キャラクターおよびギミックに追加した専用コライダとコリジョンします。
プレイヤーには、身体部分にカプセルコライダ、足元にスフィアコライダが設定されている
物理シミュレーションには挙動の安定性からPosition Based Dynamics（PBD）が採用されています。
コインの物理シミュレーション処理は、毎フレーム実行されるParticleUpdate内の「コライダの更新」「スリープ状態の更新」「積分」「コリジョンコンストレイント解決」で構成されています。
キャラクターとギミックのコライダは移動や増減があるため、コライダの更新が必要です。
そこで、毎フレームVolume内にある特定のObjectTypeを持つコライダを検出し、コライダの形状、位置、向き、サイズ情報をシミュレーションに渡しています。
各コインは床の動摩擦により速度が一定値を下回ったらスリープ状態に移行します。スリープ状態では描画およびシミュレーション処理をストップし、負荷を削減。また、コインの移動による配置ムラを防ぐため、スリープ時に初期配置位置に戻ります。スリープ状態のコインは、キャラクターやギミックのコライダが一定距離に近づいたらスリープが解除されます。
コインが飛び散る様子と、スリープに入りコインが初期位置に戻る様子
積分処理では、通常のPBDと同様の処理に加え、剛体であるため向きと角速度も扱っています。
コリジョンコンストレイント解決では、通常の剛体シミュレーションであればコリジョンをメッシュと同じ円柱形状で扱うところ、今回は計算量を減らすためにディスク形状として扱っています。
ディスクの中で最も深くコリジョンにめり込んだ点のみを衝突点として近似している
コリジョンしたコインには、「めり込まない位置にコインを移動させるための押し出し」と「Volumeに当たった際の反発力と動摩擦の適用」の2つの処理を行っています。また、Volumeとコライダは無限質量扱いとし、コインのみが位置調整されるようにしています。
キャラクターとギミックに対しては反発と動摩擦がなくても表現としては問題がなかったとのこと
パフォーマンスを測定したところ、シミュレーションと描画をあわせた処理時間は1.0msに収まった
最後に駒田氏の経験から、GPU物理シミュレーションを実装する際は、「ステップ実行が容易なCPU側で十分な検証と実装を済ませてからGPU側に移植する」「精度の観点から、シミュレーションはワールド座標系ではなくローカル座標系で行ったほうがよい」というアドバイスがありました。
配置コインの64,000枚は「GPU物理シミュレーション」という設定項目がデフォルトの「低」になっているときの値で、これを「中」にすると128,000枚、「高」にすると256,000枚になる。「高」だと飛散枚数が多すぎてプレイヤーキャラであるチャイが見えにくくなるので難易度も上げることができる…とのことだが、駒田氏曰く残念ながらこれについて触れているレビューを見たことがないそうだ
© 2023 Bethesda Softworks LLC, a ZeniMax Media company. HI-FI RUSH, Tango, TangoGameworks, Bethesda, Bethesda Softworks, ZeniMax and related logos are registered trademarksor trademarks of ZeniMax Media Inc. in the U.S. and/or other countries. All Rights Reserved.
「ゲームと社会をごちゃまぜにして楽しんじゃえ」がモットーの、フリーのコンテンツ開発者。節電ゲーム「#denkimeter」やVRコンテンツ、体験型エンタメの開発をしています。モニター画面の中だけで完結しないゲーム体験が好きで、ここ十数年注目しているのはアイドルマスターです。
西川善司が語る“ゲームの仕組み”の記事をまとめました。
Blenderを初めて使う人に向けたチュートリアル記事。モデル制作からUE5へのインポートまで幅広く解説。
アークライトの野澤 邦仁（のざわ くにひと）氏が、ボードゲームの企画から制作・出展方法まで解説。
ゲーム制作の定番ツールやイベント情報をまとめました。
東京ゲームショウ2024で展示された作品のプレイレポートやインタビューをまとめました。
CEDEC2024で行われた講演レポートをまとめました。
BitSummitで展示された作品のプレイレポートをまとめました。
ゲームメーカーズ スクランブル2024で行われた講演のアーカイブ動画・スライドをまとめました。
CEDEC2023で行われた講演レポートをまとめました。
東京ゲームショウ2023で展示された作品のプレイレポートやインタビューをまとめました。
UNREAL FEST 2023で行われた講演レポートをまとめました。
BitSummitで展示された作品のプレイレポートをまとめました。
ゲームメーカーズ スクランブルで行われた講演のアーカイブ動画・スライドをまとめました。
UNREAL FEST 2022で行われた講演レポートやインタビューをまとめました。
CEDEC2022で行われた講演レポートをまとめました。
