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