Unreal Engine 5.1 の仮想アセット — より小さく、より高速化したデータ同期
2022年12月12日
先日リリースされた Unreal Engine 5.1 には、より高速で、より小さなデータ同期が可能になる新機能、仮想アセットが搭載されました。
現在ベータ版の仮想アセットではバルク データから構造化されたデータを分離する方法が提供され、デベロッパーは Perforce などのソース コントロール システムから必要なもののみを同期できるようになります。これにより、オブジェクト データ全体にアクセスする必要のないデベロッパーは、より小さなワークスペースで、より高速な同期が可能になります。
この技術ブログでは、Unreal Engine チームのシニア プロダクト マネージャーである Grace Yen 氏と、仮想アセットのリード デベロッパーである Paul Chipchase 氏が仮想アセットについて詳しく説明します。みなさんのプロジェクトに適しているかどうかをご検討ください。
また、アップデートの配信方法を進化させ続けているチームもありました。一部のチームでは、ビルドが安定してリリースの準備が整うまで、開発中の最新機能が残りのチームに影響を与えないようにする「機能ストリーミング」を選択しています。
一部のチーム メンバーは、(ライブ サービスをサポートするために) 製品のリリース間に作業しながら、「メイン」タイプの開発ワークストリームと「高度」なタイプの開発ワークストリームを持つモデル間での作業も行っていました。
これは別の課題を提起しています。チーム メンバーは SSD の空き容量が足りなくなる寸前のことが多く、現在行っている作業のために容量を空けなければならないせいで、またすぐに必要になる可能性が高いワークストリームの同期を解除するという無駄な決断を行わなければならない場合があります。
パンデミックが発生する前、一部のスタジオ (当社も含みます) では同期の規模と時間に関する課題を経験しました。そこで、Performance Edge サーバーなどのソリューションをデプロイし、ユーザーにより高速なアクセス ポイントを提供しようとしました。しかし、2020 年に自宅から作業する必要が出たとき、チーム メンバーには信頼できるインターネット接続がなかったり、まったく異なるインターネット速度だったりするという痛みを経験し始めました。
最高のチームをまとめるということは、チーム メンバーが各地に散らばっていることを意味する場合もあります。私たちは、そのダイナミックさがここにあると考えます。たとえば、チーム メンバーが 2 か所に分かれて時間を過ごすというハイブリッドなシナリオの場合にも、その場所で割り当てられたハードウェアに何度も同期する必要があるという面倒な問題が発生する可能性があります。
ピクセル スケールの詳細と大量のオブジェクト数を実現するように設計されている UE5 の仮想化ジオメトリ システムである Nanite などの強力な技術により、プロジェクトの規模は今後さらに大きくなることが予測されます。
現在ベータ版の仮想アセットではバルク データから構造化されたデータを分離する方法が提供され、デベロッパーは Perforce などのソース コントロール システムから必要なもののみを同期できるようになります。これにより、オブジェクト データ全体にアクセスする必要のないデベロッパーは、より小さなワークスペースで、より高速な同期が可能になります。
この技術ブログでは、Unreal Engine チームのシニア プロダクト マネージャーである Grace Yen 氏と、仮想アセットのリード デベロッパーである Paul Chipchase 氏が仮想アセットについて詳しく説明します。みなさんのプロジェクトに適しているかどうかをご検討ください。
仮想アセットが解決する問題について
この何世代かのゲーム開発では、プロジェクトの規模に関連するいくつかの興味深いデータ傾向がありました。プロジェクトの規模が大きくなっただけでなく (このことを検証するため、非公式に一部のライセンシーで調査を行いました)、多くのデベロッパーが サービスとしてのゲーム (GaaS) モデルに移行し、複数年に渡るゲームのライフサイクルを通して継続的にアップデートを行っています。また、アップデートの配信方法を進化させ続けているチームもありました。一部のチームでは、ビルドが安定してリリースの準備が整うまで、開発中の最新機能が残りのチームに影響を与えないようにする「機能ストリーミング」を選択しています。
一部のチーム メンバーは、(ライブ サービスをサポートするために) 製品のリリース間に作業しながら、「メイン」タイプの開発ワークストリームと「高度」なタイプの開発ワークストリームを持つモデル間での作業も行っていました。
これは別の課題を提起しています。チーム メンバーは SSD の空き容量が足りなくなる寸前のことが多く、現在行っている作業のために容量を空けなければならないせいで、またすぐに必要になる可能性が高いワークストリームの同期を解除するという無駄な決断を行わなければならない場合があります。
パンデミックが発生する前、一部のスタジオ (当社も含みます) では同期の規模と時間に関する課題を経験しました。そこで、Performance Edge サーバーなどのソリューションをデプロイし、ユーザーにより高速なアクセス ポイントを提供しようとしました。しかし、2020 年に自宅から作業する必要が出たとき、チーム メンバーには信頼できるインターネット接続がなかったり、まったく異なるインターネット速度だったりするという痛みを経験し始めました。
最高のチームをまとめるということは、チーム メンバーが各地に散らばっていることを意味する場合もあります。私たちは、そのダイナミックさがここにあると考えます。たとえば、チーム メンバーが 2 か所に分かれて時間を過ごすというハイブリッドなシナリオの場合にも、その場所で割り当てられたハードウェアに何度も同期する必要があるという面倒な問題が発生する可能性があります。
ピクセル スケールの詳細と大量のオブジェクト数を実現するように設計されている UE5 の仮想化ジオメトリ システムである Nanite などの強力な技術により、プロジェクトの規模は今後さらに大きくなることが予測されます。
まとめると、ユーザーが同期に費やす時間と容量はさらに増えていきます。その理由は次のとおりです。
問題が拡大している理由は、次のとおりです。
仮想アセット ソリューションは、必要なデータのみを同期し、後で必要になった追加データへのアクセスは簡単にできるようにするという基本的な考えに基づいて構築されています。
これは、チームが問題を回避してきたいくつかの方法からの転換です。チーム (当社も含みます) では、デベロッパーにダウンタイムを最小限にするための計画をしっかり立て、夜間同期を設定するように促すことが上手になりました。仮想アセットがその邪魔になることはありません。それにより、特に事前に計画を立てることができず、まだ最新の状態ではないワークストリームに緊急の問題が生じた場合に、全員のデータをより高速で、より効率的に同期する方法が提供されます。
パッケージ ファイル (.umap/.uasset) を評価したところ、ユーザーが同期しなければならないデータを削減する大きな機会を見つけました。多くの場合、ユーザーはエディタに有意義な方法でアセットを表示するために必要な情報のみを必要としています。たとえばテクスチャの場合は、サムネイルと、座標やスケールなどのエディタ プロパティが必要になるでしょう。しかし、UTexture オブジェクトのバルク データはオリジナルの生ピクセル データですから、実際には事前に必要ありません。このことに基づき、これらのアセットを実は 2 つのグループに分割しています。
- プロジェクトの規模が大きくなっている
- ゲームの寿命が延びたことにより、さらに多くのコンテンツが追加されている
問題が拡大している理由は、次のとおりです。
- 新機能のリリースやライブ サービスの管理など、チームで複数のワークストリームの同期が必要になる場合がある
- 物理ハードウェア (SSD など) はプロビジョニングにより多くのコストがかかり、難しく、時間もかかる
- チームの規模が大きくなることにより、効率的な作業が難しくなる場合がある
- ハイブリッド ワーカーとリモート ワーカーには、作業の同期という課題がある
- Nanite の活用を始めたチームは、ビジュアル忠実度が高くなるだけでなく、データ セットも大きくなる
仮想アセットに対する Epic のアプローチについて
仮想アセット ソリューションは、必要なデータのみを同期し、後で必要になった追加データへのアクセスは簡単にできるようにするという基本的な考えに基づいて構築されています。これは、チームが問題を回避してきたいくつかの方法からの転換です。チーム (当社も含みます) では、デベロッパーにダウンタイムを最小限にするための計画をしっかり立て、夜間同期を設定するように促すことが上手になりました。仮想アセットがその邪魔になることはありません。それにより、特に事前に計画を立てることができず、まだ最新の状態ではないワークストリームに緊急の問題が生じた場合に、全員のデータをより高速で、より効率的に同期する方法が提供されます。
パッケージ ファイル (.umap/.uasset) を評価したところ、ユーザーが同期しなければならないデータを削減する大きな機会を見つけました。多くの場合、ユーザーはエディタに有意義な方法でアセットを表示するために必要な情報のみを必要としています。たとえばテクスチャの場合は、サムネイルと、座標やスケールなどのエディタ プロパティが必要になるでしょう。しかし、UTexture オブジェクトのバルク データはオリジナルの生ピクセル データですから、実際には事前に必要ありません。このことに基づき、これらのアセットを実は 2 つのグループに分割しています。
- 「構造化されたデータ」は、ソース コントロール内のアセットが現在ある場所に残ります。これには、エディタがアセットをロードして表示するために必要なものがすべて含まれています
- 「バルク データ」は必要ではない可能性が高く、ソース コントロールの別の領域に分割されています
仮想アセットの開発における原則の 1 つは、ユーザーの既存のワークフローを維持することでした。チーム メンバーは同じ方法で、しかもより高速に同期と作業ができる必要があります。元のソースの場所でコア アセット メタデータを分割して残すことにより、ユーザーは以前と同じ方法でデータを同期することができます。このツールは、必要に応じて新しいソースの場所からバルク データを取得するために、裏で作業を行います。そのためには、ソース コントロール管理者と連携して、元のソース コントロールの場所と同じアクセス権限を持つ別の場所を設定する必要があります。
まとめ
チームで仮想アセットを有効にするために役立つモードがいくつかあります。
まとめ
- アセットを分割し、バルク データを別のソース コントロールの場所に保存する
- ユーザーの作業は以前と変わらないが、より小さなコア アセット メタデータの構成要素に同期する
- 取得していないバルク データが必要になる稀なケースでは、そのデータをオンデマンドで取得することができる
仮想アセットをデプロイする方法について
仮想アセット機能は現在ベータ版です。つまり、試してみる価値はありますが、形式は変更される可能性があるため、プロダクション プロジェクトでの使用には注意が必要です。しかし、フォートナイトのシーズン 22 以降のプロダクションで使用されるほど、十分に堅牢であることを強調しておきたいと思います。チームで仮想アセットを有効にするために役立つモードがいくつかあります。
プロジェクトの規模とプロダクション スケジュールに応じて、さまざまなアプローチをお試しください。たとえば、次のようなものがあります。
注意事項：
フォートナイトでは、次のような結果になりました。
- 新しいプロジェクトを開始する場合、すぐに仮想アセットを試すことをお勧めします。
- プロジェクトが完全なプロダクションに入っている場合は、ゲーム領域や何度もイテレートしているアセットにこれを取り込むことは避けた方がよいでしょう。しかし、長時間触っていないより大きなアセットのパスを実行することはできます。
- または、規模で上位のアセットをターゲットし、それらのアセットを「容易に達成できる成果」として仮想化することもできます。
注意事項：
- まだ「オフライン作業」モードは実装されていませんが、これが有益な機能であることは認識しています。これはリストで次に控えているもので、5.2 に含まれる予定です。.これは、切断中 (たとえば飛行中) も作業を行う可能性があるユーザーがいる場合、仮想アセットは現在、完全に機能しないことを意味します。編集が必要なもののバルク データを取得できない場合があります。エディタがクラッシュすることはありませんが、再接続して必要なバルク データを取得する必要があります。
- プライマリ データは分割されています。プロダクション中は問題ありませんが、既存の基礎構造の外へゲームのコンテンツ データをシッピングする予定の場合は、追加の考慮事項が発生します。この場合、スタンドアローンの UnrealVirtualizationTool を使用して、仮想化したアセットを元の形式に (バルク データをパッケージ ファイルにもう一度保存し直すことによって)「再ハイドレーション」することができます。
- この実装は、ユーザーが妥当な接続速度で共有データ キャッシュにアクセスできる場合にのみ、うまく機能します。そうではない場合、大きなヒッチが発生することになるため、同期の時間と容量をすべて事前に用意しておいた方がよい可能性があります。これについては、次のセクションで詳しく説明します。
- 現在、Perforce ソース コントロールのみをサポートしています。
- この技術は、まだベータ版です。社内ではデプロイし、現在も作業を進めていますが、仮想アセットがプロダクション対応の状態に移行する時期や、将来的に機能がサポートされる方法についての保証はありません。
仮想アセットが適しているプロジェクトについて
さまざまな要因が関係するため、仮想アセットが利益をもたらすかどうかについての明確な答えはありません。しかし、次に挙げる質問は、これが適切なソリューションかどうかを判断するのに役立つものです。また、仮想化が一方通行ではない点に留意しておくことも重要です。任意の (またはすべての) 仮想化したデータは、必要に応じていつでも再ハイドレーションすることができます。- 現在、チームにはディスク容量の問題がありますか？または、データの増大化が進み、今後そのような問題が発生することが予測されますか？
- チーム メンバーは、プロジェクトの複数のバージョンを同期する必要がありますか？また通常、バージョン間で大量のコンテンツを共有していますか？
- チーム メンバーは、適切な共有派生データ キャッシュ (DDC) にアクセスすることができますか？
- これは答えが決まっている質問でもあります。チーム メンバーのほとんどが共有 DDC にアクセスすることができ、いくつかの外れ値がある場合、プロジェクト全体で仮想アセットを使用しますが、特定のチーム メンバーを除外することができます。彼らはチェックインするときにアセットを「非仮想化」しますが、スクリプトを実行してこれを捉え、自動的に修正することができます。ただし、これにはソース コントロールのチャーンによる負荷が発生します。
仮想アセットの利点を最大化するためのヒント
- Unreal Editor のチェックイン ワークフローの使用を検討することをお勧めします。それにより、チェックイン時にアセットがまだ仮想化されているか確認するためのチェックが行われます。ただし、仮想化されたアセットを照合するために Perforce から実行できるツールがいくつか提供されていますが、ユーザーはこれをバイパスしてスキップする可能性が常にあります。
アクションでの仮想アセット
Unreal Engine でリリースする機能の多くでは、私たち自身が最初の顧客となっています。いわゆる「ドッグフードする」、つまり自社実践です。仮想アセットを内部プロジェクトやサンプル プロジェクトで使用可能にすることに加え、この機能をフォートナイトにも導入しています。次の数値は、フォートナイトで節約できた容量と時間をわかりやすくするための目的で示したものです。この効果は、ゲームを構成しているアセットの種類により異なります。たとえば、これを 『古代の谷』 で実行した場合 (これは実際のゲームを示すものではありません)、Nanite メッシュが大量に使用されているため、50 倍の節約になりました。フォートナイトでは、次のような結果になりました。
今後の展望
Unreal Engine 5.1 の仮想アセットには、次のような機能があります。- Perforce との連携
- テクスチャおよびオーディオ アセットのサポート
- アセット タイプ、パッケージ パス、またはすべてによって有効にできる、さまざまなモードの提供
- アセットのコンテンツのハッシュによって参照されるバルク データの保持
さらに、次のような仮想アセット機能も今後の視野に入れています。
- オフライン作業モード (すべてのデータを事前に同期するため)
- より多くのアセット タイプのサポート (Nanite を含むスタティックメッシュなど)
- その他のソース コントロール ソリューションに対するサポート
以上となります。この技術ブログがみなさんのお役に立つことを願っています。仮想アセットについての詳細は、ドキュメント を確認してください。
今すぐ Unreal Engine を入手しましょう！
Unreal Engine は、世界で最もオープンで高度な制作ツールです。
あらゆる機能とソース コード アクセスを完備している Unreal Engine を使用すれば、すぐに制作を開始できます。
あらゆる機能とソース コード アクセスを完備している Unreal Engine を使用すれば、すぐに制作を開始できます。