【CEDEC2016】REエンジンで採用されているアセット変換の仕組みとキャッシュ共有について

RE ENGINEで採用されている アセット変換の仕組みと キャッシュ共有について 株式会社カプコン 是松 匡亮

資料配布の予定 • 明日中にCEDiLで公開される予定です • スライドの撮影はルールをお守りください • 皆様のご理解とご協力をお願いいたします 2

おことわり • 「アセット変換」と銘打っておりますが、 本セッションでは「リソース変換」としています – お伝えする内容に変更はありません • RE ENGINE開発チームを代表してお話します

自己紹介 • 是松 匡亮(これまつ まさあき) – 技術研究開発部 プログラマー • 業務内容 – 内製エンジンの開発と採用タイトルのサポート • CEDEC2015でもRE ENGINEについて講演 – 「いまどきのゲーム制作環境：エディター群とそのバックエンド、開発スタッフ 間のコミュニケーションの具体的な方法解説」 4

RE ENGINE • カプコン内製の次世代ゲームエンジン – MT FRAMEWORKからアーキテクチャを一新 • マルチプラットフォーム対応 – PS4,Xbox One,PC(Steam/UWP)… • バイオハザード7で採用 – 今後、様々なタイトルで採用予定 世代交代

これからお話すること • RE ENGINEは効率を重視した設計 – 実行効率 • 「『バイオハザード7』を実現するレンダリング技術」 – 開発効率 • 「ラピッドイテレーションを実現するゲームエンジンの設計」 • ラピッドイテレーションを実現する機能のひとつ 「バザールキャッシュ」についてお話します 6

アジェンダ • リソース変換の概要 • MT FRAMEWORK世代の取り組み – 変換時間の短縮に向けた取り組み – 再利用に向けた取り組み • RE ENGINE世代の取り組み – 再利用の実現 – バザールキャッシュ 7

リソース変換の概要 8

リソースについて • ランタイムが読み込むファイル – テクスチャ, メッシュ, シェーダーバイナリ, … • 中間データを変換することで生成

中間データの役割 • ツールが扱うファイル – シーンの構成情報, スクリプト, メッシュ, テクスチャ, マテリアル, シェーダーコード, … – e.g.) Sample.fbx • 編集に適したフォーマット – DCC等の外部ツールとの連携(fbx) – デバッグが容易 (json, dds, …) 10

中間データの問題点 • オーバーヘッドが大きい – テキストのパース(json, xml, …) – 編集用時にのみ必要となる冗長なデータの存在 • ゲーム制作中は同じファイルを何度も開く – 長いロード時間はトライ＆エラーを阻害する – 開く必要があるのは編集ツールだけ 11

リソースの役割 • ロード速度と実行効率を追求 – Swizzle化, トポロジ最適化, エンディアン変換, … – プラットフォームごとに作成 • 最適化戦略はプラットフォームによって異なる – 高速な読み込みと最小のメモリ消費 – コントロール可能な独自のバイナリフォーマット 12

リソースの変換フロー コンバーター 中間データ ランタイム リソース 13

リソースの特徴と課題 • 特徴 – 変換後の読み込みは高速 – 実行パフォーマンスにも優れる • 課題 – 中間データから変換するコストは無償ではない • 1msec～200sec – 制作中は頻繁に中間データが更新される 14

アジェンダ ✓リソース変換の概要 • MT FRAMEWORK世代の取り組み – 変換時間の短縮に向けた取り組み – 再利用に向けた取り組み • RE ENGINE世代の取り組み – 再利用の実現 – バザールキャッシュ 15

MT FRAMEWORK 変換時間の短縮に向けた取り組み 16

MT FRAMEWORKの変換方法(1/2) • ランタイム上にコンバーターを実装 – 編集ツールがランタイムに統合されているため 17

MT FRAMEWORKの変換方法(2/2) • 特徴 – 変換コードの実装とメンテナンスが容易 – 低い学習コスト 問題点 – 変換のスループットが 開発機の性能に縛られる 18

問題点の解消に向けて • 変換に時間を要するのは 大幅な最適化を要求されるリソース – テクスチャ, メッシュ, モーション, シェーダー, … • これらの種類だけでも高速化できれば 全体として大きな時間の短縮に繋がる 19

改善された変換方法 • 「Remote Resource Convert」 – PCで動作するコンバーターが 全プラットフォーム向けに変換 – 対応しているリソースは限定 – ネットワーク上のPCに分散させることも可能 • 変換待ち時間の大幅な短縮 20

Remote Resource Convertの限界 • あくまでも変換時間を短縮するための機能 – 編集や更新がかかるとコンバートが必要 – データフォーマット変更時もコンバートが必要 • 別のアプローチが必要 – あるリソースを変換して得られる結果は同じ – すでに変換されているものを共有する 21

MT FRAMEWORK 再利用に向けた取り組み 22

深夜変換の導入 • 深夜に変換PCで作成した結果をNASで共有 – タイトル開発メンバーはbatでNASからrobocopy – 細かいやり方は異なるが複数のタイトルで運用 • 一定の成果は見られた – 入ったことのないステージに入るケース – あまり更新されない中間データを参照するケース 23

深夜変換のフロー NAS 変換PC Repository 22:00～09:00 A B C 09:30～ 24

深夜変換の問題点 日中の中間データ更新に対応できない – 安易に中間データを取得するとコンバート地獄 コンバーターの更新に対応できない – 次の深夜コンバートを待たなければならない 変換の要否判定を誤判定する – MT FRAMEWORKの設計に起因する制限 25

変換が必要とされる条件 • リソースが存在しない • リソースのバージョンが一致しない – 最適化や機能追加に伴うフォーマットの変更 • 中間データとリソースの不一致 – 編集、サーバーから中間データを取得 if( !exists(nativepath) ) { // コンバートが必要 } if( stream.readInt() != DataVersion ) { // コンバートが必要 } if( 不一致を検出するコード ) { // コンバートが必要 } 26

一致の検出方法 • ファイルのタイムスタンプによる判定 – 変換の完了時にリソースの作成日時を 中間データの更新日時で上書き – 中間の更新日時とリソースの作成日時を比較 他の場所からコピーしてくると問題が発生 – 中間データの更新日時は「VCSから取得した日時」 – コピー元と同タイミングで取得することは困難 27

タイムスタンプ比較の誤検出 Repository A 08/24 10:00 08/24 10:02 08/24 10:00 08/24 10:02 B 28

ファイルハッシュ値の検討 • タイムスタンプによる比較よりも正確 – 日時が異なっていても同一内容ならば変化なし – 日時が同一でも内容が異なれば別のハッシュ値 • 課題 ファイル全体のハッシュ値計算は遅い • ハッシュ値をキャッシュしておく機構が必要 キャッシュを破棄するタイミングが掴めない • ファイル書き換えを監視する機構も必要 29

アジェンダ ✓リソース変換の概要 ✓MT FRAMEWORK世代の取り組み ✓変換時間の短縮に向けた取り組み ✓再利用に向けた取り組み • RE ENGINE世代の取り組み – 再利用の実現 – バザールキャッシュ 30

RE ENGINE MT FRAMEWORKから変わった点 31

アセットの概念を導入 • アセット – 中間データとメタデータのファイルで構成 – メタデータに付加的な情報を保存 – アセットを変換したものがリソースになる Sample.fbx Asset Sample.fbx.meta アセットの編集者名 タグ 中間データの編集日時 アセットの内包関係 …

アセットの内包関係 Texture PatternAnimation 変換 width, height 変換 • 相手の状態によって自身の状態が変化 – 相手が変換されると自身も再変換

ファイルハッシュの課題解決方法 • アセット管理システムが変更を監視 – 中間データの登録や書き換えを検出して計算 • System.IO.FileSystemWatcherによる監視 – メタデータにMD5ハッシュ値を保存 • 起動していない間のファイル書き換え – メタデータに記録されている更新日時と 中間データの更新日時を比較 34

一致の検出方法 • ファイルハッシュ値の比較 – 中間データのハッシュ値はメタデータに格納 – リソースのどこにハッシュ値を埋めるか？ • ファイル先頭 or 終端？ • いずれにせよランタイム側に負担が生じる • ファイルのタイムスタンプ領域を活用 – ランタイムのロード時に追加コストなし

リソースに埋め込むMD5 • メタデータには中間データのMD5が格納 – これだけでは一致性のテストは不可能 • 以下のケースを考慮したMD5が必要 – 内包先のアセットが編集されているケース – コンバート時のパラメータが異なるケース 36

内包関係を考慮したMD5 • シナリオ – マテリアルから参照するシェーダーパラメータは シェーダーで定義されている – シェーダーが編集されていれば再変換が必要 • 計算方法 md5.TransformBlock( materialAsset.MD5 ); foreach(var asset in materialAsset.IncludeAssets) { md5.TransformBlock( asset.MD5 ); } var materialNativeMD5 = md5.Hash; 37

パラメータを考慮したMD5 • シナリオ – テクスチャには圧縮レベルのパラメータが存在 – パラメータが変化した場合はリソースが変化 • 計算方法 md5.TransformBlock( materialAsset.MD5 ); foreach(var parameter in materialAsset.ConvertParameters) { md5.TransformBlock( Encoding.UTF8.GetBytes(parameter) ); } var materialNativeMD5 = md5.Hash; 38

RE ENGINEの変換方式 • すべてが「Remote Resource Convert」 – 編集ツールとランタイムのプロセスが分離

RE ENGINE 再利用の実現

共有の方針 • 変換用のPCで変換した結果をNAS上にコピー • コンバーターを動かす前にキャッシュをクエリ – あればファイルをコピー、なければコンバート – コンバート時間をファイルコピーの時間に置き換え 41

キャッシュ共有のフロー Repository A NAS 変換PC B C 42

キャッシュ共有の実装 • リソースのMD5ハッシュをファイル名に – “リソースの MD5ハッシュ.拡張子.バージョン” • e.g.) “0A38004D25B6925D47AB47BBEFD6B40D.mesh.5” • クエリ方法はファイルの存在チェック – “\\NAS\リソースのMD5ハッシュ.拡張子.バージョン” – 取得後に本来のリソース名にリネーム

深夜変換との対比 日中の中間データ更新 – コミット時に変換PCを駆動 コンバーターの更新 – リソースを全変換 変換の要否を誤判定 – ハッシュ比較によって誤判定は発生しない 44

キャッシュ共有の限界 コンバートが追いつかなくなってきた – 変換マシンは3台しか用意していなかった – ほとんど自分で変換をする状態に コンバーター更新の一括変換も間に合わない – 数万アセットの変換は一晩かけても終わらない 全リビジョンが変換されるわけではない – 変換できる状態になった時点の最新版が変換 45

大聖堂とバザール バザールキャッシュ 46

これまでの振り返り • 中間データをリソースに変換 – ロード速度と実行速度の改善 • 変換時間がイテレーション速度を律速 – Remote Resource Convert – 深夜変換 – キャッシュ共有 47

キャッシュ共有の理想 • 自席で変換待ちをしなくても済むこと • コンバーターの更新に迅速に追従 • リビジョンの歯抜けが発生しない

バザールキャッシュ • 最初に変換された結果を全員で共有 – コンバートした結果を自動的にNASへコピー • みんなで変換した結果を 持ち寄って共有する Photo by Dan Lundberg - 20141003_Uzbekistan_0840 Tashkent(2014) / CC BY-SA 2.0

• https://www.flickr.com/photos/9508280@N07/16257413122/in/photolist-qLBuwf-pPGcVb-qLBu6f-qLFNmD-pPFJpu-qufS7n-quezog-aHK7sR-aHK8W4-qJoMKW-qLwnqa-pPERow-pPFNQo
• https://creativecommons.org/licenses/by-sa/2.0/

バザールキャッシュのフロー Repository A NAS B C 50

理想へ近づいた形に コンバートが追いつかないことは稀 – 誰かが先にコンバートしてくれていることが多い – RE ENGINEを利用する全てのPCが演算資源 コンバーターを更新した場合は自動的に追従 – 誰かが新コンバーターで変換すれば共有される ほぼ全てのリビジョンが変換される – 誰かが先に取得していれば共有される 51

デモ 52

運用上の課題と解決 • エンジンの開発者はコンバータを書き換える – 開発途中の不正なリソースが共有される • RE ENGINEはexeやdllを署名で区別 – 開発者ビルドではキャッシュの取得のみ – 配布ビルドではキャッシュの取得と送信を行う

インフラに対する課題 • NASに対する負荷が高くなりがち – 現在のところは問題となっていない 今後のタイトル数拡大に追従できない可能性 • NASがダウンするとすべて自力で変換 – システムとしてはあまりにも脆弱 • P2Pによる共有を検証中

アジェンダ ✓リソース変換の概要 ✓MT FRAMEWORK世代の取り組み ✓変換時間の短縮に向けた取り組み ✓再利用に向けた取り組み • RE ENGINE世代の取り組み ✓再利用の実現 ✓バザールキャッシュ 55

『バイオハザード7 ティザー ～ビギニングアワー～』 実働タイトルにおける成果 56

チーム全体 • クエリ数 – 12,279,694 • ヒット数 2 9% – 11,204,053 • 浮いたコンバート時間 1 91% – 11,555時間 ≒ 72人月 57

無作為に抽出したユーザー • クエリ数 2 0.17% – 8,788 • ヒット数 – 8,773 • 浮いたコンバート時間 1 99.83% – 1.1時間(コピーは8分で完了) 58

まとめ 59

まとめ • リソースの共有は可能 – 実働タイトルで90%以上のヒット率を維持 • アセットを適切に管理することが重要 – 依存関係を静的に確定させてハッシュを計算 • 日中でも気兼ねなく中間データの取得が可能 – イテレーションサイクルの効率化に貢献 60

ご清聴ありがとうございました 本日の関連セッション 8/25 16:30～17:30 「バイオハザード7 レジデント イービル」における アニメーション技術について この資料に記載されている会社、製品等の名称は一般に各社の商標または登録商標です。 なお、本文および図表には や®を明記しておりません。 61

ご質問はございますか？ • アジェンダ(再掲) – リソース変換の概要 – MT FRAMEWORK世代の取り組み • 変換時間の短縮に向けた取り組み • 再利用に向けた取り組み – RE ENGINE世代の取り組み • 再利用の実現 • バザールキャッシュ 62

附録

リソース管理としてのVCSの検討 • 中間データの取得に時間がかかる – テクスチャやメッシュはファイルサイズがそのまま – ディスク容量の圧迫にも繋がる • コンバーター変更時にコンフリクトが多発 • 解決すべき課題が多く存在したため見送り 64