【Unite Tokyo 2019】「禍つヴァールハイト」Timelineだから可能だった！モバイルに最適化されたリアルタイム3D演出！

Timelineだから可能だった！モバ イルに最適化された リアルタイム3D演出！ 所属団体名 / KLab株式会社 登壇者名 / 三宅 喬志, 田中 康夫, Fernandez Francisco

登壇者・自己紹介 TAKASHI MIYAKE YASUO TANAKA Fernandez Francisco FX Lead Artist Lead Programmer Technical Artist 演出 システム担当がつ GPU周り最適化 3

目次 — 禍つヴァールハイトとは — リアルタイム３D演出 — Timeline を用いた作業効率化に ついて — 禍つヴァールハイトの最適化 — まとめ — 質疑応答 4

禍つヴァールハイトとは Takashi Miyake, FX Lead Artist [email protected] 5

禍つヴァールハイトとは 6

禍つヴァールハイトとは 7

禍つヴァールハイトとは 8

禍つヴァールハイトとは 9

禍つヴァールハイトとは 10

リアルタイム3D演出 11

リアルタイム3D演出 本編7章でヒロインのパーシバルが、 傷つき意識の無い主人公に決意を独白 するシーン 12

リアルタイム3D演出の目的：没入感 — 世界観・コンセプトアートの表現 – コンセプトアートの設定・雰囲気 を大事に — シナリオ・キャラクターを魅力的 に表現 – ３Dで演技・表情豊かな映像演出を 組み込む 13

世界観・コンセプトアートの表現 — 荒廃した世界 — 立ち込める粒子 — 彩度の低いルック 14

LookDev・アートの落とし込み — 環境粒子 — FOG — Post Processing Stack — 画面全体の色味調整 15

世界観・シナリオに没入するための表現 コンセプトアート・光の表現 LooKDev Unity 粒子（光）が霧のように立ち込めている FX・FOG・ポスト表現 Post Processing Stackを使用 16

機動兵団の一員としての体験 — プレイヤーを禍つの世界に落とし 込む — インゲームに登場させる — 演出と同期させる 17

世界観・シナリオに没入するための表現 プレイヤーを禍つの世界に落とし込み、インゲー 物語の一部として、プレイヤーを登場させる ムと同期した見え方にする 18

実制作：担当箇所 — 演技・カメラ — ライティング — FX — ポスト — データテーブル・サウンド 19

実制作：ライティング — 背景のライティング — キャラモデルのライティング — モンスターのライティング 20

実制作：FX — 世界観・粒子の表現 — Shurikenによる効果FX 21

実制作：PostEffects — ブルーム — DOF — カラコレ — ブラー — etc 22

実制作：サウンド・字幕 — キャラボイス — SE — BGM — 字幕のデータテーブル化 — ローカライズ 23

初期実装での問題 24

工数の問題 — 1カットの工数 – おおよそ10ｈ — ビルド確認 – 4ｈ — １シーン約12カット – 10*12+4 = 124h — 全24シーン – 124*24=2976h(=372人日) — １年以上かかる 25

表現の問題 — LooK Devの段階でやりたい表現 を詰め込んだ結果、端末が猛烈に 熱くなった（知ってた） — ただ、見た目を来る限り妥協した くないので、エンジニアに最適化 でなんとかならないか相談するこ とになった 26

リアルタイム３D演出の問題点のまとめ — 作業が大変 – 確認作業や演出の組み込みに時間 がかかる – 楽に作業できる環境が欲しい — 負荷高くて端末が大変 – アセット数が多く、ポストがもり もりに入っている為、モバイルに 向かない – クオリティを下げたくない 27

Timeline を用いた 作業効率化について Yasuo Tanaka, Lead Programmer [email protected] 28

Timeline導入前の実装 (初期実装） 29

初期実装とは — Timeline に移行する前に構築し たシステム – 当時はUnity5で開発していたため、 Timelineがなかった – 社内で実績のあった実装をベース – プレビューシーンを用意 30

初期実装の概要 — モデルはインゲーム共用 — キャラクター・カメラのアニメー ションは Maya で作成 — エフェクト・サウンドなどのタイ ミング制御は、 Animator イベン トやデータテーブルで対応 — シーンに登場するキャラクターと アニメーションをデータテーブル で関連付け 31

ワークフロー 移行前 Unity - エフェクト - プレビュー確認 - 簡易すぎて不便 - Maya - シークバーが無くて任 意のフレームを確認で きない 等... アニメーション データテーブル - アセット関連付け - ID指定 - サウンド - テキスト 32 実機端末 - 動作確認 - ビルドされるまで確認 出来ないためイテレー ションが遅い

ワークフロー 移行前問題 Unity - エフェクト - プレビュー確認 Maya - - 再生機能のみ - 編集出来ない 実機端末 - アニメーション データテーブル 動作確認 - リアルタイム作業が 出来ない - アセット関連付け - ID指定 - サウンド - テキスト - 毎回 DB 更新必要 33 - イテレーション遅い

初期実装の問題 — 作業継続が困難 – アニメーション修正するたびに AnimationClip からイベントが消え るので再設定が必要 – よってアニメーション更新時に以 降の作業工程を止めないといけな い – 総じて修正コストが高い 34

初期実装から Timeline へ 35

初期実装の結果 — 発生した課題 – プレビューの機能不足 – データシートの更新時間 – リアルタイム編集できない – イテレーションが遅い – イベント組み込みの再設定 – アニメーション更新の作業待ち 36

初期実装の結果 — 課題の対応方針 – 検証の結果、Timeline へ移行する ことで、問題の解決を図ることに なった。 37

Timeline 移行計画 — 初期実装問題の解決タスク – エフェクト・サウンドなどのタイ ミング制御を Timeline トラックで 対応 – イベントコールバックを PlayableBehaviour へ移植 – プレビューシーンを Timeline エデ ィターに移植 38

ワークフロー 移行前問題 Unity - エフェクト - プレビュー確認 Maya - - 再生機能のみ - 編集出来ない 実機端末 - アニメーション データテーブル 動作確認 - リアルタイム作業が 出来ない - アセット関連付け - ID指定 - サウンド - テキスト - 毎回 DB 更新必要 39 - イテレーション遅い

ワークフロー 移行前問題 Unity - エフェクト - プレビュー確認 Maya - - 再生機能のみ - 編集出来ない Timeline へ 移行 実機端末 - アニメーション データテーブル 動作確認 - リアルタイム作業が 出来ない - アセット関連付け - ID指定 - サウンド - テキスト - 毎回 DB 更新必要 40 - イテレーション遅い

Timeline 移行計画 — 移行に掛かった期間 – Unity バージョンアップ – ワークフローとアセット更新環境の 修正、移行後インゲームの正常系動 作確認まで – 呼び出し側の対応としては RuntimeAnimatorControllerから PlayableDirectorのバインドに変更。 – 完了まで約１ヶ月 41

Timeline 対応ルール — 1 シーン ＝ 1 PlayableDirector – カットは隙間なく再生したいので シーン内直列 — 担当者ごとにトラック作成 – 複数作業者の編集がコンフリクト しないようにトラックを担当者ご とに分ける 42

自動トラック作成 — シーンアセットからトラックを含 む PlayableDirector アセットを自 動作成 – エディタ拡張で作成 – 作業工数削減 43

自動トラック作成 — トラック名をルール化して自動・ 手動で作成したトラックを共存 – 自動はnodeプリフィックス、トラ ック種、操作対象を表す – 例： node_Animation_CM01 – 名前識別により自動作成トラック のみをツールで更新 44

自動トラック作成 — 自動トラック追加 — 手動トラック追加 – キャラクター – 各種エフェクト – 背景 – 各種サウンド – オブジェクト – 字幕・テロップ – カメラ – ライトオブジェクト 3Dモデルが存在するものは、 アニメーションと同時にトラック追加 45

セットアップ機能 — シーンアセットからTimelineエデ ィターのセットアップを行うエデ ィタ拡張 – エディットアバター都合 – ヒエラルキーにインスタンス化 → PlayableDirector の ExposedReferenceバインドまで一 括で行う。 46

Playable トラック — テキストやサウンドの対応 – リソースをアタッチせず、Playable クリップに ID 設定 – マスタによる外部変更を容易に – PlayableBehaviour 内の処理で ID から DB 抽出を行い、UIやサウンド APIと連携 47

Timeline エディター — プレビューシーンから移植 – ゲームが実行していないのでゲーム イベント内の実装箇所を変更 – ExecuteInEditMode アトリビュー トの追加を行ったが期待した動作 ではなかった。 – PlayableDirector を持つ GameObject に後述プレビュークラ スを作成・コンポーネント化 48

プレビュークラス例 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [RequireComponent(typeof(PlayableDirector))] Public class TimelinePreviewBehaviour : MonoBehaviour { void OnEnable() { if (EditorApplication.isPlayingOrWillChangePlaymode) return; // TODO: awake impl. EditorApplication.update += OnUpdate; } void OnDisable() { EditorApplication.update -= OnUpdate; } void OnUpdate() { if (EditorApplication.isPlayingOrWillChangePlaymode) return; // TODO: update impl. } 49

Timeline エディター — ランダムアクセス対応 – シークで再生時間を戻すと値が追 従しないことがあった – 0 フレームに必ずキーを打つ — 作業イテレーション – トラック編集とアセットをコンポ ジットit – 実機確認はプレビューシーンを引 き続き使う 50

Timeline だから 出来たこと 51

ライティング — 平行光源・リムライト – Pixel Light Count は常に 1 – モバイル負荷都合 — ライト方向をキャラクター個別に 設定 – マテリアルにライト方向を設定 – デザイナーがカットごとに調整で きる 52

Recording 機能 — Animation トラックに直接アニメ ーションを保存 — カット間のスムーズなプロパティ アニメーション対応 – Transform 各値 – ライティング – ポストエフェクト 53

ワークフロー 移行前問題 Unity - エフェクト - プレビュー確認 Maya - - 再生機能のみ - 編集出来ない Timeline へ 移行 実機端末 - アニメーション データテーブル 動作確認 - リアルタイム作業が 出来ない - アセット関連付け - ID指定 - サウンド - テキスト - 毎回 DB 更新必要 54 - イテレーション遅い

ワークフロー 移行後 Unity Maya - アニメーション - エフェクト - Timeline - シーク操作 - 編集即プレビュー - イベントキー拡張 - アセット関連付け - トラック分割による 並行作業 55 実機端末 - 動作確認 - FIX確認のみでOK

効率化の結果 — どれぐらいの工数削減？ — 仕様 – 24シーン作成 – 1シーンあたり12カット – 1カットあたり実機2回チェック — 実機確認までの時間 – 移行で1回 3h → 1h = 2h削減 56

効率化の結果 — よって – 24シーン x 12カット x 2回チェック x 2h削減 = 1152h – 1日8hとすると – 1152h / 8h = 144d 144日削減！！ 57

まとめ — Timeline 機能 – — Timeline エディター トラックを自由に追加できるので 管理がしやすい – PlayableTrack による拡張が容易 – データテーブルやAnimatorイベン – コンポジット作業に最適 – リアルタイムでアセット編集結果 を確認できる – 意する場合がある トは Playable クリップに – 外部アセットは PlayableTrack を用 – Recording 機能 でスムーズなプロ パティアニメーション 58 実機確認の手段は別途用意

禍つヴァールハイトの最適化。 Fernandez Francisco, Technical Artist [email protected] 59

困った問題 CutsceneのFrame Rateが低い 60

困った問題確認ツール紹介 (A.K.A : Fran Tools) 61

ゲーム中のプロファイラーツール — どんなUnityバージョンでも出来るプロファイラー。 — リリースモードもログを保存します。 — モードに関して別データをログします。(Debug Mode, Editor, Ios, Android) — 端末のネイティブメモリを保存します。 — できるだけのoverhead無し。 — Bookmarkまたはイベントログ。 — プロファイラーデータを比較するが必要です。 — 充電無し、USB無し。 62

OverDraw / Shader ツール Replace with image OverDrawビューア HeatMapビューア Shader / Texture Particlesの重なりを確認す ある程度ターゲット端末の ゲーム中でシェーダーと ることが出来ます。 FillRateを確認することが Textureサイズを変更するこ 出来ます。 とができます。 Particlesを配置する際の参 考に使用します。 黒い部分はGPUに重いで す。(FPSが落ちる) 63

WEBプロファイラーツール Sessionsを比較。 ネイティブFunctionを呼ぶ。（Java, Objc-c） イベントとBookmark (ロード, Field, Cutscene, Battle, etc) 64 Bookmark

Unityプロファイラーツール。 WEBプロファイラーでUnityて取った Binaryデータを確認することができます。 Unityのプロファイラーを独自に開発しま した。 — Functionを選ぶ。 — 色々なプロファイルデータを比 較。 — FPS, ms, GBの平均。 — など。 65

困った問題が分かりました — CutsceneのFrame Rateが低い。 – ポストエフェクトが重い。 – DrawCallが多い。 – レンダリングの順番が正しくな い。 – Particles / FBX / Shaderが重 い。 66

困った問題 ポストエフェクトが重い 67

独自ポストエフェクト、大事なポイント Replace with image ブルームマスク — GPU Depth Texture ぼかす Alpha Bufferを使用し — Dual Filteringでぼかす。 てBloom maskを作 — Downsample る。 — Upsample 1/4-1/2。 1/4-1/8。 — 低い解像度でポストエフ ェクトを描く。 68 — 被写界深度。 — フォグ。 — 早い、Opengl 2.0 オ ッケー。

独自ポストエフェクトの最適化結果 最適化前 -> 最適化後 Bloom (Fake HDR), Vignette, Depth Of Field, Radial Blur, Blur, 2d Color Correction, Fog. 20+ ms -> 4ms 69

困った問題 レンダリングの順番が正しくない 70

レンダリング順番 と Draw Call — 1200 Draw Calls。 — 40.85 ms CPU。 — 7.8 ms Dynamic Mesh Batching。 — Static Batching 無し。 — 正しくないRendering順番。 – 不透明(Opaque), Rendering順番は先前か ら後ろまで。 — Early Z-Test 無し。 – Z-Test を強制することができます, render Color Mask 0, 先にDepthだけを描きます。 71

Early Z-TestやCombine Meshなどの結果 1291 Draw Call -> 33 Draw Call。 レンダリング順番の問題。何回も同じPixelを 描いています。 Mesh 40.85 ms -> 5.1 ms。 SnapDragon profilerで確認することができま す。 Dynamic Mech 7.8 ms -> 0 ms。 72

困った問題 FBX Setup/ Particles Effects / Shaders が重い 73

FBX / Particles / Shader 最適化、大事なポイント Replace with image Missing Material ツール UnityのDefault Materialとシ ェーダーをコンパイルとロ ードをしないようにするた めのツールです。 Noise Module OpenGL 3 Particle Modulesを注意くだ GPU Instanceは全部の端末で使え さい。使用するModuleによ ってはCPU負荷が高いです。 ないです。 メーカーによってOpenGL 3.0の サポートがあります。 — CallBack Module。 — Noise Module。 74 Google OpenGL Usage

• https://developer.android.com/about/dashboards

FBX / Particles / Shader 最適化、大事なポイント Replace with image Grab Pass シェーダーのGrabPassはモバ イルで結構重い。別の方法を 使用した方がよいです。メモ リー 5MB。 GPU 6 ms.。 (iOS / Android) Shader Variant ツール ゲームを遊びながらシェー XCode Run Timeでシェーダーを変更出 来ます。 ダーVariantを自動で作るツ そのほか、PixelやVertexを1つず ール。 確認したり、GPUスレッドを比 これをRun Timeにシェーダ ーのWarm Upに使います。 75 較して確認することが出来ます。

まとめ最適化の結果 76

もう困ってないです IPhone X とターゲット端末 — 50フレームほど速くなりました。 — 見た目はまるで同じ。 — 端末の熱さが少ない, プレイ時間が長く できます。 — Steady 60 FPS — (Q3 2015, Iphone 6s)。 77

まとめ 78

より良い世界観表現をする為に — Timelineを使うことでワークフロー の改善ができた – 制作効率UP – 実装確認が容易 – 加えてアーティストにとってなじみ深 い操作感で生産性UP — 最適化を行う事で、表現をよりこだ わる事ができた – 膨大なアセットの同時表示 – クオリティの高い見た目を作れる — 世界観作れてリリースに間に合う 79

これからの禍つヴァールハイト — クオリティの向上 – 切り替わりを意識させないシーム レスな演出 – 新たなポストエフェクトの追加 – RAMPカラー – LWRP対応 – HDRの取り組み – ソフトシャドウ 80

禍つヴァールハイトをよろしくお願いします 81

ご静聴 ありがとうございました 82

質疑応答 83