ヴァルキリーエリュシオンのグラフィックス表現とコストとパフォーマンスの工夫【UNREAL FEST WEST ’22】
124K Views
November 21, 22
スライド概要
講演アーカイブ：
https://youtu.be/3FBCeEtHoRE
講演内容：
スクウェア・エニックスから発売中『ヴァルキリーエリュシオン』の個性的なグラフィックスを実現するための工夫や、短めの開発期間に対応するための工夫、苦労したことなどをお話します。
講演者：
田中 達大 (ソレイユ株式会社)
尾田 委久 (ソレイユ株式会社)
アクションRPG『ヴァルキリーエリュシオン』についてはこちら：
https://www.jp.square-enix.com/v_elysium/
UNREAL FEST WEST ’22 公式サイト：
https://unrealengine.jp/unrealfest/west2022/
Unreal Engineを開発・提供しているエピック ゲームズ ジャパンによる公式アカウントです。 勉強会や配信などで行った講演資料を公開しています。 公式サイトはこちら https://www.unrealengine.com/ja/
関連スライド
各ページのテキスト
ヴァルキリーエリュシオンのグラフィックス 表現とコストとパフォーマンスの工夫 ソレイユ株式会社 田中達大・尾田委久
はじめに 制限事項、注意事項 • この講演の撮影・録音・録画は禁止です。 • SNSへの投稿はテキストのみ可とします。写真、動画付きの投稿は禁止です。 • この講演で表示される画像・動画はスクウェア・エニックスの著作物です。許可なしに撮影、転載などは 出来ません。 2
自己紹介 田中達大 ソレイユ株式会社 シニアソフトウェア・エンジニア 主にUnreal Engineに関するR&D、社内プロジェクトの技術協力などをしています。 ゲーム業界歴３０年以上の古参ですが、本人はまだまだ現役だと思いこんでいます。 3
自己紹介 尾田委久 ソレイユ株式会社 リードテクニカルアーティスト ライティング、マテリアルなど描画を中心としたアートのサポート。 アセット制作ワークフローや最適化に関しての進行なども行っています。 ゲームと映像業界歴23年。 ワープ、ジェットスタジオ、ソニー・インタラクティブエンタテインメントを経て、3年前にソレイユに参加 4
この講演で得られるもの 独特な雰囲気の画面を構築するための工夫 背景コストを下げるための工夫 最適化のためのパフォーマンス計測手法 まだ情報が少ないHDRについての知見 5
作品紹介 6
作品紹介・ヴァルキリーエリュシオンとは 公式トレーラー https://youtu.be/QQtIcCDHIdw 7
作品紹介・ヴァルキリーエリュシオンとは ヴァルキリーエリュシオン © 2022 SQUARE ENIX CO., LTD. All Rights Reserved. 北欧神話をモチーフに、独自の世界観で描かれる「ヴァルキリー」シリーズの最新作です。 シリーズ初のアクションRPGとして、スクウェア・エニックス様より発売中です。 8
作品紹介・ヴァルキリーエリュシオンとは はるか昔、終末の定め「ラグナロク」により、破滅の危機に瀕した人間世界と、天界が舞台になります。 神界の戦いによって力を失った万物の主神オーディンは、世界の崩壊を食い止めるべく、救済の使徒ヴァルキリーを創造 し、命運をたくします。 地上に降ろされたヴァルキリーは、様々な未知の敵と戦いながら広い世界を浄化して行きます。 9
作品紹介・ヴァルキリーエリュシオンとは 地上にはいくつもの国があります。ヴァルキリーはそこで優れた魂を持った死後の人々と出会います。 彼らはエインフェリアと呼ばれる仲間として加わり、ヴァルキリーと共に戦います。 彼らが生前に残した想いの物語や様々な人間のドラマに触れるにつれ、ヴァルキリーの心情が変わっていく、また大きな秘密 が明らかになる、という壮大なストーリーになっています。 10
作品紹介・ヴァルキリーエリュシオンとは ヴァルキリーエリュシオン ウェブサイト © 2022 SQUARE ENIX CO., LTD. All Rights Reserved. 発売：スクウェア・エニックス 開発：ソレイユ株式会社 PC(Steam)、PS5, PS4 対応 UE4のバージョンは 4.27.1 11
開発コンセプト 12
開発コンセプト 写実的なPBRを下敷きにしつつ、さらに独特で個性 的な画作りを目指しました。 開発期間が限られていたため、工数を抑えつつも見 栄えが良い手法を模索しました。 最新コンソール対応のゲームということで60fpsを 目指しつつもグラフィックスのクオリティを保つこ とを目標にしました。 13
画作り・表現の方向性 コンセプトアート コンセプトアート 北欧の曇天をイメージした陰鬱な風景が主題です。 ヴァルキリープロファイルのオリジナルのコンセプトアートのタッチや、 西洋絵画の印象を参考に、舞台となる崩壊しつつある陰鬱な人間世界を表現しました。 そのためには、ライティングだけでなくポストプロセスでの画作りが重要なポイントになり ました。 14
画作り・表現 15
キャラクターを際立たせるアウトライン アウトラインは欧米のタイトル ではあまり採用されませんが、 今回は特にキャラクターや背景 を際立たせる要素として採用し ました。ヴァルキリーエリュシ オンの画作りの要になっている かと思います。 ヴァルキリーエリュシオンのア ウトラインはキャラクターのア ウトラインと背景のアウトライ ンの２種があり、それぞれ別個 に処理されています。 16
キャラクターを際立たせるアウトライン 背面法ではなく、ポストプロセスでアウトラインを生成しています。 キャラクターのアウトラインは４つの要素から算出したものを合成しています。 法線の勾配の大きさ キャラクター内の稜線になるような部分にアウトラインを生成。 背景との境界 キャラクターの外側、背景との境界に描画。キャラクターを背景から分離 して際立たせる。 深度差 深度の差が大きい部分にアウトラインを生成します。顎のラインやキャラどうし の重なりなど。 マテリアルIDの境界 マテリアルの境界にアウトラインを生成。 17
マテリアルIDの境界アウトライン マテリアルごとにアウト ラインIDを設定し、IDが違 うマテリアルの境界にアウ トラインを生成しています。 肌と衣服、鎧など、明確 に違う素材の間にアウトラ インを描きたい場合に使用 しています。 マテリアルID（模式図） 18
GBufferの情報だけでは足りない アウトラインの濃さやマテリアルのID、描画したくない部分のマスクなどの 情報が必用なため、GBufferを１枚追加しました。当然GBufferが増えること で、描画負荷やメモリの増大、Engine改造コストがありましたが、狙ったアウ トラインを出すためにはどうしても必用でした。マテリアルから拡張GBuffer に値を出力できるようにしています。 描画負荷の増大が心配でしたが、そこまで大きくはありませんでした。 アウトラインの強さをマテリアルでコントロールすることで、髪にはアウト ラインを描かない、ディザ抜き時はアウトラインを無くすなどの制御にも使用 しています。ディザが使用されているとアウトラインで真っ黒になってしまっ たりするのを防ぐ目的です。 19
背景のアウトライン 背景のアウトラインはシンプルに深度差があるところに描画。背 景オブジェクトが引き締まって見える効果があります。 深度差が大きい程アウトラインが濃くなりますが、サンプリング 範囲の最大深度で計算することで安定した品質になります。 また、Shading Model IDを取得して Two Sided Foliage（草）のアウトラインを薄くして います。 20
アウトラインにもフォグをかけたい Opaque描画の直後にポストプロセスパスを追加 UEのポストプロセスマテリアルは フォグの後にしか描画できません。 しかし、本作でのアウトラインは キャラクターや背景と一体になって 描画され、同じ様にフォグなどの効 果がかかって欲しい。そのため、UE のポストプロセスパスを追加して、 ライティングの直後にアウトライン を描画できるようにしました。 21
背景に色を重ねる独特な色彩 アートスタイルのために、すこ し特殊なポストプロセスマテリ アルでの色彩表現を行いました。 コンセプトアート 22
背景に色を重ねる独特な色彩 アートディレクターと話し 合いを重ね、「彩度を抑え た荒廃した世界だが、画面 内の暗部には様々な豊かな 色を感じる、絵画的な表 現」を目指すことにしまし た。 加工前 実機画像 23
背景に色を重ねる独特な色彩/影の着彩 色を豊かに見せるために、空間上に着彩を行いましたが、画面上の暗部にのみ色が乗るように工夫しました。 画面の平均輝度を求めて、 暗部のマスクを作成 影部分のみ着彩 3DノイズのRGBテクスチャを使用し て空間上に色を配置 24
背景に色を重ねる独特な色彩/「ブルー」と呼んだ着彩表現 キャラクターの下部と、背景の遠景に青いグラデーションを入れました。 これは正確なフォグとは別で、イラストレーションで、良く使われる効果を参考にしたものです。 このグラデーション コンセプトアート 25
「ブルー」と呼んだ着色表現 ディテールを整理/背景とキャラを分離 キャラ用mask(opacityチャンネルを流用) 背景はデプスとスクリーンスペースからマスクを。 キャラクターは、バウンディングのサイズをもとにグラデーションの マスクを。 opacityチャンネル経由でポストプロセスに渡して着彩しました。ソ ラリゼーションのような効果を狙って、少し元の明るさより明るくし たブルーの色を合成しています。 26
遠景をぼかしつつノイズを混ぜる 絵画的な表現を加えるために、距離が遠くなる ほど少しぼかしを入れつつ、ノイズを加えてい ます。 被写界深度ではフォーカスポイントを計算して いますが、簡略化のため距離だけで計算してい ます。ノイズは色ではなくコントラストに加え ています。人間の眼は色の変化より輝度の変化 に敏感なため、色にノイズを加えてもあまり認 識されないので、コントラストを変化させるの が効果的です。 27
ポストプロセス（アウトライン/着彩）の結果 加工前 ポストプロセスによる、アートスタイル表現の 結果です。本タイトルでは、このような調整を レベルと時間単位で数多く設定しました。 28
コストを抑えるための工夫・アセットとライティング 29
広大な背景/開発コストを抑えるための設計 30
広大な背景/開発コストを抑えるための設計 このタイトルでは、多くの非常に広いレベルを作成 する必要がありました。 • • • • ４つの文化様式の国 それぞれ、城や大きな都市 500メートルから1Km以上もの大きさ 天界やカットシーン専用レベルなども多く ソレイユでは今まで経験したことが無い物量。 限られた期間。大規模に海外アウトソースを行うこ とはコミュニケーションコストばかり大きくなる懸 念もあり、リスクが大きいと思われました。 そこでいくつかの事に注目して、アセット仕様と ワークフローを整理して、少数精鋭での量産を目指 しました。 31
広大な背景/開発コストを抑えるための設計/アセット制作 まず、背景の大半を占める建築物のモジュラーアセットに関して、以下の方針を決めました。 •（ZBrushなどの）ハイポリゴンへのスカルプトを行わない。 •ユニークなテクスチャを作らない。 ※Megascans とスマートマテリアルで、共有化して使う 改善 非常に多くの、巨大な廃墟のアセットに対する大きな工数 テクスチャの品質のバラつきや、テクスチャ数が増えてメモリが 増大する問題 ※もちろん、重要な一点物のアセット等はスカルプトを行う作り方をしました。 32
広大な背景/開発コストを抑えるための設計/ライティング また、ライティングに関しても以下の方針としました。 •Lightmassのライトビルトを行わない つまり、静的なライトマップを作らず、 ムーバブルなLightだけを使用する。 改善 マイルストーン毎にライトビルドとその調整に数日かかる問題 広大な地形をLightMapで覆うとメモリが莫大になる問題 ライトビルドが剥がれるとパフォーマンスが測れない問題 但し、ライティングを動的にしたことで、処理負荷の課題はとても大きくなりました。 33
Texutre2DArrayを使ったスマートマテリアル 多くの種類の質感を効率的に扱うために、Texutre2DArrayを使ったスマートマテリアルを作りました。 • 多レイヤー/低負荷 • 自動で汚しやダメージを • 自動でバリエーションも ※（例）多様な質感に対し、マテリアルはたった１個 34
Texutre2DArray？ 最大２５６枚までのテクスチャを1アセットにまとめる事ができる仕組み UV + Index（整数値）でレイヤーを選択 レイヤー的な表現可能だが、テクスチャサンプル数は増えない 負荷は１レイヤーと同等 （↑例６４レイヤー）
Texutre2DArrayを使ったスマートマテリアル マスクテクスチャによって、汚しやダメージ 表現も自動的に入ります。 また、配置情報によってUVがずらされるの で、バリエーションが生まれます 頂点カラーやテクスチャでブレンド ブレンドは２値だがノイズを使って疑似的に滑らかに 見せます 36
背景アセットの結果 37
Texutre2DArray メリットとデメリット 便利だが、良いことばかりではなかったのでメリットとデメリットをまとめます。 メリット： •リピートの多用によってテクスチャ解像度を低めに抑えられる •少ないテクスチャ参照での疑似レイヤー表現が可能 デメリット： •テクスチャ管理が煩雑になりがち •テクスチャのセットの一部だけ違うものが増やされたりするととても非効率 •１セットのテクスチャのメモリ使用量が大きい UE4.27ではまだTexture2DArrayのテクスチャストリーミングが実装されていなかったため、UE5を参考に 実装しました。ストリーミングされないと大量のT2DAテクスチャがメモリに常駐してしまい、コンソール機 のメモリに乗り切れないという問題がありました。また、当初はUEの不具合でT2DAを読み込む際のメモリ が開放されないという問題もありました。 上記のことはプロジェクトの後半の時期に大きな問題になりました。 なので、エンジンを無改造の場合、このワークフローはお勧めしません。 しかし、今後はVirtual TextureのUDIMの機能を使って、同様のワークフローが行えるかもしれないと考え ています。 ※UE5の機能をUE4に移植する際はEpicとの追加契約が必用になる場合があるので必ず連絡を 38
全てのLightを動的に このタイトルでは、多くの時間と天候のためのライティングのバリエーションが必要でした。 ムーバブルライトだけでライティングすることで、ライトビルドのための調整の工数削減に加えて、 メモリ削減への利点も非常に大きいと考えました。 ただし、処理負荷は非常に大きくなるので、工夫が必要になりました。 39
ライティングの構成 distance field distance field AO 直射光 result • • • • • Sky Light Sky Atmosphereを使用した、動的なライティング MarketplaceアセットのUItra Dynamic Skyをカスタマイズ、DataTableとアーティストが配置するボリュームによって制御。 Light buildしないので、Distance field ambient occlusionによって、屋内が暗くなる。 なので、完全に隠蔽されるのではなく、室内でも少しSky Lightが透過している状態。 室内を完全に暗くしたり、逆に明るくしたりする場合には前述のアーティストの配置するボリュームで制御。 Point Light等、配置するライトはすごく少ない。廃墟が多いので成り立った。 40
マテリアルAOを追加する機能拡張 動的なLightingでもMatrialAOが反映で きるように、機能拡張しました。 SSAOのみ SSAO+MaterialAO 機能拡張 前述のアウトライン表現用の拡張 GBufferを流用。SSAOのパスで MaterialAOもブレンドするように。 41
屋内モード・動的シャドウの負荷を下げる工夫 すべてのシャドウを動的にしたことで、屋内は常に建物のシャドウの中に居ることになります。そうでないと屋内が屋外 のように明るくなってしまいます。 とはいえ、城の中のステージでは常に暗い状態で良く、そのために城全体のシャドウを生成しつづける事は効率が良くあ りません。 この問題に対応するために、エンジンを改造して「太陽光は存在するが常に影の中にある状態」にする、「屋内モード」 を実装しました。具体的にはDirectional LightのIntensityを0としてライティング計算を行うが、フォグやSkyLight、天 球などは設定されたIntensityで計算されるモードです。 太陽が雲に隠れた状態を再現するといえばわかりやすいかもしれません。 Sky Atmosphere（改造） シャドウ負荷減 屋内モード 太陽はOFFだが、 SkyLightは明るく 太陽光が直接届かないシーンでは屋内モードに切り替えることで、Directional Lightによる影生成をキャンセルすること ができるようになり、描画負荷が大きく軽減されました。 屋内だけでなく、鬱蒼とした森の中や大きな建物の影といったシーンにも使用できます。 42
動的なライティングのメリット/デメリット このようにライティングをすべMovableにした事によって、 以下のメリットとデメリットがありました。 メリット： • メモリ使用量の大幅な軽減 • 調整の工数の大幅な削減 • ロード時間の短縮 デメリット： • 間接光が静的に表現できないため、表現の幅が限られたと思う • 配置するライトの数や重なりを相当減らす必要がある • 影を動的に作る必要があり、描画負荷が高い ※特に影がすべて動的になるのは描画負荷に直結するので、影の設定、影を落とすオブジェクト については注意深く設定が必要。 43
ライティングのまとめ このゲームでは物理的に正しいライティングを無視した手法が多く使われています。 ある意味邪道と言えるライティングも多く採用しています。 あくまでもこのゲームの雰囲気、画作りに添って決めた方針なので、一般的にどんなゲームにでも使える手法 では無いと思います。特に影の作り方や暗いところでのライティングなど。あくまでも主要なライティングが 曇天ベースであるからこそ通用したやり方だと考えています。 曇天ベースであることでフォグも濃いめにすることができ、遠方の影がを誤魔化しやすかったのが助かりまし た。 44
負荷・計測、パフォーマンス調整 45
4K 60fpsの実現 5 4 美しいグラフィックスを表現したいのは当然としても、やはりアクションRPGということで、PC、 PS5では60fpsを目指したかった。しかし、PS5となると当然4K対応も視野に入れる必要があります。 UE4で4K 60fpsというのは正直かなりの描画最適化と作り込みが必要になります。 しかもビジュアル重視ということでGBufferを拡張したり、ポストプロセスを豪華にしたりしてい たので、この状態で4K 60fpsは非常に厳しい。半ばあきらめかけていました。 そんなタイミングでUE5のプレビューが公開されました。UE5ではTemporal Super Resolutionと いう超解像技術が実装されていることを知り、飛びつきました。 結果は良好で、1080Pから2160Pへアップスケーリングしてもネイティブ4Kに比べてそれほど遜 色のない描画ができました。この機能のおかげでほぼ4K 60fpsが実現できました。 ※UE5の機能をUE4に移植する際はEpicとの追加契約が必用になる場合があるので必ず連絡を 46
処理負荷計測/フロー QA（専任） アーティスト その他 主にアートアセットや描画に関わる処理負荷 は、テストプレイのログをTAに集約しました。 処理負荷のロ グ 処理負荷ログ専任のQAや、アーティストの当 番がログ作成。TAレベルである程度切り分け を行って、プログラマや、アーティストに対 策を相談しました。 CsvProfileとPlay動画 https://docs.unrealengine.com/4.27/ja/TestingAndOptimization/PerformanceAndProfiling/CSVProfiler/ 47
処理負荷計測/ツール CsvProfileと動画を共有。しかしデータが、膨大すぎて可読性が低いので可視化Toolを作成しました。 可視化Tool CSVProfilerをゲームの デバッグUIから実行可能にした。 コマンド //profile csvの開始 r.GPUStatsEnabled 1 r.GPUCsvStatsEnabled 1 CsvProfile Start //profile csvの停止 CsvProfile Stop 約300項目もの毎フレームの処理時間や統計のデータ 48
CsvProfile可視化Tool/使い方 • 大きく見渡して、負荷の大きい場所と出来事を確認 • 動画をシーク再生しながら、ログを分析。 動画 • 更にグラフから、負荷の大きい項目を見つける • GPU、CPU、メモリーの各積み重ねグラフ グラフ • 具体的な負荷の原因を洗い出し、対策へ。 • アセット数や、他項目との相関などを確認 • Light、アクター、Tickの数、相関係数も。 ヒートマップ 49
CsvProfile可視化Tool/GPU処理負荷の対策例 •GPU処理負荷が特に大きかったのは Cast Shadowに関することだった。 解決 •以下のような対策を行った • 配置するlightの整理/Point Lightのcast shadowの 禁止等 • Directional Lightのカスケード枚数や解像度の削 減 •屋内に入るとDirectional LightをOFFにする仕組み •背景アセットの頂点の削減 •ランドスケープのcast shadowをなくす •その他 PS4処理負荷対策前 PS4処理負荷対策後 •Foliageの距離設定 •Distance FieldAOの設定（PS4ではSSAOに） •Volumetric Cloudsは不使用にした またPS5では、TSRの処理負荷がとて も大きかったが、これによって全体 解像度をUP出来ているので良いと考 えた。 また解像度高いのでポストプロセス 処理も大きくなるので注意。 PS5処理負荷対策前
CsvProfile可視化Tool/メモリ負荷の対策例 •PS4ではメモリの不足が大きな課題 だった。 •あるステージでは、いつも中ほどでメモリが溢れ てしまう問題が・・ •当然アセット削減もしたが、以下の対策が必要 だった・・ •敵キャラクター他配置アセットが、ステージの最 初に呼ばれたまま、メモリから捨てられていな かった。対策を行うと、メモリが低く安定した。 PS4メモリ対策前 PS4メモリ対策後 5.5GB 3.8GB ※たくさんloadしても、捨てているのでメモリ増えにくい
CsvProfileを使った処理負荷計測/珍しい事例 ログと動画が無かったら発見困難だったかも? ■サブサーフェイス用バッファのGPU負荷 分析 • シネマティックの、あるカットのみ処理負荷が大きいと発見 • カットはじめにキャラクターの顔アップになると重い？ • GPU処理/SSSの処理が大きい？プログラマに報告。 対策 • プログラマが、サブサーフェイスのバッファ処理が重いと発見 • サブサーフェス用のバッファをハーフサイズに ■パーティクルのメモリ負荷 分析 • あるギミック攻略後のカットシーン中、メモリが600MBも増大 • 当初アセットのロードを疑うが、アクター数やFileIOには変化無し • 動画上のパーティクルの発生と、メモリのログに相関がありそうと推測 対策 • アーティストに一時的にパーティクル削除してもらうと改善した • GPUパーティクルが異常に多かった場合、メモリが増えるとわかったので削減を要望 52
CsvProfile可視化Tool/実装方法 UI実装はPythonの「DearPyGui」を使用。 https://github.com/hoffstadt/DearPyGui ※「dear imgui」で構築されたライブラリ。 描画軽く、習得も容易なのでお勧め。 グラフ上でバーを動かすとその時点へ動画がシークされる仕組み の実装に苦労 ↑動画キャプチャが手動だったので、同期情報がなかったので・・ 動画にはCsvProfileのフレーム数が表示されてたので、これを手 掛かりに同期する仕組みで解決。 自動のOCRか、読み取れない場合は手動でフレーム数を打ち込む ことに。 ※openCVとpytesseractを使用。 再生位置を同期 データ量が大きいこともあり、今後はwebベースのツールに切り替 えていきたい。 53
CsvProfileを使った処理負荷計測 メリット/デメリット CsvProfileを使って、QAとアーティスト、TAのレベルで処理負荷の分析を行った。 メリット： • GPU/レンダースレッドの負荷に対してはかなり有効 • 主にアートアセットに由来。プライオリティを明確にして対策することができた。 • プログラマ以外でも、自主的に簡単な分析と対策まではできた • TestBuildでもログが出力可能、データとツールを簡単に共有できるようにした • （例）エフェクトアーティストがトランスルーセントの負荷ログを見てゲーム全体の処理負荷調整 デメリット： • ゲームスレッドの負荷に対しては、発見はできるが、分析までは難しいかも • 物理や、様々な処理の実装内容が多岐にわたるため • 早めにプログラマに負荷の状況を伝えて分析してもらうべき 54
HDR - High Dynamic Range 55
HDRへの取り組み ヴァルキリー・エリュシオンはソレイユでも初めてのHDR対応タイトルになりま した。対応を始める前は甘く見ていましたが思ったより大変でした。 HDR （大変） 56
HDRへの取り組み UEのHDRの現状について UE4.27の段階ではHDR描画ををエディタで確認することができません。 ビルドを作成・実行し、コンソールコマンドなどでHDRに切り替える必要があります。UE側の HDR対応も十分ではありませんでした。 特にHDR時のUI描画に関しては色々問題が合ったのですが、その話は後でまとめてします。 HDRでの主な問題としては次のようなものがありました。 57
HDRへの取り組み/HDRでの主な問題 正解がわからない まだまだ事例も少なく、情報も少ないため、表示されているものが正しいかどうかの判断基準に 乏しかった。ディスプレイによってもかなり違うのでどこにあわせて良いかの判断も難しかった。 特にこのプロジェクトでは強い光が当たるシーンも少なく、実写的な画作りを重視していないた めHDRの効果を実感しにくかったかもしれません。 とはいえ、実際にHDRで出力してみると色域の広さや色の美しさを感じることが出来ました。 実際のHDRを見比べるために安物からそれなりの家庭用テレビ、そこそこの高級ディスプレイま で多数のディスプレイを購入して比較しました。 作業はそれなりのHDRディスプレイで行いますが、実際にユーザーが目にするのは民生用のテレ ビになると考えたので最終的な確認は必ずテレビでも行うようにしました。 58
HDRへの取り組み/HDRでの主な問題 フィルミックトーンマップが効かない HDR時はフィルミックトーンマップが機能しません。フィルミックトーンマップで調整しすぎる とHDR時にSDRと大きく違う見た目になってしまいます。とくに暗部の輝度を持ち上げたりして いた場合はHDR時に暗いままになるので注意が必要です。なるべくフィルミックトーンマップで の調整はしないようにしてもらいました。カラーグレーディングなどは反映されるので、そちら での調整は可にしました。 59
HDRへの取り組み/HDRでの主な問題 明るさの調整ができない UEでの設定では最大輝度を1000nitにするか2000nitにするかの選択くらいしかないのですが、ディスプレ イによってHDR時の輝度は大きく違います。またHDRディスプレイでもSDR時は明るく表示する傾向があり、 HDRにすると暗く見えることが多かった。HDRでの明るさ調整は追加のトーンマップなど色々な方法を試し たのですがなかなかしっくりくるものが無く、最終的にはシンプルにリニア時の出力に単純に倍数を掛けるこ とで落ち着きました。リニア出力を2倍3倍にしたものにHDRスペースへの変換をかけて出力するという手法 が無難に思えましたがあまり正しくはないのかもしれません。 そのため、このゲームの輝度調整画面では、ゲーム画面を表示した状態でユーザーには明るさ調整だけをし てもらうという形式で、よくある特定の画像を表示してギリギリ見える明るさを設定してもらうといった形式 にはしませんでした。 60
HDR時のエフェクトの問題 次はエフェクトの問題です。 SDR時でもHDR時でもエフェクトに限らずゲーム画面はHDR空間に描画が行われます。 （厳密には輝度の範囲はHDRで色空間がHDRとは限らないですが） SDR時はトーンマッピングにより、RGBが0-1.0の範囲にマッピングされて出力されるのですが、HDRでは1.0 を超える範囲まで出力されます。SDR時はEye Adaptaionによる輝度範囲の最適化により、一定以上明るい部 分が1.0になるように調整されます。それ以上に明るい部分は1.0でクリップされてしまいます。 HDRでも極端に明るい部分はクリップされたりはしますが、SDRに比べるとかなり高い輝度までクリップされ ずに表示されます。 通常のシーンではそれほど問題にならないのですが、エフェクトでは問題になることがありました。 61
HDR時のエフェクトの問題 エフェクトはEmissiveな半透明なポリゴンを多層に重ねる事が多く、特定の色を多層に重ねた部 分が白くなるような表現がよく使われます。青いレーザーの中心部分が白くなるといった表現は 中心部分には青が何層にも重なった結果白くなっていたりします。 そのような作り方はHDRでうまく表現できないことがあります。 この図は模式図ですが、SDRでは高輝度な 紫がクリップされて白くなる部分が、HDR では高輝度まで紫のままでなかなか白に飽 和してくれません。 輝度 エフェクトアーティストが想定したものに ならないという指摘が多くありました。 HDR SDR 62
HDR時のエフェクトの問題 そもそも、HDRではエフェクトが眩しくなりがちです。最初は「キラキラして綺麗」くらいに思ってましたが、 場合によっては眼が疲れるしアクションの邪魔になりかねません。 輝度が高いエフェクトが多数でるとEye Adaptationに影響を与えて相対的にシーン全体が暗くなることもあ るかもしれません。 エフェクトの輝度や色はこまめにHDRで確認して調整する必要があります。 63
UIにおける問題点・Background Blur 条件を満たすまで読むことができないテキストというギミックがあるのですが HDR SDR 読めてはいけない取得前のフレーバーテキストが… HDRだとはっきり読めてしまった。 64
UIにおける問題点・Background Blur テキストをボカすために、Background Blur Widgetを使用しているが、UE4.27ではHDR時にそもそも Background Blurが描画されないという問題があります。 この点はUDNに対応方法が掲載されているので、それを参考に修正することができた。 Backgound Blurに関するUDNのリンク しかし、修正してもHDR時のBackground BlurはUIの最背面にしか描画できず、テキストを描画してからボカ すことが出来なかった。 HDRでは SDRでは 1. 背景画像 1. 背景画像 2. Background Blur 2. Background Blur 3. Background Blur 3. テキスト枠 4. テキスト枠 4. テキスト 5. テキスト 5. Background Blur の順に描画されてし の順に描画してテキスト まう をボカしている。 65
UIにおける問題点・Background Blur 同様の問題はメニューが多層に重なるUI画面でも発生します。 スキル画面の背景をぼかすためにBackground Blurを挟んでいるが、HDRでは再背面に描画されるので、下絵 が完全に透けている。文字のフレアのかかりかたも違う。メニューの上にさらにメニューを重ねるような表現 はHDRでは避けたほうが安全。 66
HDR時のUIの問題 ModulateやAddtiveはHDRではTranslucentとして描画される SDR（模式図） HDR（模式図） 見た目が変わってしまう 67
HDR時のUIの問題 なぜこのような問題が起きるのかというと、UE4のHDR時のUI描画の仕組みがSDR時と違うことにあります。 SDR時はUI Widgetは背面から前面に向かってひとつずつ順番に描画されていきます。 HDR時はUI Widgetは一旦内部バッファに描画し、その内部バッファをまとめて画面に描画します。 これをUE内部ではUI Composite Modeと呼んでいます。SDRはr.HDR.UI.CompositeMode=0、HDR時は r.HDR.UI.CompositeMode=1で描画されます。 なぜこのような事をしているかというと、UIが描画されるターゲットがHDRの場合に半透明合成が正しくで きないことや、HDR時のUIの明るさを調整できるようにする目的だと思われます。 しかし、UE4.27の時点ではCompositeMode=1のときにBackgourndBlurを無視してしまうという問題があ りました。またHDR時のUIのカラー変換にもミスがあり、正しい色が出ていません。こちらもUDNで修正方 法が挙げられていますので、参考にすると良いかと思います。 UIカラーに関するUDNリンク 68
HDR時のUIの問題 CompositeMode=1の場合には、次のような制約が生まれます。 • 半透明合成がTranslucent、シンプルなアルファ合成に限られる。ModulateやAddtiveはTranslucentとし て描画されてしまう。 • BackgroundBlurが最背面にしか描画されない。UIの間に挟むことができない。 この事に気づいたのがUIの殆どが完成していた時期でした。今更UIの多くを作り直すというのは厳しかったの で、なんとかHDRでもCompositeModeを使用せずに描画できないかと足掻いてみました。 結果的にはUI Widgetの描画のたびにHDR空間へ色空間を変換することで正しい色で描画されるようにはでき たのですが、HDR空間への半透明合成を完全実装することはできませんでした。特にHDR空間でAddtiveを使 用すると異常に明るい輝度になってしまいますし、Modulateの結果も大きく違います。そのためHDR時のUI の明るさにばらつきが出る結果になってしまいました。UIアーティストにAddtiveやModulateをなるべく使 わないようにしてもらうなど、可能な限り調整をしてもらいました。 69
HDRへの取り組み/経験からのアドバイス HDRでの問題解決 プロジェクト後半になってからHDR対応を始めたこともあって、様々な問題が浮上し、苦労する ことになりました。ここでHDR対応の経験からのアドバイスです。 プロジェクト初期からこまめにHDRで確認しましょう！ 特にUIアーティストやエフェクトアーティストには常にHDRで確認できる環境を用意する。 大量のエフェクトやUIを作ってしまってからHDR対応しようとすると多大な修正コストが必要に なる可能性があるので注意してください。 エフェクトのHDR確認用ステージ 70
まとめ 71
エンジン改造のまとめ このプロジェクトでの主なエンジン改造をまとめてみました。 エンジンの改造は保守性の低下やアップデート時のマージコストやそれによる不具合の懸念などから嫌う人も 多いですが、実際にやりたい表現や機能のためにはなかなか避けて通れないと考えています。 • TSRの移植 • Texture2DArrayのストリーミング 上記2つはUE5から移植しましたが、UE4プロジェクトでUE5の機能を移植して使用する場合は別途契約が必 用な場合があるので、必ずエピックゲームズに確認しましょう。 • • • • • • HDRの明るさ調整 HDR UIのCompositeを使用しないモード GBufferの拡張 ポストプロセスパスの増設 フォグの拡張 ライティングの屋内モード 他にも細かい改造はたくさんあります。 72
まとめ 独特な画作りのために、ポストプロセスによる加工を中心に構築を行った クオリティを保ちながらのコスト削減のためにTexture2DArrayを活用 リソース削減とコスト削減のために静的ライトマップを排除 動的シャドウでパフォーマンスが出るように工夫 ヒートマップ式のパフォーマンスチェックツールで負荷を計測して最適化 HDR対応はプロジェクトが進行してから行うと大変な思いをする。特にUIとエフェクトは注意 エンジンの改造は必要だが計画的に 73
ご静聴ありがとうございました https://soleilgamestudios.com 74
アンケートへのご協力をよろしくお願いします ＜講演に関するアンケート（Game Day）＞ https://forms.gle/B3FfR3rSEcpDYXFH8 75