本講演の後半冒頭では、PDGを活用したキャッシュ出力処理の設計方針を決めるにあたり、PPIが直面した課題とそれに対する対応策が語られた。

まず紹介されたのは、プロジェクト全体におけるキャッシュ出力の基本構成だ。同社の多くのプロジェクトでは、キャッシュ出力はfx（エフェクト）、lgt（ライティング）、rta（Unreal Engine）の3用途に分類され、それぞれに応じた仕様が設けられている。例えばfx用キャッシュでは、Time Driverを反映したSteppedと、エフェクトシミュレーションに必要なLinearの両方を出力する必要があり、Prerollの自動生成にも対応している。

一方で、lgtおよびrtaではSteppedキャッシュのみを出力し、Prerollは不要となる。特にrtaに関しては、キャッシュ出力後に自動でTriangulateを実行するほか、一部のケースではAlembicではなくFBX形式で出力するよう求められるなど、ゲームエンジン連携特有の要件にも柔軟に対応している。

PDGによる大規模キャッシュ処理において重要となるのが、「不要な再書き出しを避ける」という発想だ。例えば1体のキャラクターの一部に変更があった場合に、ほかのキャッシュまで巻き込んで全て再出力してしまうと、データ量・作業時間・クラウドトラフィックが膨大になってしまう。

こうした課題に対し、同社では依存管理に基づいた差分パブリッシュを導入している。ショットごとのキャッシュ出力は、該当するアセット、あるいはアニメーションのRevisionが更新された場合にのみ再出力するよう管理している。さらに、Alembic書き出し設定（例：法線やサブステップの有無など）についても、ショットごとに設定値を保存・比較し、設定変更時のみ再出力が実行されるというしくみだ。

このような大量かつ複雑なキャッシュ出力処理を支えるには、確認性と可視性の確保も重要となる。そのため、PPIではキャッシュ出力後に自動でFlipbookを生成し、アーティストが即座に結果を確認できるようにしている。また、各キャッシュの内容や生成条件を記録したメタデータファイルも併せて作成し、後工程やデバッグ時の追跡性を確保している。

「結論から言うと、こういうノード構成ができました」という前置きの後にパベル氏が提示したのは、キャッシュパブリッシュのながれを整理したTOPネットワークの一例だ。紹介されたネットワークには、キャッシュ書き出しから仮データの削除にいたるまでの一連の処理が組み込まれており、PPI Deadline Schedulerと連携して自動化されている。ACMやanmCacheManifestなど、聞き慣れないノード名が多数登場する複雑な構成で、各ノードの役割はこの後に詳しく紹介された。

まずは、lgt（ライティング）とrta（Unreal Engine）のキャッシュパブリッシュフローが解説された。ライティング用のながれでは、アセットの事前処理を経てAlembicを書き出し、それをパブリッシュした上で、ACM（Asset Cache Manifest）パブリッシュ、Flipbookのレンダー、anmCacheManifestパブリッシュが行われる。一方でrtaでは、Alembicに加えてFBX形式での出力も必要になる。また、ポリゴンの削除や階層の解除といった変換処理はHoudini側で担っている。

anmCacheManifestは、ショット単位でのキャッシュ情報をまとめたUSDファイルであり、従来のようにJSONで管理していたデータ構造を、より柔軟で再利用可能なかたちへと移行させたものである。anmCacheManifestは、各ショットにどのアセットが含まれているかを示す情報を保持し、ACM（個別アセットのManifest）を参照する構造になっている。例えば、ACMファイルがLinearおよびSteppedのキャッシュをまとめ、anmCacheManifestがそれらを束ねるかたちで管理されている。

このようにUSDベースのManifest構造を採用することで、以下の利点が得られるとパベル氏は語る：

・書き出し時のLauncher Optionsや設定内容を記録できる
・キャッシュやほかのManifestまでの参照パスを管理できる
・データのネスティング（入れ子構造）に対応
・SolarisやUSD Viewでの再生・検証が容易

Cache Manifestは、単にキャッシュファイルのまとめ役にとどまらず、「いつ、どのように書き出されたか」というレシピ情報＝Launcher Optionsや書き出し設定までも保存する。これにより、たとえキャッシュファイルが失われても、設定情報さえあれば再生成が可能になる。これは、協力会社とのデータ連携において特に有効なアプローチだと言える。

続いて紹介されたのはCache Manifestの内容だ。これは、USD形式で記述されたシンプルなファイルだが、ショット内のキャッシュ構成の管理を容易にすることで、プロジェクト全体の信頼性と効率を支える、重要なコンポーネントとなっている。

Cache Manifestは、まずショットに関する基本設定（尺やfps、軸方向など）を記述できる点が特徴だ。JSON形式でも同様の情報は記述できるが、USDならば標準で備わっている属性を活用できるため、記述の手間が大幅に軽減されるという。

さらに、variantSetsを使えば、Stepped／Linearといった複数のキャッシュ形式を同一ファイルに収めることも可能だ。例えば、1体のキャラクターに対し、Tポーズ・Stepped・Linearの3種類のキャッシュを登録しておくことで、エフェクト作業など多様な用途に対応しやすくなる。

このような設計により、Solaris上でのプレビューも容易になる。variantSetsを切り替えるだけで、必要なキャッシュを即座に確認できるのだ。

また、Cache Manifestは「Cache Components」、「Asset Manifest Components（ACM）」「Shot Manifest Component（anmCacheManifest）」という3層構造で管理されている。Cache Componentsはキャッシュそのもの、ACMは1体のキャラクターに対するキャッシュの統合情報、そしてanmCacheManifestはショット全体の統合情報を指す。それぞれが役割を分担することで、膨大なキャッシュ管理の混乱を防いでいるのだ。

各アセットに対しては、以下のような構造でコンポーネントが整理されている：

・abc_xxxStepped／abc_xxxLinear：実際のAlembicキャッシュ
・acm_xxx：Stepped／Linearの参照を含むACMファイル（1アセット1ファイル）
・anmCacheManifest：ショット全体の構成をまとめたマニフェスト（1ショット1ファイル）

このような整理により、特定のキャッシュがどのアセットに紐づくものなのかが明確に把握できるようになっている。また、ネーミングにはNamespaceが活用され、各キャッシュの意味合いも読み取りやすい。

Manifest設計の最上位にあたるのが、anmCacheManifestを含むShot Manifest Componentだ。これはショット単位で生成されるもので、以下のような構成をもつ：

・Flipbook（Houdiniによるmp4レンダー）
・UE用のJSON
・PDGネットワークのHIPファイル
・各種Manifest（ACMおよびCache Manifest）

FlipbookはPDGネットワークによって自動的に生成されるため、確認作業の効率も大幅に向上する。さらに、manifest.usdaがもつメタ情報により、どのキャッシュがどこに保存され、どんな設定で書き出されたかを追跡可能となっている。

こうした構造の最大の利点は、クラウド上でのトラフィックを最小限に抑えられる点にある。例えばRegular Publishではキャッシュファイル自体もDataSyncを通じて共有されるが、Lazy Publishでは、shared/publishにはメタデータのみを置き、キャッシュファイルそのものはunshared/temp/cacheにローカル保存する。

Manifestファイルには再書き出しに必要なすべての情報とPDGネットワーク（HIP）が含まれているため、外注先でも同じ環境を再現できる。これにより、ファイル転送量の削減と、高精度なワークフロー再現性を両立している。

続いてパベル氏は、PDGの実装の解説を始めた。キャッシュのパブリッシュ処理を自動化するために構築されたPDGネットワークは、プロジェクト全体を対象とする大規模なものだ。作業対象となる全ショットに対応しつつ、すでに作業を終えたショットには処理を再実行しないよう制御されている。

ネットワークは大きく「下準備」と「実行処理」の2パートに分かれており、PDGの基本的な思想に基づいて構築されている。上段ではアセスメント処理を行い、下段ではFBX、Alembic、USDのそれぞれのフォーマットでキャッシュを書き出すためのMaya Command Chainが展開される。

また、ショットごとに設定されたdisablePublishServiceパラメータによって、サービスの実行可否を柔軟に切り替えることができる。これにより、エピソード単位やシーン単位での再出力を防ぎ、効率的な処理が可能となる。

さらに、キャッシュ出力の基となるアニメーションデータは、プロジェクトの進行状況に応じてanm（アニメーション）、anmp（プライマリアニメーション）、lay（レイアウト）の3段階から自動で選択されるようになっている。優先順位が定義されており、例えばアニメーションが未完成でもレイアウトからキャッシュを出すといった柔軟な運用が可能だ。

キャッシュ書き出しに先立ち、PDG上では各ショットに含まれるアセットの情報を収集し、依存関係や更新の有無を評価するアセスメント処理が行われる。

まず、アニメーションシーンに含まれるアセット情報とNamespace情報を収集。これにより、同一アセットがシーン内で複数登場している場合でも、個別に管理が可能となる。さらに、各アセットに付随するTime Driverの数と名前も取得される。これはキャッシュのコマ落とし処理に影響を与える重要な要素だ。

続いて、アニメーションデータのロケーションやパブリッシュディレクトリ、使用されたMayaのバージョン情報など、書き出し時に必要な各種情報を保持する。特にMayaのバージョンは、互換性確保のために重要であり、パブリッシュ時のバージョンをそのまま保持しておくことで、再利用時の不整合を防げる。

対象アセットの選定には、アセットごとに付与されたアセットカテゴリが用いられる。例えばfxCache/abc、lgtCache/fbx、rtaCache/usdといった形で、フェーズ（fx、lgt、rta）とフォーマット（abc、fbx、usd）を組み合わせたタグが設定されており、これにより不要な書き出しを防ぎつつ、適切なデータだけを抽出できる。

また、アニメーション用の軽量アセット（bldAnm）は、書き出し処理に際して自動的に最終レンダリング用のアセット（bldRend）に置き換えられる。これもアセスメント段階で事前に検出・更新される情報のひとつである。

さらに依存管理の観点から、アセット単体だけでなく、その動作に影響を与えるほかのアセット（例えば、プロップが特定キャラクターにコンストレインされている場合など）に関する更新情報もassetupdateinfoとして記録される。この情報によって、プロップを正しく再キャッシュするために必要な依存元のアセットが自動的に判断されるしくみとなっている。

続いて紹介されたのは、キャッシュ書き出し時の設定をどのように管理・適用しているかという点だ。プロジェクトにおいて、ショットごとに異なる書き出し設定が求められる場面は少なくない。そこで活用されているのが、Pipeline Parameterから読み込まれるpublish_optionsアトリビュートだ。これにより、各ショットに対して適切なAlembic書き出し設定が自動的に適用される。

設定の内容はJSON形式で記録され、Houdiniノードのパラメータ名と対応しているため、後工程でも確実に再利用できる。また、こうした設定を効率的に管理・運用するために開発されたのがPublish Options TOPノードである。

このノードでは、例えばMaya Export AlembicノードをSourceとして指定し、必要なパラメータだけをOptionsとして抽出。Publish Optionsとして一括管理できるほか、生成されたアトリビュートを対象ノードへ適用するしくみも備わっている。これにより、書き出し設定の変更をPipeline Parameter側から柔軟に行うことが可能になっている。

この方式は、ノードUIに直接アクセスできないアーティストにとっても有効だ。ショット単位で設定を変えたい場合は、Pipeline Parameterを編集するだけでよく、PDGはそれを反映して書き出し処理を実行してくれる。こうした構造によって、設定変更と実行を安全かつ柔軟に切り分けられる点が大きな利点と言える。

PDGネットワーク上では、キャッシュフェーズ（Phase）ごとにFBX、Alembic、USDといった形式別に設定を分岐させている。例えば、lgt（ライティング）用のAlembicと、rta（Unreal Engine）用のFBXでは、出力の内容もパラメータも異なる。そのため、Pipeline Parameterから読み込まれるpublish_datatypeアトリビュートを基にWorkItemを分類し、形式ごとに設定を適用する構成としている。

さらに、Unreal Engine向けのキャッシュでは、ポリゴンの三角形化（Triangulate）など、出力における特有の処理も必要となる。こうした個別設定も1パラメータ単位でPublish Optionに組み込み、出力の精度と柔軟性を両立させている。

大量のショットやアセットを扱う大規模プロジェクトでは、「すでにキャッシュが出ているアセットかどうか」を正確に判定することが、無駄な処理を防ぐ鍵となる。パベル氏はこの課題を解決するために、独自のPDGノードによる依存関係チェック機構を構築した。

このしくみでは、まず対象のアセットが保存されているロケーション内にある全てのRevisionを検索し、アニメーションやアセットのRevision情報、書き出し時の設定を含むメタデータ（JSON）を比較。現在の条件に合致するRevisionが存在すれば、再パブリッシュは不要と判断され、該当処理はスキップされる。

このとき設定されるskipcmdchaincook属性が1であれば処理は停止、0であればパブリッシュを実行するしくみだ。ただし、例外的に強制的な再パブリッシュが必要な場合にはforce_republishにより処理を上書きできるようになっている。

こうした判定処理は約9千アセット・10万以上のファイルに対して実行されるため、マルチスレッドによる高速化も施されている。この機構が、作業の自動化と最適化における中核を担っている。

アセスメントが完了し、実際に書き出し処理を行うステージに入ると、PDGネットワークはFBX・Alembic・USDの3つの出力先に分岐する構成となっている。今回のプロジェクトではUSDはキャッシュ用途としては使用されなかったが、将来的な拡張を見越して準備されているという。

書き出し処理の各ノードでは、前段のアセスメントで得たskipcmdchaincook属性を基に、Schedule When機能を活用し、WorkItemごとの実行可否を制御。これにより、新規または変更のあったキャッシュのみを効率的に処理できるようになっている。

次に、Mayaノード群が実行され、キャッシュの書き出しに向けた一連の操作が行われる。特に注目すべきは、Mayaファイルの読み込み時にリファレンスをアンロードする設定により、高速な起動を実現している点だ。また、リファレンスされたアセットにおけるコンストレインの依存関係は、ツリー構造としてメモリ上に保持され、後続のノードで活用される。

さらに、アセットが更新されている場合にはMaya Replace Referenceノードにより、bldAnmからbldRendへの差し替えが行われる。これらのノードはショット単位ではなくアセット単位で並列に走るため、パフォーマンス上の利点も大きい。

アセットに変更がなかった場合には別系統のノードが走り、既存のリファレンスを読み込み直すだけで処理が完了するようになっている。各処理は全て依存情報に基づき、最小限の書き出しと最適な再利用を実現するよう設計されている。

Mayaノード群の実行後は、実際のキャッシュ書き出しに向けた準備が進められる。まずはカメラの読み込みから始まる。これはカメラのNamespaceの情報を基に実行され、さらにカメラにコンストレインでつながる要素も同時に読み込まれる。

続いて、プロジェクトごとに定められた場所にスクリプトを配置することで、書き出し前に任意の処理を挿入できるrun_preAlembicScriptが実行される。例えばアーティストが個別に必要とする処理をこの段階で追加できるようになっている。

Time Driverの書き出しでは、chanファイル、Houdini clip、csvの形式で各種カーブ情報を出力。さらに、ステップ・コンペンセーションの処理も行われる。これはSteppedで記述されたキャラクターのアニメーションと、Linearなカメラの動きが合わずにガタつく問題に対処するためのしくみで、滑らかな見た目を維持する上で不可欠な工程だ。

その後、Alembicの書き出しが行われる。このノードは、publish_optionsアトリビュートの内容に基づき、全てのパラメータがエクスプレッションで制御されている。また、書き出し後にはlgt（ライティング）かrta（Unreal Engine）用のどちらかの処理に分岐する。

rta用のフローでは、Houdini Engineが起動され、Alembicファイルを読み込むためのコンバート処理が行われる。最終的には、専用ノードによって変換結果をレンダリングするところまで自動化されている。

キャッシュの書き出し工程が完了すると、次に行うのはマニフェストのパブリッシュである。まず用いられるのが、PPIの社内で開発されたCustom Publishノードだ。このノードは、namespace、publish_datatype、cache_pathといったキャッシュ情報の基本的な要素を記録するほか、アニメーションやアセットのRevision情報（dependencies）、各種書き出し設定（publish_options）なども含めて保存する。

パブリッシュの後には、各キャッシュに対応するFlipbookのレンダリングも実行される。Flipbookの生成にはGPUリソースが必要なため、GPU搭載マシンのみに制限をかけてノードのスケジューラを実行しているという。

そして最後に行われるのが、Publish Shot Manifestノードによるショットマニフェストの生成だ。これは前述したanmCacheManifestと呼ばれるUSDファイルで、ショット単位でキャッシュの構成を定義する重要なコンポーネントとなる。ここまでの一連の処理を経て、ようやくパブリッシュ工程が完了する。

数千ショット規模のプロジェクトにおいて、毎回手動でキャッシュパブリッシュネットワークを実行するのは現実的ではない。この処理の自動化において活躍するのが、DeadlineのJob Scheduling機能だ。PPIでは、PPI Deadline Schedulerによってパブリッシュネットワークのスケジュール実行を可能にしており、rtaフェーズは毎日20時、lgtフェーズは毎日21時にキャッシュのパブリッシュが自動的に実行されるよう設定している。ファームの混雑を避けるために1時間の時差を設けた上で、アーティストの業務に支障を与えない時間帯で処理される。

実行状況はDeadlineのUI上で可視化され、各ショットのタスク状態やエラー箇所が即座に確認可能だ。アーティストが直接状況を把握し、必要な修正にすぐ対応できるしくみが整えられている。

また、容量やトラフィックの観点でも最適化が進んでいる。今回のプロジェクトでは、自動実行により5TB以上のキャッシュが生成されたが、これは約4,000ショットというプロジェクト規模に対しては十分に軽量な水準といえる。未使用キャッシュの自動削除機能も実装されており、次のプロジェクトではさらなる効率化が期待されている。

本講演の後半では、PDGを活用したキャッシュパブリッシュフローの設計から実装、そしてDeadlineによる自動スケジューリングまでの一連の取り組みが詳細に紹介された。特に数千ショット規模の大規模プロジェクトにおける差分パブリッシュ、依存関係管理、容量最適化といった実践的な課題への対応は、業界内でも汎用性の高い知見となるだろう。パイプラインの自動化を志す開発者にとって、極めて参考となる内容であった。