【Unite Tokyo 2019】「禍つヴァールハイト」Timelineだから可能だった！モバイルに最適化されたリアルタイム3D演出！
•
2 gostaram•4,970 visualizações
『禍つヴァールハイト』はモバイルのハイエンド向け3DリアルタイムMMOです。Timelineを活用してカットシーンなどの演出をいかにして作り込んだのか、使用したポストエフェクトにおける独自の最適化手法も講演で紹介します。
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a 【Unite Tokyo 2019】「禍つヴァールハイト」Timelineだから可能だった！モバイルに最適化されたリアルタイム3D演出！
Semelhante a 【Unite Tokyo 2019】「禍つヴァールハイト」Timelineだから可能だった！モバイルに最適化されたリアルタイム3D演出！ (20)
Mais de UnityTechnologiesJapan002
Mais de UnityTechnologiesJapan002 (20)
【Unite Tokyo 2019】「禍つヴァールハイト」Timelineだから可能だった！モバイルに最適化されたリアルタイム3D演出！
- 2. Timelineだから可能だった！モバ イルに最適化された リアルタイム3D演出！ 所属団体名 / KLab株式会社 登壇者名 / 三宅 喬志, 田中 康夫, Fernandez Francisco
- 3. Fernandez Francisco Technical Artist GPU周り最適化 YASUO TANAKA Lead Programmer システム担当がつ TAKASHI MIYAKE FX Lead Artist 演出 登壇者・自己紹介 3
- 4. 目次 4 — 禍つヴァールハイトとは — リアルタイム３D演出 — Timeline を用いた作業効率化に ついて — 禍つヴァールハイトの最適化 — まとめ — 質疑応答
- 5. 5 禍つヴァールハイトとは Takashi Miyake, FX Lead Artist miyake-t@klab.com
- 10. 10 禍つヴァールハイトとは
- 11. 11 リアルタイム3D演出
- 13. リアルタイム3D演出の目的：没入感 13 — 世界観・コンセプトアートの表現 – コンセプトアートの設定・雰囲気 を大事に — シナリオ・キャラクターを魅力的 に表現 – ３Dで演技・表情豊かな映像演出を 組み込む
- 14. 世界観・コンセプトアートの表現 14 — 荒廃した世界 — 立ち込める粒子 — 彩度の低いルック
- 15. LookDev・アートの落とし込み 15 — 環境粒子 — FOG — Post Processing Stack — 画面全体の色味調整
- 16. コンセプトアート・光の表現 粒子（光）が霧のように立ち込めている 世界観・シナリオに没入するための表現 16 LooKDev Unity FX・FOG・ポスト表現 Post Processing Stackを使用
- 19. 19 — 演技・カメラ — ライティング — FX — ポスト — データテーブル・サウンド 実制作：担当箇所
- 20. 20 — 背景のライティング — キャラモデルのライティング — モンスターのライティング 実制作：ライティング
- 22. 22 — ブルーム — DOF — カラコレ — ブラー — etc 実制作：PostEffects
- 23. 23 — キャラボイス — SE — BGM — 字幕のデータテーブル化 — ローカライズ 実制作：サウンド・字幕
- 24. 24 初期実装での問題
- 25. 25 — 1カットの工数 – おおよそ10ｈ — ビルド確認 – 4ｈ — １シーン約12カット – 10*12+4 = 124h — 全24シーン – 124*24=2976h(=372人日) — １年以上かかる 工数の問題
- 26. 表現の問題 26 — LooK Devの段階でやりたい表現 を詰め込んだ結果、端末が猛烈に 熱くなった（知ってた） — ただ、見た目を来る限り妥協した くないので、エンジニアに最適化 でなんとかならないか相談するこ とになった
- 27. リアルタイム３D演出の問題点のまとめ 27 — 作業が大変 – 確認作業や演出の組み込みに時間 がかかる – 楽に作業できる環境が欲しい — 負荷高くて端末が大変 – アセット数が多く、ポストがもり もりに入っている為、モバイルに 向かない – クオリティを下げたくない
- 28. Timeline を用いた 作業効率化について 28 Yasuo Tanaka, Lead Programmer tanaka-ya@klab.com
- 30. 初期実装とは 30 — Timeline に移行する前に構築し たシステム – 当時はUnity5で開発していたため 、Timelineがなかった – 社内で実績のあった実装をベース – プレビューシーンを用意
- 31. 初期実装の概要 31 — モデルはインゲーム共用 — キャラクター・カメラのアニメー ションは Maya で作成 — エフェクト・サウンドなどのタイ ミング制御は、 Animator イベン トやデータテーブルで対応 — シーンに登場するキャラクターと アニメーションをデータテーブル で関連付け
- 32. 32 Maya - アニメーション Unity - エフェクト - プレビュー確認 - 簡易すぎて不便 - シークバーが無くて任 意のフレームを確認で きない 等... 実機端末 - 動作確認 - ビルドされるまで確認 出来ないためイテレー ションが遅い データテーブル - アセット関連付け - ID指定 - サウンド - テキスト ワークフロー 移行前
- 33. 33 Maya - アニメーション Unity - エフェクト - プレビュー確認 - 再生機能のみ - 編集出来ない 実機端末 - 動作確認 - リアルタイム作業が 出来ない - イテレーション遅い ワークフロー 移行前問題 データテーブル - アセット関連付け - ID指定 - サウンド - テキスト - 毎回 DB 更新必要
- 34. 初期実装の問題 34 — 作業継続が困難 – アニメーション修正するたびに AnimationClip からイベントが消え るので再設定が必要 – よってアニメーション更新時に以 降の作業工程を止めないといけな い – 総じて修正コストが高い
- 36. 初期実装の結果 36 — 発生した課題 – プレビューの機能不足 – データシートの更新時間 – リアルタイム編集できない – イテレーションが遅い – イベント組み込みの再設定 – アニメーション更新の作業待ち
- 37. 初期実装の結果 37 — 課題の対応方針 – 検証の結果、Timeline へ移行する ことで、問題の解決を図ることに なった。
- 38. Timeline 移行計画 38 — 初期実装問題の解決タスク – エフェクト・サウンドなどのタイ ミング制御を Timeline トラックで 対応 – イベントコールバックを PlayableBehaviour へ移植 – プレビューシーンを Timeline エデ ィターに移植
- 39. 39 Maya - アニメーション Unity - エフェクト - プレビュー確認 - 再生機能のみ - 編集出来ない 実機端末 - 動作確認 - リアルタイム作業が 出来ない - イテレーション遅い ワークフロー 移行前問題 データテーブル - アセット関連付け - ID指定 - サウンド - テキスト - 毎回 DB 更新必要
- 40. 40 Maya - アニメーション Unity - エフェクト - プレビュー確認 - 再生機能のみ - 編集出来ない 実機端末 - 動作確認 - リアルタイム作業が 出来ない - イテレーション遅い ワークフロー 移行前問題 データテーブル - アセット関連付け - ID指定 - サウンド - テキスト - 毎回 DB 更新必要 Timeline へ 移行
- 41. Timeline 移行計画 41 — 移行に掛かった期間 – Unity バージョンアップ – ワークフローとアセット更新環境の 修正、移行後インゲームの正常系動 作確認まで – 呼び出し側の対応としては RuntimeAnimatorControllerから PlayableDirectorのバインドに変更。 – 完了まで約１ヶ月
- 42. Timeline 対応ルール 42 — 1 シーン ＝ 1 PlayableDirector – カットは隙間なく再生したいので シーン内直列 — 担当者ごとにトラック作成 – 複数作業者の編集がコンフリクト しないようにトラックを担当者ご とに分ける
- 43. 自動トラック作成 43 — シーンアセットからトラックを含 む PlayableDirector アセットを自 動作成 – エディタ拡張で作成 – 作業工数削減
- 44. 自動トラック作成 44 — トラック名をルール化して自動・ 手動で作成したトラックを共存 – 自動はnodeプリフィックス、トラ ック種、操作対象を表す – 例： node_Animation_CM01 – 名前識別により自動作成トラック のみをツールで更新
- 45. 自動トラック作成 45 — 自動トラック追加 – キャラクター – 背景 – オブジェクト – カメラ – ライトオブジェクト 3Dモデルが存在するものは、 アニメーションと同時にトラック追加 — 手動トラック追加 – 各種エフェクト – 各種サウンド – 字幕・テロップ
- 46. セットアップ機能 46 — シーンアセットからTimelineエデ ィターのセットアップを行うエデ ィタ拡張 – エディットアバター都合 – ヒエラルキーにインスタンス化 → PlayableDirector の ExposedReferenceバインドまで一 括で行う。
- 47. Playable トラック 47 — テキストやサウンドの対応 – リソースをアタッチせず、 Playable クリップに ID 設定 – マスタによる外部変更を容易に – PlayableBehaviour 内の処理で ID から DB 抽出を行い、UIやサウンド APIと連携
- 48. Timeline エディター 48 — プレビューシーンから移植 – ゲームが実行していないのでゲー ムイベント内の実装箇所を変更 – ExecuteInEditMode アトリビュー トの追加を行ったが期待した動作 ではなかった。 – PlayableDirector を持つ GameObject に後述プレビュークラ スを作成・コンポーネント化
- 49. プレビュークラス例 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
- 50. Timeline エディター 50 — ランダムアクセス対応 – シークで再生時間を戻すと値が追 従しないことがあった – 0 フレームに必ずキーを打つ — 作業イテレーション – トラック編集とアセットをコンポ ジットit – 実機確認はプレビューシーンを引 き続き使う
- 52. ライティング 52 — 平行光源・リムライト – Pixel Light Count は常に 1 – モバイル負荷都合 — ライト方向をキャラクター個別に 設定 – マテリアルにライト方向を設定 – デザイナーがカットごとに調整で きる
- 53. Recording 機能 53 — Animation トラックに直接アニメ ーションを保存 — カット間のスムーズなプロパティ アニメーション対応 – Transform 各値 – ライティング – ポストエフェクト
- 54. 54 Maya - アニメーション Unity - エフェクト - プレビュー確認 - 再生機能のみ - 編集出来ない 実機端末 - 動作確認 - リアルタイム作業が 出来ない - イテレーション遅い ワークフロー 移行前問題 データテーブル - アセット関連付け - ID指定 - サウンド - テキスト - 毎回 DB 更新必要 Timeline へ 移行
- 55. 55 Maya - アニメーション Unity - エフェクト - Timeline - シーク操作 - 編集即プレビュー - イベントキー拡張 - アセット関連付け - トラック分割による 並行作業 実機端末 - 動作確認 - FIX確認のみでOK ワークフロー 移行後
- 56. 効率化の結果 56 — どれぐらいの工数削減？ — 仕様 – 24シーン作成 – 1シーンあたり12カット – 1カットあたり実機2回チェック — 実機確認までの時間 – 移行で1回 3h → 1h = 2h削減
- 57. 効率化の結果 57 — よって – 24シーン x 12カット x 2回チェッ ク x 2h削減 = 1152h – 1日8hとすると – 1152h / 8h = 144d 144日削減！！
- 58. まとめ 58 — Timeline 機能 – トラックを自由に追加できるので 管理がしやすい – PlayableTrack による拡張が容易 – データテーブルやAnimatorイベン トは Playable クリップに – Recording 機能 でスムーズなプロ パティアニメーション — Timeline エディター – コンポジット作業に最適 – リアルタイムでアセット編集結果 を確認できる – 外部アセットは PlayableTrack を 用意する場合がある – 実機確認の手段は別途用意
- 59. 59 禍つヴァールハイトの最適化。 Fernandez Francisco, Technical Artist fernandez-f@klab.com
- 61. 困った問題確認ツール紹介 (A.K.A : Fran Tools) 61
- 62. — どんなUnityバージョンでも出来るプロファイラー。 — リリースモードもログを保存します。 — モードに関して別データをログします。(Debug Mode, Editor, Ios, Android) — 端末のネイティブメモリを保存します。 — できるだけのoverhead無し。 — Bookmarkまたはイベントログ。 — プロファイラーデータを比較するが必要です。 — 充電無し、USB無し。 62 ゲーム中のプロファイラーツール
- 63. 63 OverDraw / Shader ツール Replace with image Shader / Texture ゲーム中でシェーダーと Textureサイズを変更する ことができます。 HeatMapビューア ある程度ターゲット端末の FillRateを確認することが 出来ます。 黒い部分はGPUに重いです 。(FPSが落ちる) OverDrawビューア Particlesの重なりを確認す ることが出来ます。 Particlesを配置する際の参 考に使用します。
- 64. 64 WEBプロファイラーツール Sessionsを比較。 イベントとBookmark (ロード, Field, Cutscene, Battle, etc) ネイティブFunctionを呼ぶ。（Java, Objc-c） Bookmark
- 65. 65 Unityプロファイラーツール。 WEBプロファイラーでUnityて取った Binaryデータを確認することができます 。 Unityのプロファイラーを独自に開発しま した。 — Functionを選ぶ。 — 色々なプロファイルデータを比較 。 — FPS, ms, GBの平均。 — など。
- 66. 困った問題が分かりました 66 — CutsceneのFrame Rateが低い。 – ポストエフェクトが重い。 – DrawCallが多い。 – レンダリングの順番が正しくな い。 – Particles / FBX / Shaderが重い 。
- 68. GPU Depth Texture — 被写界深度。 — フォグ。 — 早い、Opengl 2.0 オ ッケー。 ぼかす — Dual Filteringでぼかす。 — Downsample 1/4-1/8。 — Upsample 1/4-1/2。 — 低い解像度でポストエフ ェクトを描く。 ブルームマスク — Alpha Bufferを使用し てBloom maskを作る 。 独自ポストエフェクト、大事なポイント 68 Replace with image
- 69. 最適化前 -> 最適化後 20+ ms -> 4ms 独自ポストエフェクトの最適化結果 69 Bloom (Fake HDR), Vignette, Depth Of Field, Radial Blur, Blur, 2d Color Correction, Fog.
- 71. 71 レンダリング順番 と 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だけを描きます。
- 72. レンダリング順番の問題。何回も同じPixelを 描いています。 SnapDragon profilerで確認することができま す。 Early Z-TestやCombine Meshなどの結果 72 1291 Draw Call -> 33 Draw Call。 Mesh 40.85 ms -> 5.1 ms。 Dynamic Mech 7.8 ms -> 0 ms。
- 73. 困った問題 73 FBX Setup/ Particles Effects / Shaders が重い
- 74. OpenGL 3 GPU Instanceは全部の端末で使え ないです。 メーカーによってOpenGL 3.0の サポートがあります。 Google OpenGL Usage Noise Module Particle Modulesを注意くだ さい。使用するModuleによ ってはCPU負荷が高いです 。 — CallBack Module。 — Noise Module。 Missing Material ツール UnityのDefault Materialとシ ェーダーをコンパイルとロ ードをしないようにするた めのツールです。 FBX / Particles / Shader 最適化、大事なポイント 74 Replace with image
- 75. XCode Run Timeでシェーダーを変更出 来ます。 そのほか、PixelやVertexを1つず 確認したり、GPUスレッドを比 較して確認することが出来ます 。 Shader Variant ツール ゲームを遊びながらシェー ダーVariantを自動で作るツ ール。 これをRun Timeにシェーダ ーのWarm Upに使います。 Grab Pass シェーダーのGrabPassはモ バイルで結構重い。別の方法 を使用した方がよいです。メ モリー 5MB。 GPU 6 ms.。 (iOS / Android) FBX / Particles / Shader 最適化、大事なポイント 75 Replace with image
- 76. 76 まとめ最適化の結果
- 77. もう困ってないです 77 IPhone X とターゲット端末 — 50フレームほど速くなりました。 — 見た目はまるで同じ。 — 端末の熱さが少ない, プレイ時間が長く できます。 — Steady 60 FPS — (Q3 2015, Iphone 6s)。
- 78. まとめ 78
- 79. 79 より良い世界観表現をする為に — Timelineを使うことでワークフロー の改善ができた – 制作効率UP – 実装確認が容易 – 加えてアーティストにとってなじみ深 い操作感で生産性UP — 最適化を行う事で、表現をよりこだ わる事ができた – 膨大なアセットの同時表示 – クオリティの高い見た目を作れる — 世界観作れてリリースに間に合う
- 80. これからの禍つヴァールハイト 80 — クオリティの向上 – 切り替わりを意識させないシーム レスな演出 – 新たなポストエフェクトの追加 – RAMPカラー – LWRP対応 – HDRの取り組み – ソフトシャドウ
- 83. 質疑応答 83