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

377 Views

September 26, 19

スライド概要

2019/9/25-6に開催されたUnite Tokyo 2019の講演スライドです。
三宅 喬志(KLab株式会社)
田中 康夫(KLab株式会社)
Fernandez Francisco(KLab株式会社)

こんな人におすすめ
・Timelineに興味がある方
・カットシーンを用いたタイトルに興味がある方
・モバイルでのプロファイリングやレンダリングの最適化に興味のある方

受講者が得られる知見
・禍つヴァールハイトでのTimeline活用事例
・モバイルで動く軽量なポストエフェクトの実装事例
・モバイルでのプロファイリングやレンダリングの最適化の手法


Unityのイベント資料はこちらから:
https://www.slideshare.net/UnityTechnologiesJapan/clipboards

profile-image

リアルタイム3Dコンテンツを制作・運用するための世界的にリードするプラットフォームである「Unity」の日本国内における販売、サポート、コミュニティ活動、研究開発、教育支援を行っています。ゲーム開発者からアーティスト、建築家、自動車デザイナー、映画製作者など、さまざまなクリエイターがUnityを使い想像力を発揮しています。

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
2.

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

3.

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

4.

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

5.

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

6.

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

7.

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

8.

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

9.

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

10.

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

11.

リアルタイム3D演出 11

12.

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

13.

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

14.

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

15.

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

16.

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

17.

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

18.

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

19.

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

20.

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

21.

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

22.

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

23.

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

24.

初期実装での問題 24

25.

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

26.

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

27.

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

28.

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

29.

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

30.

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

31.

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

32.

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

33.

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

34.

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

35.

初期実装から Timeline へ 35

36.

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

37.

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

38.

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

39.

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

40.

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

41.

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

42.

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

43.

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

44.

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

45.

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

46.

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

47.

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

48.

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

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

51.

Timeline だから 出来たこと 51

52.

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

53.

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

54.

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

55.

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

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

59.

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

60.

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

61.

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

62.

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

63.

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

64.

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

65.

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

66.

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

67.

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

68.

独自ポストエフェクト、大事なポイント 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 オ ッケー。

69.

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

72.

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

73.

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

74.

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

75.

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.

まとめ最適化の結果 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.

質疑応答 83