USDを使用したMayaシーンをレンダーファームでレンダリングする方法

Universal Scene Descriptionは、Pixar社の社内フォーマットから多くのMayaパイプラインの基盤へと進化しました。スタジオがレイヤー構造のUSDステージを用いてショットをコンポーズし、部門をまたいでパブリッシュされたアセットを参照し、プロシージャルを通じてレンダラーに渡しているのであれば、USDがもはや実験的な取り組みではなくシーンの根幹であることは自明です。しかし、デッドラインが迫るまで気づかないのは、ワークステーションで完璧にレンダリングできるシーンが、他のファームでも同様にレンダリングできるとは限らないという点です。ファームには適切なMayaUSDのビルド、適切なレンダリングエンジンのUSDサポート、そしてステージが参照するすべてのアセットパスを解決する手段が必要です。これらのいずれかが欠けていると、明確なエラーは発生しません。フレームの失敗、サイレントなフォールバック、あるいは単純にジオメトリが存在しないという状況が生じます。

私たちはマネージドレンダーファームを運営しており、Maya+USDのジョブはスタジオがワークステーションから移行するのに苦労するワークフローのひとつです。このガイドでは、USDが自己完結型の.maファイルよりもリモートレンダリングが難しい理由、実際に動作させるために何を揃える必要があるか、そして私たちのファームでどのように対応しているか——間違えやすいポイントも含めて——を解説します。

Maya USDレンダリングパイプライン：レイヤー構造のUSDステージからMayaUSDプラグイン、Arnold USD procedural、レンダリングフレームへ。アセット解決と環境マッチングを含む。

USDが自己完結型シーンよりもリモートレンダリングが難しい理由

従来のMayaシーンはほぼ自己記述型です。ファイルを開くとメッシュとマテリアルが揃っており、レンダラーを向ければフレームが出力されます。USD駆動のシーンは、完成品というよりもレシピに近いものです。.usd、.usda、.usdcファイルは、サブレイヤー、リファレンス、ペイロード、バリアントといったレイヤー構造の命令セットであり、ロード時に最終的なステージへとコンポーズされます。このコンポジションは強力ですが、レンダリングするマシン上で3つの要素がすべて揃い、互換性を持っている必要があることを意味します。

最初の要素はMayaUSDプラグインそのものです。MayaUSDは、MayaがUSDステージを読み込み、コンポーズし、レンダリングに渡すためのブリッジです。ファームのMayaにMayaUSDがロードされていない場合、あるいはアーティストが制作に使用したバージョンとステージのコンポーズ方法が異なるバージョンが使用されている場合、シーンは開けないか、USDを通じて追加されるべき部分が欠落した状態で開かれます。

2番目の要素はアセットパスの解決です。USDステージは、ジオメトリ、テクスチャ、ネストされたUSDレイヤーなどの他のファイルをパスで参照します。ワークステーション上では、データがステージの期待する場所に存在するためパスが解決されます。ファームでは、同じディレクトリ構造と同じリゾルバーの動作が再現されない限り、参照の半分が何にも解決されません。「手元では動く」USDシーンがファームから空のフレームとして戻ってくる最も一般的な理由はこれです。ピクセルは正常にレンダリングされていても、リファレンスが見つからなかったのです。

3番目の要素はレンダラーのUSDサポートです。レンダリングエンジンは、MayaからのUSDデータを理解できる必要があります。Arnoldの場合、そのパスはArnold USD proceduralを通じます。これはステージ全体をMayaに展開するのではなく、レンダリング時にUSDコンテンツを読み込みます。proceduralがインストールされていない場合、またはそのバージョンがデータと一致しない場合、レンダラーは読み取れないものを——サイレントに——スキップします。

これはまた、一部のクラウドレンダリングサービスで広く知られているギャップが露見する場面でもあります。AWSのDeadline CloudにはMayaトラッカーにMayaUSDサポートに関するオープンなissue（aws-deadline/deadline-cloud-for-maya#409）があり、これはUSDシーンを確実にレンダリングするために端から端まで解決する必要があるパイプラインの問題を示す好例です。USDレンダリングは単一のスイッチでオンにする機能ではなく、すべてが一致する必要があるバージョンとパスの連鎖なのです。

MayaのUSD Layer Editor内のレイヤー構造USDステージ——サブレイヤーとリファレンスが表示されている——とArnold RenderViewの出力。

私たちのファームでMaya + USDをレンダリングする方法

私たちのアプローチは、1フレームもキューに入れる前から始まります。シーンをファームの固定イメージに合わせるのではなく、環境をシーンに合わせます。スタジオからUSDベースのMayaジョブを受け取ると、Mayaのバージョン、MayaUSDのビルド、レンダラー、アセットが作成されたUSDのバージョンを確認し、それに合わせてノードを起動します。目標は、ステージが私たちのノード上でアーティストのマシンと同じようにコンポーズされること——同じプラグインの動作、同じ解決方法、同じproceduralです。

レンダリング側では、Arnold使用時のMaya USDで最も重要な2つのコンポーネントが両方ともクリーンに初期化される必要があります。Mayaの内部でステージをコンポーズするMayaUSDと、レンダリング時にUSDコンテンツを読み込むArnold USD proceduralです。私たちはノードプール全体で両方が正しくロードされ動作するプロダクションのMayaジョブをレンダリングしてきました。これが実際のテストです——「ファームがUSDをサポートする」かどうかではなく、「このステージが、これらのリファレンスで、アーティストが期待するフレームを生成するか」ということです。Arnoldはここで私たちのCPUノード上で動作します。これは多くのスタジオがArnoldを最終品質のUSD作業に使用する方法と一致しています。プロジェクトで必要な場合は同じシーンをGPU上で実行することもできます。

注目すべき詳細があります。USDシーンはいくつかのパイプラインを経由してきた場合、残留したプラグインリファレンスや不要なノード属性が含まれることがよくあります。スタジオが数ヶ月前に廃止したプラグインを依然として要求しているシーン、または最終レンダリングパスに含まれないエンジンの属性を持つシーンを目にします。私たちのノードでは、これらの残留物は無害です——Mayaはそれらをスキップして、実際に使用しているエンジンでレンダリングします。ログを整理したい場合は、Mayaで送信前に未知のプラグインリクエストと不要なノードを削除できますが、それは見た目の問題です。レンダリングを止める原因にはなりません。「無害な残留物」と「実際に失敗している原因」の違いを理解することが、USDレンダリングをスムーズに進めるために最も重要なことです。

ハードウェアについて正直な制約をお伝えします。私たちのGPUノードはRTX 5090カードを搭載しており、1GPUあたり32GBのメモリがあります。このメモリはマシン内の2枚のカード間でプールされているわけではありません。多くのスタジオが持ち込むCPU-Arnold USDの作業では、この上限が問題になることはほとんどありませんが、非常に大きなテクスチャや重いボリューメトリクスを含むシーンでGPUパスを実行する場合は、事前に1GPU当たりのメモリフットプリントを確認することをお勧めします。ジョブの途中でフレームが収まらないよりも、事前に確認する方が良いと考えています。

既存のファイルスペースからレンダリング——再アップロード不要

先ほど説明したアセット解決の問題には、スタジオがすでにマウントされたファイルスペースにプロジェクトを保存している場合、明確な解決策があります。アセットがLucidLink上にある場合、私たちは同じファイルスペースをレンダーノードにマウントできるため、USDステージはアーティストが参照するのと全く同じデータに対してリファレンスを解決します——数ギガバイトのアセットライブラリを再アップロードする必要も、手作業でディレクトリ構造を再構築する必要もありません。ステージは実際のパスに対してコンポーズします。なぜならば、実際のパスがマウントされているからです。

これはパッケージ化された単一ファイルのシーンよりもUSDにとって重要です。USDがこれらの外部リファレンスに依存しているためです。ソースのファイルスペースをマウントすることで、「リファレンスが見つからない」という失敗のクラスが丸ごと解消されます。コピーが間違って作成されるという問題がなくなるからです——ファームはスタジオと同じツリーを読み取ります。すでにLucidLinkをネイティブに使用しているチームにとって、これはアップロードして結果を祈るサイクルと、単純に解決されるレンダリングとの違いになることが多いです。

スタジオのLucidLinkファイルスペースがレンダーノードにライブマウントされ、ノードがアセットをその場で読み取る——再アップロードなし。

含まれるもの——ライセンスとDCC、マシンだけではありません

専用キャパシティをレンタルすると、レンダリングエンジンのライセンスとDCCアプリケーションが含まれています。Maya、レンダラー——Arnold、V-Ray、Redshift、Octane、Cycles——およびサポートプラグインは、私たちがプロビジョニングするものの一部であり、ノードごとに個別にライセンスを取得するものではありません。USDジョブでは、通常Arnoldのライセンスが実行の一部として私たちのサイドで処理されるため、ブロック内の各ノードのレンダリングライセンスを別途調達する必要はありません。

これはベアメタルやセルフビルドのアプローチと比較検討する価値があります。そのアプローチではマシンあたりの料金が低く見えますが、レンダリングエンジンのライセンスを加算するまでのことです——セルフホストでは、エンジンあたり、ノードあたり、年間数百ドルから1,000ドルを大幅に超えるものもあります。バンドルは静かに機能している部分です。レンダリングできるシーンは、Maya、MayaUSD、procedural、そしてエンジンライセンスがすべて同時に存在する場合のものです。それらをまとめてプロビジョニングすることが、その連鎖を維持する方法です。

実際の移行例：Maya + USD、動かせなかったクラウドスケジューラーから

具体的な例をご紹介します。最近、私たちは英国のVFXスタジオと協力しました。彼らは既存のクラウドスケジューラーのセットアップが、まさにこの問題——その環境ではMayaがUSDアセットを処理できなかった——のために失敗していたため、私たちのところに来ました。彼らのパイプラインはArnoldを使ったMayaで、LucidLinkファイルスペース上にありました。私たちはファイルスペースをノードにマウントし、環境をシーンに合わせ、ログ上でMayaUSDとArnold USD proceduralの両方がマシン全体で正しく初期化されレンダリングされることを確認しました。シーンには以前のライフからの残留リファレンスが含まれていましたが、それらはスキップされ、フレームが出力されました。スタジオは「USDレンダリングが失敗し続ける」という状態からクリーンな実行へと移行し、そこからスケールアップしました。スタジオは匿名にしていますが、ワークフロー——Maya、USD、Arnold、LucidLink——は例外というよりもむしろ標準になりつつあります。

USDジョブをどのファームに送信する前でも確認するチェックリスト

私たちのファームを使用するかどうかに関わらず、USDシーンがファームで想定外の問題を起こさないよう事前に確認する価値があることをまとめます。

USDレンダリングの失敗のほとんどは、最初の3行のいずれかに起因します。ジョブ後ではなくジョブ前にこれらを確認する理由は、USDではクリーンな実行と空フレームの違いが通常、単一の不一致したバージョンまたは未解決のパスであるためです——デッドラインの480フレーム目よりもテストフレームで発見する方がはるかにコストが低いです。

まさにそのため、私たちが通常Maya USDエンゲージメントを始める方法は代表的な1フレームです。フルブロック前に1フレームを実行し、スタジオがステージのコンポーズと私たちのノードへのフレーム着地を確認できるようにし、大きなコミットメントの前にパイプライン全体を端から端まで検証します。USDでは、1フレームで連鎖を証明することはどのような機能チェックリストよりも価値があります。

USDを超えたMayaレンダリングの全体像を知りたい場合は、Mayaクラウドレンダリングガイドで一般的なワークフローを扱っており、Mayaのレンダーファームの選び方では評価方法を解説しています。このUSD作業が実行される専用ノードのレンタルについては、レンダーファームレンタルページで説明しています。フォーマット自体については、PixarのOpenUSDドキュメント（openusd.org）がステージのコンポーズに関する正式なリファレンスです。

FAQ

Q: レンダーファームはUSDを使用するMayaシーンをサポートしていますか? A: はい。私たちはUSDを使用するMayaジョブをレンダリングしており、MayaUSDのビルドとレンダラーのUSDサポートをシーンに合わせています。プロダクション実行のログで、MayaUSDとArnold USD proceduralの両方がノードプール全体で正しく初期化されレンダリングされることを確認しています。重要なのは、アーティストが使用したのと同じMayaUSDのビルド、USDバージョン、アセットパスがレンダリング側で再現されることです。

Q: どのMayaおよびUSDバージョンをサポートしていますか? A: 固定のイメージに限定するのではなく、アセットが作成されたMayaのバージョン、MayaUSDのビルド、USDのバージョンを合わせています。USDのコンポジションは、レイヤー、リファレンス、バリアントの解決方法においてバージョンの違いに敏感であるため、制作環境に合わせることがステージをワークステーションと同じようにコンポーズさせる方法です。

Q: Arnold USD proceduralをサポートしていますか? A: はい——MayaとArnoldの組み合わせでは、Arnold USD proceduralはレンダリング時にUSDコンテンツを読み取るパスであり、Arnoldと一緒にプロビジョニングします。インストールされており、データとのバージョン互換性がある必要があります。そうでなければ、レンダラーは読み取れないものをスキップします。フルブロックを実行する前に初期化されることを確認します。

Q: Arnoldのライセンスを自分で持ち込む必要がありますか? A: いいえ。Arnoldを含むレンダリングエンジンのライセンスは、私たちがプロビジョニングする専用キャパシティの一部です——ノードごとに自分でライセンスを取得するものではありません。セルフホストのセットアップでは、マシンコストにこれらのライセンスを加算する必要があります。バンドルすることはレンダリング連鎖を維持する方法の一部です。

Q: LucidLinkファイルスペースをマウントして、アセットを再アップロードしなくて済むようにできますか? A: はい。プロジェクトがLucidLink上にある場合、そのファイルスペースをレンダーノードにマウントできるため、USDステージはアーティストが参照するのと全く同じデータに対してリファレンスを解決します。USDにとって特にこれは一般的な失敗モードを取り除きます。なぜなら、ファームはスタジオと同じアセットツリーを読み取るからです——構造が異なる可能性のあるコピーではありません。

Q: MayaのUSDシーンを実行できないクラウドスケジューラーを使用しています。移行できますか? A: それはスタジオが私たちのところに移行する一般的な理由です。環境をシーンに合わせ、ファイルスペースがある場合はそれをマウントし、代表的なフレームでUSDステージがコンポーズされてレンダリングされることを確認してから、フルランへのコミットメントを行います。移行の大部分は、レンダリング側で制作環境を忠実に再現することです。

Q: シーンに使用していないレンダラーの残留リファレンスがあります。これは問題ですか? A: 通常はそうではありません。いくつかのパイプラインを経由してきたUSDシーンは、不要なプラグインリクエストや残留ノード属性を持つことがよくあります。私たちのノードでは、MayaはそれらをスキップしてUSDを実際に使用しているエンジンでレンダリングします。ログを整理するためにMayaで削除することもできますが、それは見た目の問題です——残留物がレンダリングを止めることはほとんどありません。

Q: Maya USDはCPUとGPUのどちらでレンダリングすべきですか? A: 両方が利用可能であり、適切な答えはレンダラーとシーンによります。多くのスタジオはCPU上で最終品質のUSD作業にArnoldを使用しており、私たちのCPUノードはそのために構築されています。プロジェクトで必要な場合はGPUも利用可能です——ただし、私たちのGPUカードは1枚あたり32GBのメモリであり、プールされていないことにご注意ください。非常に重いGPUシーンの場合は、事前に1GPU当たりのメモリフットプリントを確認することをお勧めします。