XGenと.txファイルがレンダーファームで壊れる？Mayaプリフライトガイド
概要
レンダーファームでシーンが「壊れる」典型パターン
ワークステーションでは完璧にレンダリングできるのに、レンダーファームに送ると結果がおかしくなる — これはMayaパイプラインの中でも特に原因を特定しづらいトラブルの一つです。ログを見ても「あなたのせい」だと示す記述はなく、シーンファイル自体もどこも壊れていません。最もよくある原因は、XGenと.txテクスチャキャッシュの2つです。どちらも設計上、メインのシーンファイルの外側で動作します。XGenはグルーム(毛の生成)とディスクリプションのデータを、別のcollectionsフォルダとarchivesフォルダに保存します。また、ArnoldのMtoAプラグインは、ソーステクスチャの隣に独自のタイル状.txテクスチャキャッシュをサイレントに生成することがあります。どちらの問題も、ローカルで.maファイルや.mbファイルを開いたときには表れません。ローカル環境では、それらの外部ファイルがMayaの想定通りの場所にすでに存在しているためです。
フリーランスや小規模スタジオのMaya案件では、このパターンが十分な頻度で発生するため、きちんと文書化しておく価値があります。ファームでのレンダリングで毛や毛皮が「消える」現象や、フレームの途中で原因不明のOpenImageIOエラーが発生する現象は、ほとんどの場合ソフトウェアのバグではありません。実際にはアセット収集の不備とキャッシュの陳腐化が原因であり、どちらも提出前の短いプリフライトチェックで防ぐことができます。
ローカルのワークステーションではグルームとキャッシュデータが正しく解決されるが、レンダーファームのノードでは見つからず、毛や毛皮がレンダリングから消えてしまう様子を示す図。
シーンが「問題なさそう」でもXGenがレンダーファームで壊れる理由
XGenは、グルームやディスクリプションを.ma/.mbファイルに焼き込まれたジオメトリとしては保存しません。参照として保存します — 具体的には.xgenパレットファイルに加え、ディスクリプションの設定次第で、collectionsフォルダ(ディスクリプションごとのグルームデータ)やarchivesフォルダ(ディスクリプションがライブ生成ではなくアーカイブからのレンダリングに設定されている場合の、ベイクされたポイントキャッシュやAlembicデータ)が使われます。ローカルでシーンを開くと、Mayaはこれらの参照を、自分のマシンやローカルネットワーク共有上にすでに存在するパスに対して解決します。同じシーンがレンダーファームのノードに届くと、多くの場合これらのパスは存在しません。パスが絶対パスだったため、ファームノードにマッピングされていないUNC共有を指していたため、あるいは.ma/.mbファイルだけがアップロードされ、隣にあるはずのxgen/フォルダが一緒に送られなかったためです。
結果として、はっきりしたエラーになることはほとんどありません。XGenは通常、ディスクリプションの解決に静かに失敗し、レンダリングはそのまま完了します — ただし、本来そこにあるはずの毛や毛皮、羽毛が入っていない状態のままです。これがデバッグを厄介にする特有の失敗パターンです。フレームの他の部分はすべて正しくレンダリングされ、ドライブはマッピング済みと報告され、ファーム側のMayaとXGenのバージョンもワークステーションと完全に一致しています。それでもグルームだけが消えているのは、それを生成するファイルが最初から届いていなかったからです。
もう一つ、関連する原因があります。xgen/フォルダがきちんと収集されている場合でも、ディスクリプションが「レンダリング時に生成」なのか「キャッシュ/アーカイブ済み」なのかという設定が重要になります。ディスクリプションがアーカイブから読み込む設定になっていて、そのアーカイブパスがファームノードと共有されていないプロジェクト構造に対する相対パスである場合、ライブ生成のグルームにフォールバックすることなく、ディスクリプションは何も解決しないまま終わります。
一般的なディスクリプションエディタ風のパネルで、collectionとarchiveのパスフィールドを強調し、XGenのグルームデータ参照がメインのシーンファイルの外側に存在することを示す図。
.txテクスチャファイルがレンダーファームで壊れる理由
.txは、OpenImageIOのmaketxツールで生成される、タイル状・ミップマップ化されたテクスチャ形式です。Arnoldは生のソース形式よりも.txテクスチャの方を高速に、かつ少ないメモリフットプリントで読み込めます。そのためMtoA(ArnoldのMayaプラグイン)には「Auto-Convert Textures to TX Files」という機能があり、保存時またはレンダリング時に、ソーステクスチャの隣に.txキャッシュをサイレントに生成します。
このオート変換の挙動は、ローカルディスクが1つ、OpenImageIOのビルドも1種類だけの単一ワークステーションでは便利です。しかし、分散型のレンダーファーム全体では、次の3つの独立した理由により、はるかに信頼性が低くなります。
- キャッシュの陳腐化。
.txファイルが生成された後にソーステクスチャが編集され、本来なら再変換をトリガーするはずのタイムスタンプチェックが発火しなかった場合(あるいはファームノードが必要とする書き込み可能な場所が、生成時のものと異なる場合)、Arnoldは古い.txファイルを、それが古いという警告なしに読み込んでしまうことがあります。 - バージョン不一致。
maketx/OpenImageIOのバージョンは、ArnoldやMtoAのリリースごとに異なります。あるOIIOバージョンで生成された.txキャッシュを、ファーム側の別バージョンで読み込むと読み込みエラーが発生することがあり、通常は原因不明のOIIOエラーとしてフレームが中断される形で表れます。 - 共有パスや読み取り専用パスでの書き込み競合。 オート変換は、
.txファイルをソーステクスチャの隣に書き込めることを前提としています。レンダーファームでは、その場所が読み取り専用だったり、複数のジョブで共有されていたり、あるいはワークステーションで使っていた物理パスとは単純に異なっていたりします。その結果、変換がサイレントに失敗するか、複数のノードが同じキャッシュファイルへの書き込みを競合させることになります。
この問題は業界全体でよく見られるため、当社に限らず多くのレンダーファームのドキュメントが、Maya/Arnoldユーザーに対してオート変換の挙動そのものを直そうとするのではなく、「Auto-Convert Textures to TX Files」を無効にするよう案内しています。より信頼できるやり方は、意図的に方針を決めることです。既知の固定されたmaketxバージョンでテクスチャを事前に.txへ変換し、それらの.txファイルをアセット収集の一部として提出するか、あるいはオート変換を完全にオフにして生のソーステクスチャを提出し、変換処理をファーム側のレンダラーに一貫して任せるかのどちらかです。
maketxによってソーステクスチャが.txキャッシュに変換される様子と、陳腐化またはバージョン不一致のキャッシュがテクスチャ読み込みエラーにつながる様子の2つの分岐を示すパイプライン図。
Mayaのシーンアーカイブが自動で集めてくれないもの
Maya標準のシーンアーカイブ機能(Send To / archive project)は、標準的な参照モデル — Mayaのfileノードを通じて接続されたテクスチャや、シーングラフの内側にあるジオメトリ — を前提に設計されています。XGenはこのモデルに完全には当てはまらないため、それ以外は「完璧」に見えるアセット収集の中で、最も見落とされやすい要素の一つになっています。XGenシーンをどのレンダーファームに提出する場合でも、次のものを明示的にパッケージ化する計画を立ててください。
.xgenパレットファイル自体- シーン内で参照されているすべてのディスクリプションに対応する
xgen/collections/<description>/フォルダ - いずれかのディスクリプションがベイク済みアーカイブからのレンダリングに設定されている場合は
xgen/archives/フォルダ - XGenのモディファイアがMaya標準のfileテクスチャノードの外部で参照する、ガイドカーブ、密度マップ、長さマップなどの外部ファイル — これらは通常のテクスチャを検出するアーカイブツールをすり抜けてしまうことがあります
- シーンが作成された正確なMayaおよびMtoA(Arnold for Maya)のバージョン — これにより、レンダーファーム側が「近いが微妙に異なる」ビルドではなく、一致するプラグインビルドでディスクリプションを読み込めるようになります
これらはどれも特別なソフトウェアを必要としません。必要なのは、XGenのデータを、シーン保存の暗黙的な副産物としてではなく、アセット収集の中で正式な構成要素として扱うことだけです。
XGen/.txジョブ向けMaya + Arnoldプリフライトチェックリスト
| ステップ | 確認事項 | 重要な理由 |
|---|---|---|
| 1. バージョン確認 | レンダーファームが対応しているMayaおよびArnold/MtoAのバージョン範囲が、シーンの正確なバージョンをカバーしているか確認する | ファイルパスが正しくても、バージョンの不一致がXGenディスクリプションの互換性を壊すことがあるため |
| 2. XGenフォルダの収集 | xgen/collections/、xgen/archives/、.xgenファイルを明示的にパッケージ化する — 汎用のシーンアーカイブツールだけに頼らない | これらは最も置き忘れられやすいファイルであり、毛や毛皮がサイレントに消える原因になる |
| 3. 生成/アーカイブ設定の確認 | 各ディスクリプションがライブ生成なのか、ベイク済みアーカイブから読み込むのかを確認し、アーカイブパスがジョブと一緒に移動することを確認する | 解決できないアーカイブパスは、エラーもなく何もレンダリングしない結果につながる |
| 4. テクスチャ戦略を1つに決める | 「Auto-Convert Textures to TX Files」を無効にして生のテクスチャを提出するか、固定したmaketxバージョンで事前変換して.txファイルを含めるかのどちらかにする | オート変換を有効なままにしておくことは、ファーム側の書き込み権限と一致するOIIOバージョンを前提にしており、その前提は常に成り立つとは限らない |
| 5. UNCパスとドライブレターの参照を修正する | XGenおよびテクスチャノード内の\\server\share\...やローカルドライブレターのパスを、ファームからアクセス可能な相対パスに置き換える | ローカルでは解決できるパスが、レンダーノード上には存在しないことが多いため |
| 6. 1フレームのテストを実行する | フルシーケンスの前に1フレームだけテスト送信し、レンダリングが完了したかどうかだけでなく、テクスチャの読み込みやXGen解決に関する警告がないかレンダーログを具体的に確認する | 毛の欠落、テクスチャの欠落、OIIOエラーを、フルシーケンス全体を無駄にする前に検出できるため |
| 7. ショットごとにCPU/GPUを決める | XGenを多用したグルーム、密度の高い毛・毛皮、カスタムシェーディングネットワークを含むショットでは、最終フレームにArnoldのCPUレンダリングパスを想定しておく — プロシージャル処理やカスタムシェーダーを多用するシーンは、Arnold自身のガイダンスが最終出力にCPUを推奨しているクラスの作業であるため | 提出前にCPU/GPUのルーティングを決めておくことで、レンダリング途中でデバイス制約が発覚する事態を避けられる |
よくある問題と対処法
| 症状 | 想定される原因 | 対処法 |
|---|---|---|
| ファームレンダーでは毛や毛皮が欠けているが、ローカルでは表示される | XGenのcollections/archivesフォルダが収集されていない、またはパスがファームからアクセスできない | XGenフォルダを明示的にパッケージ化し、UNC/ドライブレターの参照を修正する |
| フレームの途中で原因不明のOpenImageIOエラーによりレンダリングが中断する | .txキャッシュが陳腐化している、またはバージョンが不一致 | 固定したmaketxバージョンで.txを再生成する、またはオート変換を無効にして生のテクスチャを提出する |
| レンダーノード上でテクスチャやビットマップが解決できない(3ds Max + Arnoldのパイプラインでも見られる、関連はあるが別種の失敗パターンです — 詳しくは3ds Max Arnoldのビットマップ欠落ガイドをご覧ください) | レンダーノードからテクスチャパスが解決できない | 提出前に、相対パスかつファームからアクセス可能なパスであることを確認する |
| 再提出すると正しくレンダリングされるが、最初は失敗する | 1回目のパスでオート変換がレンダリング途中に.txキャッシュを書き込んでおり、2回目のパスでは完成済みのキャッシュが読み込まれた | 提出前に.txファイルを事前変換しておく、またはオート変換を完全に無効にする |
| 読み込み時にArnoldまたはMtoAプラグインのエラーが発生する | ファーム側のMtoAバージョンが、シーンが作成されたバージョンと一致していない | 提出前に対象のMaya/Arnoldバージョン範囲を確認する |
警告レベルのテクスチャ読み込みエラーを示すレンダーログコンソールのモックアップ。陳腐化または不一致の.txキャッシュがレンダーノード上で発生させるメッセージの例を示す。
まとめチェックリスト
- MayaとArnold/MtoAのバージョンを、レンダーファームの対応範囲と照合して確認しました
-
xgen/collections/とxgen/archives/をアセット収集に明示的に含めました - 各XGenディスクリプションの生成/アーカイブ設定を確認し、パスがファームからアクセス可能であることを検証しました
- テクスチャ戦略を1つに決めました：事前変換した
.tx(固定maketxバージョン)、またはオート変換を無効にした生のテクスチャのどちらか一方(両方は不可) - すべてのUNCパスとドライブレターのパスを、相対的でファームからアクセス可能なパスに置き換えました
- フルシーケンスの前に1フレームのテストを提出し、レンダーログでXGenおよびテクスチャの警告を確認しました
- XGenを多用するショットやカスタムシェーダーのショットについて、CPU/GPUのレンダリングパスを決定しました
当社のファームでは、比較的新しいMayaバージョン(2022以降)は提出時に自動でバージョンマッチングを通過します。対応範囲である2014〜2027の古いバージョンは、レンダリング開始前にプロビジョニングと互換性チェックを経由するため、ジョブの途中ではなく、フレームを消費する前に不一致を検出できます。パス、キャッシュ、アーカイブ設定に関する項目はシーン固有のものであり、どのファームにジョブを送る場合でも確認する価値があります。
XGenやテクスチャ以外も含めた、Mayaクラウドレンダリング全般のセットアップについては、MayaクラウドレンダリングガイドとArnoldレンダラー完全ガイドをご覧ください。ファームのバージョンマッチングを支えるソフトウェア対応範囲については、MayaレンダーファームページとArnoldレンダーファームページをご覧ください。テクスチャ面では、OpenImageIO自身のmaketxドキュメントが、.tx変換が実際に何を行っているか、そしてどのフラグがミップマップやタイリングの挙動を制御するかについて、最も明確な技術リファレンスです。
FAQ
Q: クラウドレンダーファームでレンダリングするとXGenの毛や毛皮が消えるのに、ローカルでは問題なく表示されるのはなぜですか？ A: これは通常、XGenのcollectionsフォルダとarchivesフォルダが、シーンの他の部分と一緒に収集されなかったことを意味します。XGenは、レンダリング時にこれらの外部ファイルからグルームとディスクリプションのデータを読み込みます。.maまたは.mbファイルだけがアップロードされている場合、レンダーノードには毛や毛皮を生成するための元データがなく、明確なエラーを出す代わりに毛のない状態でレンダリングされます。
Q: .txファイルとは何ですか？なぜArnoldはそれを必要とするのですか？
A: .txファイルは、OpenImageIOのmaketxツールによって作成される、タイル状・ミップマップ化されたテクスチャです。ArnoldとMtoAは、生のソース形式ではなく.txテクスチャを使用します。タイル状のミップマップは読み込みが速く、レンダリング中のメモリ使用量も少ないためで、これは単一のワークステーションよりもファーム規模のレンダリングにおいてより重要になります。
Q: レンダーファームに提出する際、「Auto-Convert Textures to TX Files」は有効にしたままでよいですか？
A: 有効にしたままにしておくと、ファーム側のテクスチャエラーの一般的な原因になります。1台のワークステーション、1つのディスクという環境では問題なく動作しますが、分散型のファームでは、陳腐化またはバージョン不一致の.txキャッシュを生成したり、レンダーノード上での書き込み権限の違いに引っかかったりすることがあります。既知のmaketxバージョンで事前変換して.txファイルを提出するか、オート変換を無効にして生のテクスチャを提出することで、どちらの失敗モードも回避できます。
Q: MayaとArnoldのバージョンはすでにファーム側と一致しているのに、なぜレンダリングでテクスチャが欠けたままなのですか？ A: バージョンの一致はプラグインレベルの失敗を防ぎますが、ファームで発生するXGenや.txのエラーのほとんどは、バージョンではなくファイルパスに起因します。XGenがレンダーノード上に存在しないUNCパスやローカルドライブレターを参照している場合、または.txキャッシュがファームから到達できないテクスチャの場所に対して生成されている場合、ソフトウェアのバージョンが一致していてもレンダリングは失敗します。
Q: レンダーファームがどのMayaおよびArnoldバージョンに対応しているかは、どのように確認すればよいですか？ A: 提出前に、ファームが対応しているMayaおよびArnold/MtoAのバージョン範囲を確認してください — バージョンを一致させることで、ある種類のレンダリングエラーを丸ごと回避できます。当社のファームはMaya 2014〜2027に対応しており、2022以降のバージョンは提出時に自動でバージョンマッチングを通過し、それより古いバージョンは互換性チェックを経由します。
Q: XGenを使ったショットは、ArnoldのCPUパスとGPUパスのどちらでレンダリングすべきですか？ A: 密度の高い毛や毛皮を含み、カスタムシェーディングネットワークを使用するXGen多用ショットは、最終出力にArnoldのCPUパスを使うべきです — これは、Arnold自身のガイダンスが最終出力にCPUを推奨しているクラスの作業だからです。どちらのパスを使う場合でも、レンダリング途中で制約が発覚するのではなく、プリフライトの一部として提出時にデバイスを決定してください。
Q: XGenを使用したMayaシーンをレンダーファームに提出する前に、何を確認すべきですか？ A: 短いプリフライトを実施してください。Maya/MtoAのバージョンが一致していることを確認し、xgen/collectionsとxgen/archivesフォルダを明示的にパッケージ化し、テクスチャ戦略を1つに決め(事前変換した.tx、またはオート変換を無効にした生のテクスチャ)、UNCやローカルドライブの参照を修正し、フルシーケンスの前に1フレームのテストを提出してください。
Q: これはXGen特有の問題ですか、それとも他のDCCでも発生しますか？ A: 同じ根本的なパターン — メインのシーンファイルの外側に存在するデータと、陳腐化するキャッシュテクスチャデータ — は、他の場面でも見られます。3ds Maxユーザーは、テクスチャパスがレンダーノード上で解決できない場合に、Arnoldのビットマップノード欠落という、関連はあるが別種の問題に直面します。詳しくは3ds Max Arnoldのビットマップ欠落ガイドをご覧ください。
About Thierry Marc
3D Rendering Expert with over 10 years of experience in the industry. Specialized in Maya, Arnold, and high-end technical workflows for film and advertising.
