お世話になります。仮想アセットの利用条件やデータの流れについて伺います。
【質問１】
https://dev.epicgames.com/documentation/ja\-jp/unreal\-engine/overview\-of\-virtual\-assets\-in\-unreal\-engine
こちらの「仮想アセットの仕組み」の説明では、
仮想化によってアセットが、「コアアセットメタデータ」（Perforceに格納）と「バルクデータ」（共有DDCに格納）に分かれるとあります。
その後の説明「仮想アセットのデプロイ方法」には、
「仮想化されたペイロードが格納されるのは、プロジェクトの「Saved」ディレクトリの「VirtualizedPayloads」サブディレクトリです。」
と、「コアアセット」とも「バルクデータ」とも異なる「ペイロード」という言葉が出てきて、
格納場所もPerforce（Contentフォルダ）ともDDCフォルダとも異なるSavedのサブディレクトリになっています。
ペイロードとコアアセットおよびバルクデータとの関係を詳しく説明いただけますか。
【質問２】
仮想化アセットを使う設定にしたクライアントからアセットをコミットした場合、
「コアアセットメタデータ」がPerforceのサブミットで格納されるもので、
「同時に共有DDCにバルクデータがアップロードされる」のでしょうか？
（「ペイロード」はその工程にかかわりますか？）
【質問３】
クライアントでのコアのサブミットに合わせて共有DDCにバルクがアップされる場合、
それはつまり作業者のクライアントから共有DDCを書き換えられるようにしなければならない、
という理解でいいでしょうか
（共有DDCの運用をサーバーから集中してアップロードするだけにはできない）
【質問４】
プラグインのコンテンツのように、エディタ外での作業でソースと一緒にコミットするようなケースで、
アセットの仮想化はどのように行えるでしょうか。
【質問５】
仮想化アセットを使うには共有DDCが必要とありますが、
共有DDCは従来のファイルシステムタイプでも新しいZenタイプでもどちらでも良いでしょうか。
以上、よろしくお願いします。
お世話になっております。
質問1
ペイロードは仮想アセットの実データと考えてください。ソース管理（Perforceなど）にも格納されますが、仮想化アクセスのためにDDC（例：CloudDDC）にもチェックインされます。エディタでメタデータを使ってアセットにアクセスする際は、まずDDCを参照し、見つからなければPerforceから取得します。
質問2
エディタ外でPerforceを使ってコミットする場合は、自動でDDCへの反映は行われません。ただしスクリプトで自動化できます。エディタからコミットした場合は、Unrealが自動で処理してくれます。
質問3
はい、その理解で正しいです。作業クライアントが直接共有DDCに書き込む必要があります。
質問4
自動化が必要になります。こちらのドキュメントが参考になります：https://dev.epicgames.com/documentation/ja-jp/unreal-engine/backend-graphs-for-virtual-assets-in-unreal-engine
質問5
基本的にCloudDDCなどのクラウド型DDCを前提としています。ローカルDDCでの利用については明確なリンクはなく、機能としては分かれていると考えてください。
よろしくお願いします。
回答ありがとうございます。１つ確認させてください。
>基本的にCloudDDCなどのクラウド型DDCを前提としています。ローカルDDCでの利用については明確なリンクはなく、機能としては分かれていると考えてください。
DDCの設定の
Shared=(Type=FileSystem, での利用はできない、という理解でいいのでしょうか？
（これはクラウドでもローカルでもないと思います）
以上、よろしくお願いします。
お世話になっております。
その通りです。
FileSystemタイプのDDCは別の機能になります！
お手数ですが、よろしくお願いします。
お世話になります。
こちらの質問の仕方が悪く意図が伝わってないかもしれませんので、何のためもう一度確認させてください。
仮想アセットと共有DDC（Shared=(Type=FileSystemを含む）が別の機能であることは承知しています。
そのうえで、確認ですが。
仮想アセットを運用するには、「共有DDC」の利用が必要とあります。
「共有DDC」と呼べるものにもいくつかの構成パターンがあると思いますが、
従来のファイルシステム共有による共有DDCについては、仮想アセットで必要とされる共有DDCに含まれない、
つまりShared=(Type=FileSystemでは、仮想アセットを利用できない、という理解で良いでしょうか。
一方Zenでは、仮想アセットが対応する共有DDCについて、
Zenのクラウド版と共有DDC版（LANで使えるもの）の二つが使えますか？（Zenのローカルは無理として）
それともZenのクラウドだけでしょうか？
以上、よろしくお願いします。
お世話になっております。
仮想アセットシステム自体は、プロジェクトのDDCがどのように設定されているかを気にすることはなく、単にDDC2 APIキャッシュとアクセスデータを使用するだけです。
チームの観点から見ると、多くの要因に依存するため、一律の答えを出すのは難しく、これはあらゆる仮想アセットのバックエンドやDDCの設定に共通して言えることであり、古い形式のDDCセットアップに特有の話ではありません。
仮想アセットDDCバックエンドをキャッシュストレージとして使用することを前提にすると、その利用理由は二つあります。
一つ目はローカルキャッシュで、最近アクセスしたペイロードをユーザーのマシン上にキャッシュして再利用できるようにするためです。例えば、ユーザーがテクスチャのUPROPERTYを編集している場合、次にPIEを実行したりCookを行ったりする際に、そのテクスチャのペイロードが必要になる可能性が高いです。
二つ目は共有キャッシュで、頻繁にアクセスされるペイロードデータを、永続的なデータストレージよりも高速にアクセスできる場所に保存するためです。
例えば、我々のプロジェクトの場合、過負荷状態のPerforceサーバーからダウンロードするよりも、HordeStorageからペイロードを取得する方がはるかに高速であるため、最初の回答をした理由もそこにあります。
誤解を招く結論になってしまい申し訳ありません。
結局のところ、必要に応じて選ぶことになります。例えば、単一拠点のチームでオンサイトのPerforceサーバーを使い、共有DDCが古い形式のネットワークファイル共有である場合、仮想アセットDDCバックエンドを利用することで本当に性能改善が得られるかどうかをプロファイルして確認するといいと思います。
お手数ですが、よろしくいお願いします。
回答ありがとうございます。
おかげさまで私の理解が深まったと思います。
ただまだ私の方で理解できていない、誤解していそうな点があり、
次のような疑問を持ちましたので、確認させてください。
＜確認点１＞
キャッシュのレイヤーに何を採用するかに自由度があるとすると、
実際に性能が改善するかどうかはともかく、
個人毎にローカルZenが動いているだけの環境であっても、
仮想アセットを使うこともできるのでしょうか？
＜確認点２＞
確認点１の通りのとき、PerforceによるContent更新をしてもメタデータのみが取得される
そして実際にエディタ上で使うときにバルクデータ（ペイロード）が（共有したDDC上にはないため）、
Perforceから自動的に追加で取得される、ということになりますか？
＜確認点３＞
またそもそもですが、UE（エディタ）の外部で、P4Vを使うなどしてプロジェクト全体を更新させる場合、
それはつまりPerforce上の永続的なバルクデータまでも取得することになるので、
仮想アセットを使っている意味がないことになりますか？
永続的なバルクデータはプロジェクトのどこに保存されますか？
（それとも永続的なバルクデータがPerforce上に入らない、という動作があり得るのでしょうか？）
以上、よろしくお願いします。
お世話になっております。
1.
はい、利用可能です。ただし前提として、ここで想定しているのは DDC (Derived Data Cache) をキャッシュ用途でのみ利用するケースです。DDC は永続的なストレージ用途には向かず、多くの実装では容量管理のためにファイルが削除されることがあります。そのため、DDC はあくまでキャッシュ専用であり、永続保存には利用すべきではありません。
2.
この点については少し誤解があるかもしれません。私たちの実装は VFS (Virtual File System) 型ではなく、エディタがパッケージを部分的に同期し、必要に応じて残りを同期するといった仕組みではありません。
代わりに、非構造化データ（バルクデータ）は通常のプロジェクト同期とは異なる専用の場所に保存されるため、ユーザーが誤ってそのデータを同期してしまう心配はありません。
3.
通常のユーザーがプロジェクトを同期しても、ペイロードデータは専用の別デポに格納されているため、自動的に取得されることはありません。
具体的には次のような構成になっています：
//Game1/Main/…
//Game1/Release00/…
//Game1/Release01/…
//Game2/Main/…
//Game2/Release00/…
//Game2/Release01/…
//Payloads/Game1/…
//Payloads/Game2/…
このように、Game1 や Game2 のすべてのブランチのペイロードが //Payloads/ という専用のデポにまとめられています。
したがって、通常ユーザーが
//Game1/Main
を同期しても、
//Payloads/Game1/
内のデータを誤って取得することはありません。
ペイロードデータは 通常のゲーム用デポとは切り離された専用のデポに保存されます。
一部の会社では仮想化データを同じデポ内に置きたがるケースもありますが、その場合は構成がやや複雑になります。例えば以下のような形です：
//Game1/Main/…
//Game1/Payloads/…
//Game1/Release00/…
//Game1/Release01/…
//Game2/Main/…
//Game2/Payloads/…
//Game2/Release00/…
//Game2/Release01/…
このように整理すれば、必要に応じて同一デポ内にペイロードを保持することも可能です。ただし、運用上の理由や要件によって最適解は変わるため、ケースバイケースでの設計が求められます。
お世話になります。
詳しく解説ありがとうございます。仮想アセットについて理解が進みました。
本件はここで終了いただいて大丈夫です。
以上、よろしくお願いします。