ヘブンバーンズレッドのレンダリングパイプライン刷新

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ©WFS Developed
by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key ヘブンバーンズレッドのレンダリングパイプライン刷新株式会社 WFS 技術室野⼝顕弘

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ⽬次 •
アプローチ • シェーダー移植 • ライティング ◦ ベイクドライティング ◦ リフレクションプローブ ◦ Physically Based Rendering ◦ シャドウ • 描画パス ◦ 半透明とキャラクター ◦ ポストプロセス ◦ 複数カメラ • アセットマイグレーション • Quality Assurance 2

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ⾃⼰紹介野⼝顕弘（Akihiro
Noguchi）技術室 WFS シニアリードエンジニア 3

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ヘブンバーンズレッドとは •
「ヘブンバーンズレッド」は、2022年にリリースされたライブサービス型ゲーム • 対応機種：iOS/Android/Windows 4

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ヘブンバーンズレッドとは 5

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ヘブンバーンズレッドとは 6

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • Built-in
Render Pipeline (Built-in) ◦ 従来のパイプライン ◦ イベントコールバックなどの API でグラフィックス機能を拡張動機 7

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • Built-in
Render Pipeline (Built-in) ◦ 従来のパイプライン ◦ イベントコールバックなどの API でグラフィックス機能を拡張 • Universal Render Pipeline (URP) ◦ 新しいパイプライン ◦ Scriptable Render Pipeline ベース動機 8

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • URP
の機能が使いたい ◦ SRP Batcher ◦ Single Pass Forward Rendering 動機 9

の機能が使いたい ◦ SRP Batcher ◦ Single Pass Forward Rendering 動機 10

の機能が使いたい ◦ SRP Batcher ◦ Single Pass Forward Rendering • URP プロジェクト間の技術共有動機 11

の機能が使いたい ◦ SRP Batcher ◦ Single Pass Forward Rendering • URP プロジェクト間の技術共有 • 柔軟にカスタマイズできる描画パイプライン動機 12

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key 13 トライした結果、頓挫

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key 頓挫の理由 •
URP に移⾏すると⾒た⽬が変化する ◦ 運営チームの監修が必要 14

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key 頓挫の理由 •
URP に移⾏すると⾒た⽬が変化する ◦ 運営チームの監修が必要 • 全コンテンツの監修と修正をするコストが⾼すぎる ◦ 運営が⽌まってしまう 15

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ⾒た⽬を変えなければ監修は不要 16

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key アセットを調整して⾒た⽬を合わせる ↓
プログラムを調整して⾒た⽬を合わせる 17

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key 移⾏結果 Built-in URP 18

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • ライブサービス運営を⽌めない
⽬標まとめ 19

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ⽬標まとめ •
ライブサービス運営を⽌めない • 全く⾒た⽬を変えない 20

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ⽬標まとめ •
ライブサービス運営を⽌めない • 全く⾒た⽬を変えない • Unity 本体のバージョンアップも同時に実施 ◦ 2020.3.15f2 ➡ 2022.3.32f1 21

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • 2
名 • レンダリング担当1名（私） • アセットパイプライン、UI、描画チェックなど担当1名作業者 22

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • リリースまで9ヶ⽉
期間 23

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • リリースまで9ヶ⽉
• 運営チームのアウトプットとの並⾛ ◦ ⻑引くと作業量が増える期間 24

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key プロジェクト構成バージョン管理
Git + LFS カラースペースガンマレンダリングパスフォワードポストプロセス Post Processing Stack v2 (PPSv2) 25

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key 作業前の状況 26

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key 移植対象シェーダーのリストアップ •
難易度の⾼い問題を先に解決し中盤以降は単純な物量勝負に持ち込む • シェーダーのリストアップ、内容の精査 27

シェーダーの統合、プロパティのデフォルト値の変更を検討 ◦ 将来的なアセット制作の効率化も⾏う 28

シェーダーは92種類 • 他の作業と並⾏で移植が完了するまで7ヶ⽉ 29

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key シェーダーの種類 •
⼿書きシェーダー ◦ プログラマー向け ◦ ShaderLab + Cg で記述 30

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key シェーダーの種類 •
⼿書きシェーダー ◦ プログラマー向け ◦ ShaderLab + Cg で記述 • Amplify Shader Editor (ASE) シェーダー ◦ アーティスト向け ◦ ノードベースのシェーダーエディター Amplify Shader Editor 31

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key URP では互換性が無いコードが多く、ASE
に⼿動移植⼿書きシェーダーの移植 Code ASE 32

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ⼿書きシェーダーの移植 •
シェーダーテンプレートの仕組みを利⽤することで移植作業を集約 • アーティストがシェーダー開発を⾃律的に⾏えるようになる Code ASE 33

URP 向けテンプレートをベースに本作特有のシェーダー再現機能を実装 ◦ たとえばカスタム仕様のフォグ Code ASE 34

URP 向けテンプレートをベースに本作特有のシェーダー再現機能を実装 ◦ たとえばカスタム仕様のフォグ • アーティストが扱いやすいようにカスタムノードの利⽤は最⼩限 Code ASE 35

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ⼿書きシェーダーの移植プロパティ順序を再現
36 Built-in URP

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ASE シェーダーの移植
• テンプレートで描画差分を吸収しているため簡単 • マスターノードの再接続とテンプレート設定の⼿動移植で対応 Built-in URP 37

• テンプレート設定の調査 ◦ 各種設定の URP テンプレートでの再現⽅法を事前に確⽴ 38

• テンプレート設定の調査 ◦ 各種設定の URP テンプレートでの再現⽅法を事前に確⽴ • 考慮漏れがあり、後々描画差異が発⽣して⼿戻りが発⽣した 39

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key その法線、正規化されていますか？ • Built-in の ASE テンプレートはフラグメントの法線が正規化されていなかった • URP のテンプレートでは正規化されていた • テンプレート挙動の理解が重要 40

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • 作業の物量が多く、事前調査を⼊念にする価値が⾮常に⾼い
◦ 調査不⾜による⼿戻りが多かった • ASE のテンプレート修正に共通の再現処理を集約できたシェーダー移植まとめ 41

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • まずはゲーム全体で⼀番使われる汎⽤シェーダーを再現してテスト
• ここまで約3週間 • 移植出来るのではないかという希望が⾒えてきた汎⽤シェーダーの移植 *この時点ではポスプロ無し 42

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ベイクドライティング 43

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ベイクドライティング •
間接光はライトマップ • 静的オブジェクトの影はシャドウマスク No Baked GI With Baked GI Lightmap Shadowmask * ポスプロ無し 44

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • 既存のシーンは完全に同じ⾒た⽬を保つ
• 新規制作するシーンは以前と同じ⾒た⽬を再現ベイクドライティング No Baked GI With Baked GI Lightmap Shadowmask * ポスプロ無し 45

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ライティングをベイクしなおした結果全く同じ結果になれば問題ない
46

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ライトマップのライト減衰 •
Unity 提供の C# API を⽤いて減衰式の設定変更を⾏う • ドキュメントを参考に URP を改造 47

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • ライトマップ再ベイク時に暗くなった Meta パス Before After 48

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Meta パス • 背景シェーダーは Meta パスが未定義、フォールバック挙動に変化 ◦ 前環境：⽩⾊を出⼒ ◦ 現環境：sRGB ミッドグレーを出⼒ 49 Before After

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Meta パス • 背景シェーダーは Meta パスが未定義、フォールバック挙動に変化 ◦ 前環境：⽩⾊を出⼒ ◦ 現環境：sRGB ミッドグレーを出⼒ • URP 版シェーダーの Meta パスを実装し、⽩⾊を出⼒ 50 Before After

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Meta パス • 明るさがおおよそ⼀致 • しかし所々⾒た⽬が違う箇所がある Before After 51

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Meta パス • 明るさがおおよそ⼀致 • しかしちらほら⾒た⽬が違う箇所がある • Unity はバージョンによってライトマッパーの挙動が変わる 52 Before After

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key データ問題の発⾒ • ベイクしたあとにシーンのライト設定が変更されたシーンを発⾒ • ベイクし直すと⾒た⽬が変わってしまう再ベイク前再ベイク後 53

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ベイク結果を合わせる（Cast Shadow） • Cast Shadow がオフになっているオブジェクトの影響が変化 ◦ 設定がライトマップに影響を及ぼさなくなった • 仕様かバグか、判断がつかない 54 再ベイク前再ベイク後

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ライトマップの状況整理 •
新規シーン ◦ ⾒た⽬をほぼ再現できるため問題はない 55

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ライトマップの状況整理 •
新規シーン ◦ ⾒た⽬をほぼ再現できるため問題はない • 既存シーン ◦ ベイクしなおすと⾒た⽬が変わる ◦ 監修が必要になるため、ベイクしなおすことが出来ない 56

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key 古いベイク結果を再利⽤すれば全く同じ結果になる
57

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ライトマップ UV
の問題 • Unity の⾃動ライトマップ UV 展開機能を利⽤していたが、バージョンアップにより展開結果が変化 • 外部で展開したライトマップ UV と Unity の⾃動ライトマップ UV 展開が混在 58

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • 旧エディターでインポートした結果を持ってくる
古いバージョンの UV を維持する 59

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • 旧エディターでインポートした結果を持ってくる
• インポート結果の頂点数も変化するため、メッシュ情報全てを持ってくる必要がある ◦ 頂点座標 ◦ UV ◦ カラー ◦ etc. 古いバージョンの UV を維持する 60

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key メッシュの再現 FBX
OnPostprocessModel バイナリ出⼒旧エディター 61

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key メッシュの再現 FBX
OnPostprocessModel バイナリ出⼒ FBX OnPostprocessModel Unity 新エディター 62 旧エディター

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key 再現されたライトマップ UV
63

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key メッシュの再現（例外） FBX
OnPostprocessModel バイナリ出⼒ FBX OnPostprocessModel Unity 新エディター 64 旧エディター • リリース済み背景データの編集は禁⽌

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • リリース済み背景データの編集は禁⽌
• しかし未リリース FBX は変更されることがあるメッシュの再現（例外） FBX OnPostprocessModel バイナリ出⼒ FBX’ OnPostprocessModel 65 新エディター旧エディター変更！

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • FBX
のチェックサムに変化があり、ライトマップ UV が未展開の場合はエラーとする • ライトマップ UV を Unity 外で制作してもらうように促すメッシュの再現（例外） FBX OnPostprocessModel バイナリ出⼒ FBX’ OnPostprocessModel 66 新エディター旧エディターチェックサム不⼀致 → エラー変更！

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ライトマップまとめ •
Meta パスは明⽰的に実装したほうが安全 67

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ライトマップまとめ •
Meta パスは明⽰的に実装したほうが安全 • ライトマップ UV を再現することで、ベイクしたライティングを維持 o Unity のバージョンが変わるとベイク結果は別物になる 68

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key リフレクションプローブ 69

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • リフレクションプローブを利⽤している
• ⼀部の室内シーンではボックスプロジェクションを採⽤しているリフレクションプローブ 70

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key リフレクションプローブ • ボックスプロジェクション設定の挙動が違う Built-in URP 71

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key リフレクションプローブ • ボックスプロジェクション設定の挙動が違う • リフレクションプローブの AABB 設定の反映⽅法が変化 72 Built-in URP

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ボックスプロジェクション AABB
Reﬂection Probe AABB Object AABB 73

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ボックスプロジェクション AABB（URP）
Reﬂection Probe AABB = Box Projection AABB Object AABB プローブに設定した AABB がそのまま採⽤ 74

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ボックスプロジェクション AABB（Built-in）
Reﬂection Probe AABB Object AABB Box Projection AABB プローブの AABB と、オブジェクト⾃⾝の描画 AABB を内包する最⼩の AABB 75

Reﬂection Probe AABB Object 2 AABB Object 1 AABB 76

Reﬂection Probe AABB Object 2 AABB Object 1 AABB Box Projection AABB 1 Box Projection AABB 2 77

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key リフレクションプローブ •
データ修正で対応が出来ない • シェーダーで対応する 78

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key リフレクションプローブ •
シェーダーで今描画しているオブジェクトの描画バウンドを取得 • リフレクションプローブの AABB と描画バウンドの OR を取るようにシェーダーで調整 float4 legacyBoxMin = float4(min(unity_SpecCube0_BoxMin.xyz, unity_RendererBounds_Min.xyz), unity_SpecCube0_BoxMin.w); float4 legacyBoxMax = float4(max(unity_SpecCube0_BoxMax.xyz, unity_RendererBounds_Max.xyz), unity_SpecCube0_BoxMax.w); reflectVector0 = BoxProjectedCubemapDirection(reflectVector, positionWS, unity_SpecCube0_ProbePosition, legacyBoxMin, legacyBoxMax); 79

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key リフレクションプローブ Built-in URP (Shader Fix) 80

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key リフレクションプローブまとめ •
ボックスプロジェクションを使っている場合は挙動が違うので注意 • シェーダー側で対応が可能 81

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Physically Based
Rendering 82

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key PBR 描画
⼀部のオブジェクトは PBR で描画されていた 83 *左の遠くに⾒える氷が PBR

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key PBR 描画差異 Built-in URP 84

• Built-in ではプロジェクト設定により実装が変化 85

• Built-in ではプロジェクト設定により実装が変化 • URP では PBR 実装が固定 86

• Built-in ではプロジェクト設定により実装が変化 • URP では PBR 実装が固定 • アーティスト確認環境での設定をリファレンスとする 87

• Built-in ではプロジェクト設定により実装が変化 • URP では PBR 実装が固定 • アーティスト確認環境での設定をリファレンスとする • Standard Shader Quality = High 88

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Diﬀuse Built-in URP 89

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Diffuse Built-in (Burley Diffuse) URP (Lambert Diffuse) • シェーダーを⽐較して実装⽅法の確認 • Built-in では Burley Diffuse が採⽤ • URP では Lambert が採⽤ • Built-in の実装に寄せる 90

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Diffuse Built-in (Burley Diffuse) URP (Burley Diffuse) 91

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Diffuse • Built-in ではカラースペースでライティング処理が変わる • URP はリニアで処理 • 例えば Built-in では⾮⾦属の F0の値の分岐（Linear: 0.04、Gamma: 0.22） • カラースペースの分岐を URP に移植する Built-in (Burley Diffuse) URP (Burley Diffuse) 92

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Diffuse Built-in (Burley Diffuse) URP (Burley Diffuse + Gamma Fix) 93

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Specular 94 Built-in URP (Gamma Fix)

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Specular 95 スペキュラハイライトの⼤きさが違う Built-in URP (Gamma Fix)

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Specular *Renaldas Zioma, “Optimizing PBR for Mobile”, SIGGRAPH 2015 Built-in URP • Built-in: GGX NDF + Smith Joint GGX • URP: 独⾃の最適化された式* • Built-in の実装に寄せる 96

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Specular Built-in URP (Final) 97

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key PBR 描画調整後 Built-in URP 98

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ポイントライト URP ではライトの減衰式が逆⼆乗に変更されている Built-in URP 99

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ポイントライト • Frame Debugger とシェーダーを確認、LUT で減衰値を求めている事が判明 Built-in URP Frame Debugger 100

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ポイントライト • Frame Debugger とシェーダーを確認、LUT で減衰値を求めている事が判明 • Built-in と同⼀の減衰式になる LUT（16-bit）をサンプルして減衰値を取得 Built-in URP Frame Debugger 101

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ポイントライト Built-in URP (Fixed) https://docs.unity3d.com/6000.0/Documentation/Manual/urp/lighting/custom-lighting-change-light-falloﬀ.html 102

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key PBR まとめ
• PBR は Built-in でのプロジェクト設定次第でかなり差が出るので注意 • URP のライティングは簡単に調整が可能 103

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key シャドウ 104

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • Close Fit Shadow Projection を採⽤していたが、URP は⾮対応 • カメラ視野に対してより厳密にシャドウマップを作成できるため、影の解像度確保に有利 Close Fit Shadow Projection Built-in (Close Fit) URP 105

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Close Fit Shadow Projection • 影の距離設定が Close Fit 前提となっていた • カスケードシャドウマップを利⽤すれば品質が上がり問題は根本解決する ◦ 採⽤検討をする時間が⾜りなかった Built-in (Close Fit) URP (2 Cascades) 106

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key 107 Close
Fit を再現実装する

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Close Fit Shadow Projection の再現実装 1. カリング前に影の描画距離を Far Clip に設定 2. カリング後に CullingResults.GetShadowCasterBounds API を利⽤して最⼤のシャドウキャスターバウンドを取得 3. 現在の最⼤影距離設定を考慮し、新しい影距離を計算 4. 新しい影距離でシャドウマップを描画 Built-in (Close Fit) URP (Close Fit) 108

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key シャドウまとめ •
プロジェクト設定によってはとても再現が⾯倒 • Close Fit を採⽤している場合は注意が必要 • 可能であればカスケードシャドウマップの採⽤を検討したほうが良い 109

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key 半透明とキャラクター 110

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key キャラクター描画構成 •
ほぼ全てが半透明描画 ◦ Geometry キュー、Depth Write ON で描画 111

ほぼ全てが半透明描画 ◦ Geometry キュー、Depth Write ON で描画 • アウトラインはマルチパスシェーダー（背⾯法） 112

Sorting Group 機能でメッシュ描画順を制御 113

Sorting Group 機能でメッシュ描画順を制御 • マテリアルのレンダーキューでも描画順制御 114

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key URP でのレンダーキュー問題
• URP では Sorting Group が Geometry キューで動作しない • Geometry キューは不透明オブジェクト⽤であるため、⾃然な仕様 • 不透明背景 • キャラクター • キャラクターアウトライン（マルチパス） • 半透明背景 • エフェクト Geometry Transparent 115

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key URP での解決策
• 半透明部分のキャラクター描画をすべて Transparent キューへ移⾏ • 不透明背景 • 半透明背景 • エフェクト • キャラクター • キャラクターアウトライン（Renderer Feature） Geometry Transparent 116

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key URP での解決策
• 半透明部分のキャラクター描画をすべて Transparent キューへ移⾏ • マルチパスシェーダーの描画順序が変わってしまった ◦ アウトラインを全キャラクター描画終了後のカスタムパスに移動 • 不透明背景 • 半透明背景 • エフェクト • キャラクター • キャラクターアウトライン（Renderer Feature） Geometry Transparent 117

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key Opaque Texture
とキャラクター • 半透明の描画順制御の影響で副作⽤が発⽣ 118

とキャラクター • 半透明の描画順制御の影響で副作⽤が発⽣ • Opaque Texture で再現が出来ない 119

とキャラクター Opaque Texture を使った描画に問題が発⽣ 120

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key URP の
Opaque Texture 機能不透明画⾯キャプチャ半透明 Camera Color Opaque Texture 121

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key キャラクター描画との相性問題 Camera
Color 不透明 122

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key キャラクター描画との相性問題 Camera
Color Opaque Texture 不透明画⾯キャプチャ 123

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key キャラクター描画との相性問題キャラクター
+ 鏡 Opaque Texture にキャラクターが映らない Camera Color Opaque Texture 不透明画⾯キャプチャ半透明 124

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key キャラクター描画との相性問題（修正後）不透明
半透明 (Before Capture) 画⾯キャプチャ半透明 (Transparent) 125

半透明 (Before Capture) 画⾯キャプチャ半透明 (Transparent) キャラクター Camera Color 126

半透明 (Before Capture) 画⾯キャプチャ半透明 (Transparent) キャラクター Camera Color Opaque Texture 127

半透明 (Before Capture) 画⾯キャプチャ半透明 (Transparent) 鏡キャラクター 128 Camera Color Opaque Texture

半透明 (Before Capture) 画⾯キャプチャ半透明 (Transparent) 鏡キャラクターキャラクターが写った Opaque Texture を⽣成できるようになった 129 Camera Color Opaque Texture

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ポストプロセス 130

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • Post
Processing Stack v2 (PPSv2) を採⽤していた • URP の実装は PPSv2 と異なる ◦ ハイエンド向けの機能が無いポストプロセス 132

• URP では再現できない機能‧⾒た⽬が⼤きく変わる機能を利⽤していた ◦ ⾃動露出、Bloom、⾊収差

• URP の実装を変更して対応することを検討 • しかし、今回の開発期間では難しいと判断

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ポストプロセス •
PPSv2 を URP のポストプロセスとして使えるように改造 • 以前は URP でも利⽤可能であったため、昔の公式実装例を参考に組み込み • ポストプロセスをそのまま再現 135

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ポストプロセスまとめ •
PPSv2 をそのまま利⽤することで、既存ポストプロセス設定を維持可能 • URP の標準ポストプロセスは利⽤不可 • RenderGraph への移⾏時に⼤幅改修が必要 136

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key 複数カメラ描画カメラスタック1
オフスクリーンレンダリングカメラスタッキングと Renderer Feature で簡単に再現 Base Camera Overlay Camera Base Camera Overlay Camera カメラスタック2 3D カメラ1 3D カメラ2 アップスケール UI 139

• コード変更のみで対応できず、データ修正も必要だった ◦ プログラムでバッチ修正する

• コード変更のみで対応できず、データ修正も必要だった ◦ プログラムでバッチ修正する • 対象アセット ◦ マテリアル ◦ プレハブ ◦ シーン

全マテリアルの描画キューの移動が発⽣ • マテリアルをテキスト解釈し、レンダーキュー設定を抽出、置き換え 144

全マテリアルの描画キューの移動が発⽣ • マテリアルをテキスト解釈し、レンダーキュー設定を抽出、置き換え • ⼿動でマッピングを作成 145

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key 複雑なアセット修正 •
Odin Validator を利⽤して Unity 上で実装 ◦ Unity アセットのバリデーションフレームワーク 146

Odin Validator を利⽤して Unity 上で実装 ◦ Unity アセットのバリデーションフレームワーク • アセットの問題を検出し、⼀覧表⽰ 147

Odin Validator を利⽤して Unity 上で実装 ◦ Unity アセットのバリデーションフレームワーク • アセットの問題を検出し、⼀覧表⽰ • 問題の検知と修正を同時に記述 148

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key バリデーション処理 public
static class ShaderUsage { public static bool RepairMaterial(Material material, bool isDryRun) } [assembly: RegisterValidationRule(typeof(MaterialValidator))] public class MaterialValidator : RootObjectValidator<Material> { protected override void Validate(ValidationResult result) { if (!ShaderUsage.RepairMaterial(Object, true)) { var errorInfo = new ResultItem("マテリアルの設定修正が必要です", ValidationResultType.Error); var fix = Fix.Create("設定修正", () => { ShaderUsage.RepairMaterial(Object, false); }); result.Add(errorInfo).WithFix(fix); } } } 149

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key バリデーション処理 150
public static class ShaderUsage { public static bool RepairMaterial(Material material, bool isDryRun) } [assembly: RegisterValidationRule(typeof(MaterialValidator))] public class MaterialValidator : RootObjectValidator<Material> { protected override void Validate(ValidationResult result) { if (!ShaderUsage.RepairMaterial(Object, true)) { var errorInfo = new ResultItem("マテリアルの設定修正が必要です", ValidationResultType.Error); var fix = Fix.Create("設定修正", () => { ShaderUsage.RepairMaterial(Object, false); }); result.Add(errorInfo).WithFix(fix); } } }

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • 運営開発ブランチを
URP ブランチにマージした場合に競合が発⽣するマイグレーションと競合解決運営ブランチ URP ブランチファイル A を追加マージファイル A を編集マージ 157 ファイル A をマイグレーションファイル A が競合！

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • 運営開発ブランチを
URP ブランチにマージした場合に競合が発⽣する • 運営開発ブランチを優先して解決する ◦ 最悪のケースでは何度も同⼀のアセットに対して修正をする必要があるマイグレーションと競合解決運営ブランチ URP ブランチファイル A を追加マージファイル A を編集マージ 158 ファイル A をマイグレーションファイル A が競合！

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ⾃動マイグレーションと競合解決 •
マイグレーションプログラムを組み込む • マージからマイグレーションまで完全⾃動化運営ブランチ URP ブランチマージマージ 159 運営ブランチを優先解決ファイル A をマイグレーションファイル A を追加ファイル A を編集ファイル A をマイグレーション

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ⾃動マイグレーションと競合解決 •
何度も同⼀アセットをマイグレーションしても差分が発⽣しないようにする • Jenkins で⾃動実⾏運営ブランチ URP ブランチマージマージ 160 運営ブランチを優先解決ファイル A をマイグレーションファイル A を追加ファイル A を編集ファイル A をマイグレーション

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key 実際の運⽤ 1⽉
2⽉ 3⽉ 4⽉ 5⽉ 6⽉ 7⽉ 8⽉ 9⽉マイグレーションツール開発 URP ブランチにマージシェーダー移植ライティングカメラ‧ポスプロ VFX PBR UI 161

2⽉ 3⽉ 4⽉ 5⽉ 6⽉ 7⽉ 8⽉ 9⽉マイグレーションツール開発半⾃動化⾃動化 QA リリース作業運営ブランチにマージ URP ブランチにマージシェーダー移植ライティングカメラ‧ポスプロ VFX PBR シャドウ最適化 UI 162

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key • 根本的に描画プログラムが変わっているため範囲が広い
• ⾃動化システム構築の時間が確保できなかったため⼈⼒で対応 Quality Assurance 168

• 根本的に描画プログラムが変わっているため範囲が広い • ⾃動化システム構築の時間が確保できなかったため⼈⼒で対応 • QA チームが描画⽐較チェックを実施 ◦ イベントを含んだ全コンテンツ ◦ iOS/Android/Windows ◦ 全キャラクター ◦ 全スキルカットシーン 169

• 根本的に描画プログラムが変わっているため範囲が広い • ⾃動化システム構築の時間が確保できなかったため⼈⼒で対応 • QA チームが描画⽐較チェックを実施 ◦ イベントを含んだ全コンテンツ ◦ iOS/Android/Windows ◦ 全キャラクター ◦ 全スキルカットシーン • モバイルは複数のチップセットでテスト 170

• Built-in と URP のパフォーマンス⽐較 ◦ メモリ不⾜によるクラッシュ ◦ ヒッチ ◦ ロード時間 171

• Built-in と URP のパフォーマンス⽐較 ◦ メモリ不⾜によるクラッシュ ◦ ヒッチ ◦ ロード時間 • フィードバックを元に最適化 ◦ 結果的に Built-in よりもパフォーマンスが向上 172

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key チェック体制 •
プログラマーも全コンテンツの描画⽐較を⽬視で確認 • スキルカットシーンは動画出⼒し、横並びで再⽣ ◦ バッチ動画出⼒するツールを活⽤ 173

• 地道に描画差分を修正バグ修正対応 175

• 地道に描画差分を修正 • シェーダー修正 = アセットのフルビルド ◦ 1ビルド20時間バグ修正対応 176

• 地道に描画差分を修正 • シェーダー修正 = アセットのフルビルド ◦ 1ビルド20時間 • ビルド担当者に⼤きな負担バグ修正対応 177

• 地道に描画差分を修正 • シェーダー修正 = アセットのフルビルド ◦ 1ビルド20時間 • ビルド担当者に⼤きな負担 • シェーダーに修正が必要な場合はビルド担当者に連絡バグ修正対応 178

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key バグ修正対応 •
Unity 本体のバージョンアップも対応しているためグラフィックス以外のバグも多数発⽣ ◦ 運営チームのサポートが発⽣ 179

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key 危険なシェーダープロパティ名 •
⼀部の Android 端末でシェーダーコンパイルエラーが発⽣ • 「__」で始まるプロパティ名が問題 • GLES の仕様では意図しない動作をすることがあるため注意 [HideInInspector]__dirty("", Int) = 1 180

by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key 完成 181 • ⾒た⽬に変化なし！ • 地味です Built-in URP

致命的な不具合はなかった • キャラクターシェーダーが ASE に移植されたため、アーティストによる改良が進んだ 184

致命的な不具合はなかった • キャラクターシェーダーが ASE に移植されたため、アーティストによる改良が進んだ • SRP Batcher の効果が⾼く、Static Batching をオフに出来た ◦ メモリ消費量の削減 185

致命的な不具合はなかった • キャラクターシェーダーが ASE に移植されたため、アーティストによる改良が進んだ • SRP Batcher が効果が⾼く、Static Batching をオフに出来た ◦ メモリ消費量の削減 • URP しか知らないプログラマーでも拡張がやりやすくなった 186

既存のシェーダー名が変わってしまっており、ツールが誤作動 • 新規アセットのみで発⽣する上、不具合の影響が分かりづらい 188

既存のシェーダー名が変わってしまっており、ツールが誤作動 • 新規アセットのみで発⽣する上、不具合の影響が分かりづらい • 理想的にはツールの QA が必要だが、ワークフローが確⽴していなかった 189

新規制作中のシーンのみ⾒た⽬の問題が発⽣ ◦ リリース後の制作で問題が発⽣するケースの発⾒が通常のゲームの QA では難しい 190

新規制作中のシーンのみ⾒た⽬の問題が発⽣ ◦ リリース後の制作で問題が発⽣するケースの発⾒が通常のゲームの QA では難しい • Unity Source Code の契約を検討すべきだった ◦ 検証と推測には限界がある 191

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key まとめ •
最終的にうまくいったが険しい道だった • 難しい選択を迫られる ◦ 描画を再現するためのコストと、得られるものを常に天秤にかけていた • グラフィックス改良の準備が整った 192

©WFS Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key ご清聴ありがとうございました ©WFS
Developed by WRIGHT FLYER STUDIOS ©VISUAL ARTS/Key

ヘブンバーンズレッドのレンダリングパイプライン刷新

ヘブンバーンズレッドのレンダリングパイプライン刷新

More Decks by gree_tech

Other Decks in Technology

Featured

Transcript