【CEDEC2014】アセットパイプラインを構築する上で重要な事～映像業界⇔ゲーム業界双方の視点から見た本質的なパイプライン
•Download as PPTX, PDF•
19 likes•6,368 views
CEDEC2014で講演させていただいた「アセットパイプラインを構築する上で重要な事～映像業界⇔ゲーム業界双方の視点から見た本質的なパイプライン」の資料です。
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to 【CEDEC2014】アセットパイプラインを構築する上で重要な事～映像業界⇔ゲーム業界双方の視点から見た本質的なパイプライン
Similar to 【CEDEC2014】アセットパイプラインを構築する上で重要な事～映像業界⇔ゲーム業界双方の視点から見た本質的なパイプライン (20)
Recently uploaded
Recently uploaded (9)
【CEDEC2014】アセットパイプラインを構築する上で重要な事～映像業界⇔ゲーム業界双方の視点から見た本質的なパイプライン
- 1. アセットパイプラインを構築する上で重要なこと 映像業界⇔ゲーム業界双方の視点 から見た本質的なパイプライン 長舩龍太郎 Ben Carter ※ハッシュタグ＃CEDEC_PFG
- 2. 講演者紹介 • 長舩龍太郎 – 司会進行 • バンダイナムコスタジオ（旧ナムコ）のTEC • Facebook海外TA勉強会管理人 • Ben Carter – メインスピーカー • Heavy Spectrum Entertainment Labsプログラマ • 元EA Games UKでリードプログラマー等豊富なキャリア – ハリーポッター、ニードフォースピード等 • アセットパイプライン関連書籍の執筆多数 – Production Pipeline Fundamentals、The Game Asset Pipeline等 2
- 3. 本セッションの背景 • 昨今のゲーム開発事情 – ますますパイプライン大規模化、複雑化 • 堅牢で柔軟なパイプライン構築の重要性 – リアルタイムCG技術の向上 • 映像業界↔ゲーム業界のクロスオーバー – 双方の距離がさらに接近 – 共通点と相違点、互いの長所を短所で埋める動き • 映像業界 • ゲーム業界 3
- 4. 本セッションの背景 • Production Pipeline Fundamentals for Film and Game（PFG本）の発売 – 映像業界⇔ゲーム業界の双方の視点から 本質的なパイプラインを体系的にまとめた良著（2014年２月） – 欧米の様々な教育機関の教科書として採用予定 • カーネギーメロン大学、サンフランシスコ州立大学等… – 日本語版もボーンデジタル様から2014年9月下旬発売予定 4
- 5. 本セッションの概要 • 目的 – ゲーム業界⇔映像業界双方の視点からの アセットパイプラインのガイドラインの紹介 – 各アセットパイプラインの再構築、リファインのきっかけ • 対象 – アセットパイプラインにかかわってる人、興味持ってる人なら誰 でも • パイプラインエンジニア • プログラマ、テクニカルアーティスト • インハウスゲーム環境の開発者、ユーザー • 市販ゲームエンジンのユーザー等… 5
- 6. 概要- アセットパイプライン • パイプラインが必要となる背景 • パイプラインの理論 • パイプラインの実用 6
- 8. 本講演のモチベーション 黒歴史からの例： • サーバー上で6か月バックアップできなかった。理由はなぜか名前が3000文字のフォルダが作成さ れていて、そのファイルがバックアップソフトをクラッシュさせていたから。そして不幸にも誰 もそのファイルの消し方がわからなかったから。 • 全てのファイル名はとっても適切に命名されている。たとえば、”test01”あるいは”hogehoge"... • 新しいファイルが古いファイルを上書きしてしまう、あるいは古いファイルを"old_"をつけて リネームしたり、新しいファイルに"new", "new final", "really final3"…とか命名している。 • 作ったモデルをゲーム内で見るためは、アーティストがプログラマーにデーターをメールして、 そのプログラマーが暇な時にデータを変換することを待つしかなかった • いつでも、誰かが間違った手順を取るとビルドが一日中停止。次第に誰もが被害妄想を持って、 更新するのが億劫に… • ゲームディスクのビルドには24時間かかり、3人のプログラマーと大規模の魔術儀式が必要です。 8
- 9. アセットとは何か？ このような物： • テクスチャ、モデル、アニメーション、マテリ アル、 オーディオエフェクト、マップレイアウト、 • コリジョン・物理情報、ローカリゼーションデー タ、 スクリプト（頻繁）、シェーダー（時々） 9
- 10. アセットとは何か？ こんな方々によって作られています： • アーティスト、ライター、プログラマー、 オーディオデザイナー、スクリプター、プロデ ューサー • 自動処理 • （基本的に全員！） 10
- 11. アセットとは何か？ こんな方法で制作されている： • DCCツール（Photoshop/Maya等） • キャプチャー処理 （写真/モーキャプ/LIDAR/Photogrammetry） • インハウス編集ツール（レベルエディター等） • 自動変換ツール 11
- 12. アセットパイプラインとは何か ？ワークフロー例1 12 テクスチャアーティストPhotoshop TGAファイル テクスチャの変更 ゲーム
- 13. アセットパイプラインとは何か ？ワークフロー例2 メッシュの変更 13 モデラーMaya MBファイル ゲーム テクスチャアーティストPhotoshop TGAファイル テクスチャの変更
- 14. ワークフロー • ワークフローは時と共に変動する – 一見関係のない変更の結果としてよく変わってしまう！ • 技術の変動が新しい要件やツールを引き起こす – たとえば、PBR（物理ベースレンダリング）とか • その場しのぎの変更が影響を及ぼさないか注意しよう – 例：ツールのバージョン更新によって新たな機能が追加(あるいは削除）されるかもしれない • ユーザーはパイプラインが「壊れている」のすら気付かないかもしれない – 見逃したディペンデンシー（依存関係）、本来より時間がかかる処理が容易に見落とされる 可能性 14
- 15. コンテンツの処理 15 TGAファイルテクスチャ圧縮DDSファイル メモリ内でのバイナリ変換ゲーム特有ファイルパッケージング インストーラーパッケージ
- 16. コンテンツの処理 16 メッシュファイルライトマップUV生成頂点最適化 AOベイキングコリジョンジオメトリ抽出中間メッシュ コリジョンジオメトリ依存テクスチャの抽出 メモリ内でのバイナリ変換 ゲーム特有ファイル AOテクスチャTGA テクスチャ圧縮 DDSファイル インストーラーパッケージパッケージング テクスチャTGA テクスチャ圧縮 DDSファイル
- 17. コンテンツの格納 • ソースデータ：バージョン管理システム （Perforce/SVN/Shotgun等）内に格納するデータ • 中間データ：ローカルストレージに格納するデ ータ、 高速キャッシュデータ • ゲームデータ：ローカルストレージに格納する データ、 ビルドディスク、アーカイブ 17
- 18. バージョン管理とは何か？ • すべての編集可能なファイルの履歴を保持 • 複数ユーザーが同時にファイル編集が可能、 (制限付きの）マージ機能のサポート • (必要ならば）複数ユーザーが1ファイルの同時編集を禁止すること も可能 • ブランチ： 他の誰にも影響を及ぼさずに、分離して機能実装あるいは実験が可 能 • アトミックトランザクション： 複数ユーザーが矛盾する結果を導くことなく同時に処理が可能 18
- 19. 分散型バージョン管理 • 非集中型サーバー • ユーザー同士が「push」と「pull」命令でデータ交換できる • 全ユーザーがプロジェクト履歴のフルコピーを持つ事が可能 • 主にソースコード管理に有益で、アセットデータの全体サイ ズは 全ユーザーにコピーを持たすことを困難にする • 解決方法はあるが、実現するには集中型サーバーを 使用する必要がある 19
- 20. ストレージの信頼性 • 信頼性は非常に重要 • データは決して消失してはならない • たとえユーザーが何か削除したいと言ったとしても… • 沈黙のデータ破損は実に問題 • RAMは宇宙線(Cosmic Rays)の影響で一月毎に256MB毎約1ビットがフリップされる（IBM調べ ） • ECC RAMはこのリスクを著しく軽減 • HDDは"ビットロット"に苦しむ • 様々な沈黙のデータ破損を、時間と共に引き起こすという問題を示す表現 • ZFSやBTRFSといったファイルシステム、幾つかのバージョン管理システムはエラーの感知・ 自動修復するために定期的にスキャンする 20
- 21. ストレージの信頼性 • ダウン時間は最小にするべき • 5分（コーヒー飲みに行って帰ってくる時間）以内が望ましい • 最悪の場合でも何らかの形でユーザの作業が続けられるようにしましょ う • 冗長性とバックアップは重要です 21
- 22. データ転送 • 帯域幅は通常パフォーマンスの大きなリミッタ • より多くのユーザー用トラフィックを扱わなければいけない 要素は注意深く考慮する必要あり • 予期しない場所でのボトルネックに警戒しよう （例：配置あるいは設定が不適切なスイッチ） • 帯域幅は特にアウトソーシングする際はよりパフォーマンスに制限がかかる • ネットワーク上の他のアプリケーションも警戒しよう • まず共通のユーザーケースを最適化しよう 22
- 23. メタデータ • 「データについてのデータ」 • 基本的なファイルデータ – （修正日時、ユーザー名等） • アセット特有の統計データ – （タグ、サムネイル、テクスチャサイズ、ポリゴン 数等） • マネジメントデータ – （承認ステータス、詳細スケジュール等） 23
- 24. ゲーム業界と映像業界の違い • データ量 • 「ショット」ベースのワークフロー • 非インタラクティブ、リニアメディア • プレビュー手法 • 最適化 24
- 25. 25 パイプラインの理論
- 26. ワークフローの確認 • 含まれるアクターの確認 〜それらは人間あるいは自動化処理か • データがどこに置かれるべきか • イテレーション（作ったデータの変更）は要注 意です • 特に他の作業の結果も変更しないといけない場所 26
- 28. イテレーション高速化の持続 28 作業処理さらに作業 処理レビュー 非常に効率が悪い！
- 29. イテレーション高速化の持続 29 作業処理レビュー さらに作業処理レビュー
- 30. データレイアウト • 可逆フォーマットをできる限り使い、 ソースデータが編集可能かを確認しよう • ソースデータと中間データと最終データを分けよう • 実用的な命名規則を使おう • ストレージを適切に分離しよう • 誰が何を必要かを意識しよう 30
- 31. ディペンデンシー（依存関係） ディペンデンシーとは何か？ メッシュ変換ツールテクスチャ圧縮ツール 31 TGAテクスチャ TGAテクスチャ メッシュ TGAテクスチャ メッシュ変換テクスチャ圧縮 中間メッシュデータ DDSテクスチャ
- 32. ディペンデンシー（依存関係） ①ワークフローディペンデンシー Xは処理を完了するためにYを必要とする （例：リギングはアニメーションつける前に必要） • 時系列と再加工の必要性を表す • 暗黙のディペンデンシーに注意しよう 32
- 33. ディペンデンシーとは何か？ ②ユースディペンデンシー Xを使用するためにはYが必要 （例：このメッシュを表示するにはこのテクスチャーが必要） • 何らかの処理（あるいはゲーム自体）を実行す るために依存するアセットの必要性を表す 33
- 34. ディペンデンシーとは何か？ ③ツールディペンデンシー XはYを使ってビルドする （例：全コリジョンデータはこのEXEを使用してビルドされる） • ワークフローディペンデンシーの特別なケース • もしツールが変更されたら、再実行する必要がある依存を表 す • （これはよくかなり骨の折れる作業） 34
- 35. ディペンデンシーの図（一部） メッシュ変換ツールテクスチャ圧縮ツール TGAテクスチャ TGAテクスチャ 35 メッシュ TGAテクスチャ ワークフローディペンデンシー メッシュ変換テクスチャ圧縮 中間メッシュデータ ツールディペンデンシー ワークフロー ディペンデンシー ワークフロー ディペンデンシー ツールディペンデンシー ワークフロー ディペンデンシー DDSテクスチャ ユース ディペンデンシー
- 36. ディペンデンシーの使用 • make、JAMやMSBuildといったツールは「与えられたアウトプットをビルドするために 必要なものは何か」を決めるためにこのツリーを走査している • ビルド「ルール」は望んだアウトプットを得るために連鎖させることが可能 １）TGAから実機用テクスチャフォーマットにコンパイルするルール ２）PSDファイルをTGAに変換するルール ３）TGAからフォントデータをコンパイルするルール • これら3つのルールは、TGAを実機用テクスチャにコンパイルするだけでなく、 自動的にPSDをテクスチャファイル（ルール１とルール２）あるいは フォント（ルール２とルール3）にコンパイルすることを可能にする 36
- 37. ディペンデンシー情報の抽出 • ルールその物に書いてある情報 – 例：コリジョンデータのコンパイルは コリジョンデータコンパイラEXEに依存する • データ自体から抽出する – 例：このモデルは3つのテクスチャを使用している • 手作業で作成 – 例：あるレベルのオーディオバンクのリスト 37
- 38. 38 パイプラインの実用性
- 39. ビルドツール • すべてを自動化する • 共通タスクをバッチ処理するためのスクリプトを作成する （例：バージョン管理からの更新、全アセットのリビルド、コード のビルド等） • もしビルドサーバーあるいはビルドファームがあれば、 ウェブベースのUIは多人数のユーザーに機能を伝える良い 手段 • 自動アップデートツール 39
- 40. 堅牢性 • たとえ不正なデータが与えられたとしてもツールはクラッシュすべ きではない • 継続する手段が全く存在しない場合以外は、エラーは非致命的であ るべき • ビルドツールはクラッシュをキャッチすべきで、中断するのでなく クラッシュをデータエラーとして扱うべき • OSのクラッシュレポートダイアログ機能をOFFにするのを忘れずに。 • さもないとクラッシュする度にダイアログが表示されて、手動で閉 じない限りビルドが継続しない状況に！ 40
- 41. エラーレポート • エラーレポートの機能をユーザーにわかりやすく提供す る • ログファイルは取り続ける • 計量データとクラッシュレポートは自動的に送る 〜ユーザーは単に彼らの仕事を進めたい • パイプラインのできるだけ早い段階でエラーレポートし よう 41
- 42. キャッシング • 冗長な処理を回避する • キャッシングは以前のビルドアセットを 再利用でき処理の遅延を避ける事が可能 • キャッシングは帯域幅の要求も また減らすことが可能 42
- 43. 効果的にデータをキャッシュする方法 • 入力セットと共に、決定した処理として各ビルドステップを取り扱う • 入力データのハッシュを生成する • 例：SHA-1アルゴリズムは160ビットのハッシュを生成する • SHA-1はセキュリティが必要な機能にはおすすめできないが、 SHA-1のコリジョン（違うデータが同じハッシュになるケース）はいまだ見つかってい ない • 複数のハッシュ結果を元に、更にハッシュを生成することも可能 • （そのアイデアを考えるだけでどん引きしている数学者には申し訳ないです！） • ハッシュを使ってインデックス化した結果を格納しよう （シンプルな共有フォルダは多くの目的に十分適合するでしょう） • ヘッダの"ビルド時間"あるいは"ユーザー名"といった不要なデータ、 あるいは初期化されていない値によってハッシュが変わることに注意しよう 43
- 44. UIデザイン • オーディエンス（ユーザー）のためのユーザーインターフェース を調整する • ツールの内部構造ではなくユーザーのワークフローを意識しよう • 多様なUIモードはいくつかのタイプのツールに有益かも • 分離したオプションより「目的」を選択できるプリセットがよい • できる限りUIは一貫性を保とう 44
- 45. テストとリリース • リリースする前にテストをしよう（！） • 「ベータ版」と「安定版」ブランチにリリースを分割しよう • データフォーマット変更に伴うリリース更新前に、ビルドサーバ ーやテスト環境を使って、新しい形式のデータを出来るだけキャ ッシュに入れよう • バグデータベースを設置しよう （可能ならユーザーが気軽にバグレポートできる仕組みを提供し よう） 45
- 46. 処理のスケーリング ビルドサーバー • コードあるいはデータをビルドするための専用マシン • 一般的に1つのマシンが最初から最後まで全体の処理を実行する • パイプラインとして無人ビルド処理を可能にする • GUIあるいはダイアログボックスを引き起こすすべての要素に注意す る （特にエラーメッセージ！） • 「継続的インテグレーション」とは変更されたら自動的にビルドが走る ことを表す 46
- 47. 処理のスケーリング ビルドファーム • 多数のマシン（"ノード"とも呼ばれる） • 1マシンがビルドプロセスの全体を制御し、各タスクは他の全マシンに分配され る • ビルドプロセス自体ではないが、時間節約のためOSやソフトウェアの設定/ 更新は自動化しておくべき • XenのようなHypervisorベースの仮想マシンのセットアップは システムイメージの開発やリソース管理を容易にする • 各ユーザーのマシンですらもノードして動作可能（夜中等マシンを使っていない 時） 47
- 48. クラウドコンピューティング • サードパーティによって運営されているレンタル可能なバーチャルマシ ンサーバー • 一般的にウェブインターフェースを通して管理する （管理の自動化のためのSDKと共に） • 仮想的に無限のコンピューティング能力を柔軟に提供可能 • しかしながら、ローカルインターネットの帯域幅が大きな制限になりう る • セキュリティと法律上の問題をケアする必要あり 48
- 49. まとめ • 様々な経験から搾り出された貴重な アセットパイプラインのガイドラインの共有 • 本質的なパイプラインは10年経っても変わらない • 新しい動きや技術には柔軟に対応する必要あり • 更なる詳細 – Production Pipeline Fundamentals for Film and Games – （仮）ゲーム･映像製作パイプライン構築マニュアル – Facebookグループ～海外TA勉強会 49
- 50. QA • 質問はございますか？ 50
Editor's Notes
- これは簡単なメッシュのディペンデンシーの図です。 たいていのビルドツールは内部でこのような「ディペンデンシーツリー」を使っています。 変更したファイルからツリーをたどれば、その変更によって必要な処理（しょり）が全部順番にリストアップ出来る。
- 自作でも第三者のでも、ツールにはいくつかの「あればすごく便利」のような機能があります。 まずは、出来るだけすべてを自動化した方が効率がいいです。ベストなのは、Maya上でファイルを保存するだけで自動的にゲーム内のメッシュでも見えることです。後ワンクリックが必要なのはそんなに悪くはないです。ツークリックはべつにいいかも。でも手順を増やせば増やすほど時間がかかって、ミスの可能性が高くなる。 同じように理想としては「ワンリックでゲームディスクが出きる」全体ビルドです。前働いていた会社ではそのためにDVDを焼けるロボットまで買いました！ウェブページでバージョンを選択してクリックすれば、数分後「ディスクが出来た」というメールが来て、後はロボットのところにいけば自分の名前が印刷してあるディスクが待っている。ファイナル期間中に無駄な時間とストレスがかなり減りました（へりました）！ ツールの自動アップデートもすごく便利な機能です。ユーザにとって手間が減る（へる）し、ツールを作っている側も「古いバージョンからのバグ報告」などもなくなります。 一般ユーザ向けなアプリなら作るのは割と面倒くさいですが、社内のシステムなら自動アップデートは特に複雑じゃなくてもいいです。一つの簡単な方法は単純にツールをバーション管理システムにいれて、batch fileでツールの実行の前にバーション管理のフォルダーアップデートを実行する事です。バーション管理システムを使えば、いざとなると簡単に前のバージョンに戻す事もできる。