VFXコンポジティングのクラウドレンダリング：3D比較

はじめに

クラウドレンダリングに関するコンテンツの多くは、単一のワークロードを前提に書かれています。3Dシーンがパストレーサーを通り、バケットごとにノイズが収まってフレームが完成するというものです。このフレーミングは「Redshift」や「V-Ray」のジョブには正確ですが、「Compositing（コンポジティング）」レンダーにはほとんど役に立ちません。コンプは光路をサンプリングしているわけではないからです。コンプが行っているのは、すでに存在する映像素材とパスに対してノードグラフを評価することであり、処理時間とコストを左右するのは、ほぼ間違いなくGPUのサンプル数ではありません。

この違いは見た目以上に重要です。一般的な「クラウドレンダリング」のアドバイスでは、この2つのワークロードが常にひとまとめにされているからです。「Nuke」スクリプトや「After Effects」プロジェクトを初めてファームに移すコンポジターは、3Dレンダーと同じGPU依存の挙動を期待し、シミュレーションもレイトレーシングもないコンプがなぜ遅いのか、あるいは選んだGPUのティアとは無関係な理由でなぜ速いのか、戸惑うことになります。本ガイドはそのギャップを扱うものです。コンプレンダーがファーム上で実際に何をしているのか、3Dレンダーとメカニズム的にどう異なるのか、そして一晩ワークステーションを回すよりもコンポジティング作業をクラウドに移す価値があるのはどんな場合か、を解説します。

当ファーム「Super Renders Farm」では、ビューティパスとAOVを生成する3Dレンダーから、それらを最終ショットへと組み上げるコンポジティングレンダーまで、このパイプラインの両サイドを日々扱っています。両者はハードウェアこそ共有していますが、レンダーの挙動という点ではそれ以外にほとんど共通点がなく、その違いを理解することが、コンプレンダーのジョブを謎ではなく予測可能なものにする鍵となります。

3Dレンダーパスが1つのマルチレイヤーEXRファイルに統合され、コンポジティングソフトウェアを経て最終グレーディングに至るマルチパスEXRコンポジティングフローを示すパイプライン図

コンポジティングは3Dレンダリングとは異なるレンダーワークロードである

「V-Ray」「Redshift」「Arnold」のような3Dレンダラーは光の伝搬を計算します。光線を追跡し、マテリアルをサンプリングし、画像が収束するまで時間をかけてノイズを低減していきます。この処理はピクセルごとに本当に計算負荷が高く、だからこそ3DレンダリングはエンジンによってCPU負荷型にもGPU負荷型にもなり、GPUアクセラレーションが3Dレンダー時間に大きな影響を与えるのです。

コンポジティングレンダーはそのいずれも行いません。「Nuke」「After Effects」「Fusion」といったツールはノードグラフを評価します。画像を読み込み、カラーコレクションを適用し、2つのレイヤーをマージし、トランスフォームを適用し、結果を書き出します。サンプリングも収束もありません。各オペレーションは決定論的で、そのほとんどがピクセルデータに対する線形代数的な処理であり、それらのオペレーション（マージ、グレーディング、キーヤー、トランスフォーム、大半のフィルター）の大部分はGPUではなくCPUで実行されます。一部の特定のノードタイプ（重いリタイム、一部のデノイズ処理、特定の機械学習ツール）はGPUアクセラレーションされますが、これらは典型的なコンプでは例外であり、原則ではありません。

コンプレンダーの所要時間を実際に左右しているのは、計算の問題というよりもデータ移動の問題に近いものです。

読み込みスループット。 コンプスクリプトは、フレームごとに映像素材とレンダーパスを読み込みます。多くの場合、複数のマルチレイヤーEXRシーケンスを同時に読み込みます。
CPUスレッディング。 コンポジティングのオペレーションは1フレーム内でCPUコアをまたいで並列化され、レンダーマネージャーはフレームレンジのチャンクを異なるワーカーに割り振ることでフレーム間を並列化します。
メモリ。 フル解像度のマルチチャンネルフレーム（ビューティパス、複数のAOV、クリプトマット、場合によってはディープパスなど）を同時にいくつもメモリ上に保持することは、見た目以上にメモリを消費します。フレーム処理の途中でRAMが不足することは、生のCPU速度よりもコンプレンダーの失敗要因としてはるかに一般的です。
書き込みスループット。 最終的なコンポジット済みフレーム、あるいは中間のプリコンプは、書き出す必要があります。VFXパイプラインの納品物では、その出力は単一のビデオファイルではなく、多くの場合また別のEXRシーケンスになります。

これはコンポジティングソフトウェアへの批判ではありません。ゼロから画像データを生成するのではなく、既存の画像データを移動・結合することを中心に構築された、異なる種類のワークロードだというだけです。コンプジョブを3Dレンダーと同じように扱い、GPU容量を重点的に用意する一方でRAMとストレージスループットを削ってしまうレンダーファームは、本来そのジョブをうまく処理できるはずのマシンで、まさにパフォーマンスを発揮できなくなります。

コンプレンダーが実際に読み書きするもの

コンポジティングジョブの入出力の形は、3Dレンダリングとの違いが最も具体的に現れる部分です。

マルチレイヤー・マルチパスEXRの入力。 コンプは通常、フレームごとに1つ以上の「OpenEXR」ファイルを開きます。そこにはすでに多数のチャンネルが含まれています。具体的には、ビューティレンダー、ディフューズとスペキュラーの個別パス、ライティングAOV、Zデプスパス、モーションベクター、そしてオブジェクト・マテリアル・アセットIDを分離するためのクリプトマットです。これらすべてが1つのReadノードを通じて単一ファイルとして読み込まれ、パスごとの作業のためにShuffleノードで分割されます。このファイルの読み込みは小さな1回のファイルアクセスではありません。特定のコンプがそのうちの一部しか使わない場合でも、フレームが持つすべてのチャンネルを引き出すことになります。だからこそ、ストレージの読み込み帯域幅は、コンプ処理の多いファームノードでは実際のボトルネックになります。これは、EXRデータの大部分を読み込むのではなく書き込む3Dレンダーではめったに見られないことです。

出力ではなく入力としてのクリプトマット。 クリプトマットデータ（再レンダリングせずに、後からコンポジターが個々のオブジェクト、マテリアル、アセットインスタンスを分離できるようにする、プロシージャルに生成されたIDマット）は3Dレンダーによって書き出され、コンプによって消費されます。つまり、コンポジティングのファームジョブは、上流の3Dレンダーが生成したクリプトマットチャンネルをそのまま引き継ぐことになり、クリプトマットによる分離を多用するコンプは、そうでないコンプよりもフレームあたり多くのチャンネルを読み込みます。当社のEXR-IOとクリプトマットのガイドでは、このデータがどのように構造化され、どう効率的に扱うかを解説しています。クリプトマットを多用するコンプをどのファームに送る前でも、一読の価値があります。

少数の出力、しかし高いビット深度。 3Dレンダーがフレームごとに複数のパスを書き出すことが多いのに対し、コンプレンダーは通常、それらのパスを1つ、あるいはごく少数の最終コンポジット出力にまとめます。VFXパイプラインのさらに下流へ向かうHDRリニア納品物には16ビットハーフフロートEXRが一般的で、完全な精度が必要なデータパスには32ビットが使われることもあります。書き出しは読み込みよりもチャンネル数は少ないものの、それでもフル解像度のフレームであることに変わりはなく、ディープコンポジティングのジョブ（3Dシーンを再レンダリングせずにホールドアウトを解決するため、ピクセルごとに複数のデプスサンプルを保持するもの）では、読み込みと書き出しの両方がかなり重くなります。

動画エンコードはレンダー本体とは別の工程です。 最終納品物が画像シーケンスではなく「H.264」や「HEVC」の場合、そのエンコードは通常、フレームごとのコンプレンダーの一部としてではなく、その後の別パスとして行われます。ビデオコーデックは、独立した画像シーケンスのようにはワーカー間できれいに分割できないためです。当社のH.264とH.265のエンコードガイドでは、その最終工程のトレードオフをより詳しく解説しています。

6つのレンダーパス（ビューティ、ディフューズ、スペキュラー、クリプトマット、デプス、アンビエントオクルージョン）が1つのマルチレイヤーEXRファイルに収束する図

コンプレンダーがクラウドファームでどう分散されるか

コンポジティング作業の分散モデルは、3Dレンダラーのそれよりも「Nuke」のそれに近いものです。その理由を正確に理解しておく価値があります。

3Dレンダラーは1つのフレームを空間的に分割できます。バケットやタイルを異なるスレッドやマシンに割り振ることができるのは、ある領域のピクセルが別の領域のピクセルに本当に依存していないからです。コンプは一般にそのようには分割できません。フレームNにおけるピクセルの値は、そのフレームの入力がノードツリー全体を通って処理された結果に依存するため、コンポジティング作業の大半は画像領域単位ではなくフレーム単位で驚くほど並列化しやすくなります。レンダーマネージャーはコンプのフレームを細分化するのではなく、フレームレンジを細分化し、フレームのチャンクを異なるワーカーに割り振ります。各ワーカーは自分の担当分について、コンポジティングアプリケーションのヘッドレスインスタンス（GUIなし）を個別に実行します。

これは、当社のNukeクラウドレンダーファームガイドが「Nuke」に特化して詳しく解説しているモデルで、具体的なコマンドラインフラグやライセンスの仕組みも含まれています。「After Effects」もほとんどのプロダクションコンプ（タイトルシーケンス、モーショングラフィックス、archvizリビール）で同様に振る舞いますが、ここで1つ注意点があります。フレームをまたいだ時間的状態に依存するAEコンポジション（フレーム間サンプリングを伴うモーションブラー、蓄積するパーティクルシミュレーション、一部のトラッキング処理）はきれいにフレーム並列化できず、単純にワーカー間で分割するとチャンク境界に目に見えるシームが生じることがあります。当社のAfter Effectsクラウドレンダリング設定ガイドでは、どのAEワークフローがきれいに並列化でき、どれがシングルワーカーパスを必要とするかを解説しています。

ファーム上でのコンプレンダージョブの実際の流れは次のようになります。スクリプトまたはプロジェクトと、それが参照するすべてのものが、自己完結型のバンドルとしてアップロードされます。レンダーマネージャーは総フレームレンジをチャンクに分割します。各ワーカーは自分のチャンクを取得し、アーティストのマシンにあったのと同じ映像素材のパス、カラー設定、フォント、プラグイン依存関係を解決し、ヘッドレスでレンダリングします。完了したフレームは各チャンクが終わるたびに共有ストレージまたはクラウドストレージに格納されるため、長いシーケンスであっても、最後のワーカーが終わるかなり前から使用可能な出力が返ってき始めます。

クラウドコンポジティングでよくある問題

ファーム上で失敗したり、誤った結果が返ってきたりするコンプレンダーの圧倒的多数は、コンポジティングの計算上の問題ではありません。ローカルのワークステーションが静かに覆い隠していた、依存関係と環境の問題です。

問題	原因	対処法
色がおかしい、レンダーは「成功」しているが見た目が違う	アーティストがローカルで使用していたのとは異なる「OCIO」/カラー設定がファーム上で解決されている	プロジェクトを1つのデプロイ済みカラー設定に固定します。レンダー環境がデフォルトではなく、まさにその設定を使用していることを確認する
映像素材の欠落やプレースホルダーブロック	絶対ローカルパス（Windowsのドライブレター、マップされたネットワークドライブなど）がリモートワーカー上では意味を持たない	送信前に、参照されているすべてのメディアを自己完結型のネットワークアクセス可能なバンドルにまとめる
フレーム処理の途中でのメモリ不足エラー	フル解像度のマルチチャンネルEXRパスとクリプトマットを複数同時にメモリ上に保持している	CPUコア数だけでなく、RAMの余裕を見込んでコンプレンダーノードを用意します。これは生の計算能力よりも一般的な失敗要因である
チャンク境界に目に見えるシームが生じる	時間依存のオペレーション（モーションブラー、パーティクルシム、一部のトラッキング）が、フレーム独立であるかのようにワーカー間で分割されている	時間依存のコンプを特定し、フレームレンジ分散ではなくシングルワーカーレンダリングに振り分ける
プラグイン、ギズモ、フォントの欠落	カスタムギズモ、サードパーティプラグイン、フォントがローカルにはインストールされているがレンダーワーカーにはない	可能な限りカスタムノード/ギズモをスクリプトに焼き込みます。送信前にファームとプラグイン・フォントのマトリクスを確認する
GPUティアのノードで想定より遅い	コンプがマージ、グレーディング、トランスフォームなどのCPUオペレーションに支配されており、GPUアクセラレーション対象のノードサブセットではない	ジョブをCPU容量に合わせて適切なサイズにします。GPUノードは、GPUアクセラレーションされたリタイム、デノイズ、MLノードを実際に多用するコンプのために確保する

これらはどれか1つのアプリケーションに固有の問題ではありません。コンポジティングスクリプトが、それが作成されたマシンから離れたときに壊れるものの一般的な形であり、だからこそ「フルシーケンスを送信する前に少数でテストする」（まず数フレームをレンダリングし、ローカルの結果と比較する）ことは、どのファームのどのコンプレンダーでも取り入れる価値のある、低コストな保険的ステップなのです。

クラウドレンダリングがコンポジティングパイプラインに実際に役立つ場面

すべてのコンプにファームが必要なわけではありません。ローカルで数分でレンダリングできる短いシーケンスは、クラウドに移すためのアップロードやキューのオーバーヘッドから得るものがほとんどありません。クラウドコンポジティングが元を取れるのは、特定の状況においてです。

締め切り駆動のバースト。 数日ではなく数時間で納品しなければならず、フレーム数と複雑さがワークステーションを締め切りより長く拘束してしまう場合です。1,000フレームのシーケンスを数十台のワーカーに分散させれば、一晩かかるレンダーを1〜2時間で返ってくるものに変えられます。スループットは利用可能なワーカー数にほぼ線形にスケールするからです。

アーティストの作業をブロックしてしまう一晩がかりのバッチ作業。 厳しい締め切りがなくても、アーティスト自身のマシンを数時間占有してしまうコンプは、そのアーティストが反復作業やレビュー、次のショットの作業をできない時間になります。ファームに送信すれば、ローカルレンダーが終わるのを待たずに、すぐにワークステーションを解放できます。

フレームあたりのデータが重い大規模シーケンス。 ディープコンポジティング、4K以上のマルチチャンネルEXR、クリプトマットを多用するコンプは、まさにフレームあたりのレンダー時間が最も積み上がるワークロードであり、多数のCPU負荷型ワーカーに分散させることが、軽量でチャンネル数の少ないコンプの場合よりも大きな効果を発揮します。

すでにファームを使っている3D・コンプ混在パイプライン。 あるショットの3Dレンダーがすでにクラウドファーム上で動いている場合、コンポジティング段階も同じインフラ上に留めることで、2つの段階の間でローカルマシンへ戻る往復を避けられ、パス（ビューティ、AOV、クリプトマット）をコンプが読み込む場所の近くに保持できます。

クラウドコンポジティングが最も元を取りにくいのは、締め切りのプレッシャーがなく、ローカルのレンダー時間がすでに自己完結型プロジェクトバンドルを準備・アップロードする時間よりも十分に短い、少数のシンプルなコンプです。アップロードや依存関係の確認にかかるオーバーヘッドは実在するものであり、小規模なジョブではそれが節約できる時間を上回ることもあります。

コスト：コンプレンダージョブの実際の費用

典型的なコンプでは大多数のノードがCPUとメモリに律速されるワークロードであるため、通常はCPUレートがコストを左右します。GPUレートが適用されるのは、実際にGPUアクセラレーションを使用する特定のノード（重いリタイム、一部のデノイズ、機械学習ツール）のみです。

当ファームでは、CPUコンピュートはGHz時間単位で課金され、基本レートは$0.004/GHz時間（優先度ティアはキューの優先度に応じて$0.004〜$0.016/GHz時間）です。GPUコンピュートはOctaneBench時間（OBh）単位で課金され、基本レートは$0.003/OBh、「RTX 5090」（32GB VRAM）カードはフル稼働時で1カード時間あたり約$5.2です。レンダークレジットに有効期限はなく、マシンレンタルの最低利用時間もありません。そのため、コンプジョブは予約された時間のブロックではなく、実際に消費したコンピュートに対して課金されます。

これを具体的なイメージにするため、あくまで例示としての試算を示します（実際のフレームあたりレンダー時間は解像度、チャンネル数、ノードの複雑さによって大きく変わるため、これはベンチマーク値ではありません）。数十台のワーカーに分散させて一晩でレンダリングする、数千フレームの4Kシーケンスとして妥当な規模感として、合計5,000 GHz時間のCPUコンピュートを消費するコンポジティングバッチは、優先度ティアの倍率を適用する前の基本レートで、コンピュート費用はおおよそ$20になります。同じジョブの一部がGPUアクセラレーションされたノードに依存している場合、その部分はGHz時間レートではなくOBhレートで別途課金されます。予算立てにおいて重要な仕組みは、正確な数字がジョブごとに変わっても単純です。コストは経過時間ではなく、消費した総コンピュートに連動します。したがって、より多くのワーカーにジョブを分散させて早く終わらせても、それだけでコストが変わることはありません。

コンポジティングレンダリング vs 3Dレンダリング：比較表

カテゴリ	3Dレンダリング	コンポジティングレンダリング
主なオペレーション	光の伝搬：サンプリング、レイトレーシング、ノイズ収束	ノードグラフ評価：読み込み、結合、トランスフォーム、書き出し
主なボトルネック	GPUまたはCPUコンピュート（エンジン依存）	CPUスレッディング、メモリ容量、ストレージI/O
並列化の単位	空間単位（タイル/バケット）＋フレームであることが多い	ほぼ常にフレーム単位で、画像領域単位ではない
GPUの関連性	GPUエンジン（Redshift、Octane）ではレンダーの中心	特定のノードサブセットのみオプトイン、大半のオペレーションはCPU専用
典型的な入力	シーンジオメトリ、マテリアル、テクスチャ	マルチレイヤー・マルチパスEXRシーケンス（ビューティ、AOV、クリプトマット）
典型的な出力	ビューティパス＋AOV、フレームあたり複数ファイルであることが多い	少数のコンポジット済み出力、通常は1つの最終EXRシーケンス
典型的な失敗パターン	収束/ノイズ、複雑なシーンでのメモリ、ライセンスの競合	パス/アセットの依存関係、カラー設定のずれ、マルチチャンネル読み込みでのメモリ不足

コンポジティングがより広いクラウドレンダリングパイプラインのどこに位置するか

コンポジティングは通常、3Dレンダーから始まる工程の最終段階であり、この2つの段階をハードウェアやボトルネックについて同じ前提で扱ってしまうことが、クラウドコンポジティングに不慣れなチームからのサポートチケットで最もよく見かける間違いです。パイプラインが完全に3D側にあり、より広いサービスモデルをまだ把握していない場合は、当社のクラウドレンダーファームとは何かというガイドとVFX・プロダクトビジュアライゼーションのクラウドレンダリングガイドがその基礎をカバーしています。コンポジティング段階に特化した内容としては、NukeクラウドレンダリングガイドとAfter Effectsクラウドレンダリング設定ガイドが、本記事があえて一般的な内容にとどめたアプリケーション固有の仕組み（ライセンス、送信フラグ、プラグインマトリクス）を扱っています。「After Effects」については、当社のAfter Effectsクラウドレンダーファームページで、対応ワークフローと料金を直接確認できます。

ほとんどのVFXコンポジティングパイプラインの基盤となるファイル形式についての正式な参照情報としては、OpenEXRプロジェクトが、大半のコンプレンダーが読み書きするマルチチャンネル・マルチパート形式を文書化しており、Cryptomatte仕様がIDマットデータがそれらのファイルにどのようにエンコードされるかを文書化しています。

FAQ

Q: コンポジティングレンダリングは、クラウドファーム上での3Dレンダリングと同じものですか？ A: いいえ。3Dレンダーは光の伝搬を計算し、画像が収束するまでサンプリングと光線追跡を行うもので、この処理はピクセルごとに本当に計算負荷が高いものです。コンポジティングレンダーはすでに存在する画像データ（映像素材、レンダーパス）に対してノードグラフを評価するもので、サンプリングよりもCPUスレッディング、メモリ容量、ストレージI/Oに支配されます。両者はファームのハードウェアを共有しますが、ボトルネックと失敗パターンは異なります。

Q: なぜコンポジティングは3Dレンダリングよりもストレージ I/O に律速されやすいのですか？ A: コンプは通常、フレームごとに1つ以上のマルチレイヤー・マルチパスEXRファイルを読み込み、ファイルが持つすべてのチャンネル（ビューティ、AOV、クリプトマット、デプス）を引き出し、ノードグラフを評価している間、それらのフル解像度フレームを複数同時にメモリ上に保持します。この読み込み量に、コンポジット済みフレームを書き出す処理が加わるため、典型的なコンプの大半のノードでは、生の計算速度よりもストレージスループットとRAM容量のほうがコンプレンダー時間に大きく影響します。

Q: コンポジティングレンダーファームにGPUノードは必要ですか？ A: ほとんどのコンプでは必要ありません。コンポジティングオペレーションの大部分（マージ、グレーディング、キーヤー、トランスフォーム、大半のフィルター）はCPUで実行されます。より限られた特定のノードタイプ（重いリタイム、一部のデノイズ処理、機械学習ツール）はGPUアクセラレーションされており、それらのノードを多用するコンプはGPU容量から恩恵を受けます。典型的なマージとグレーディングが中心のコンプでは、GPUのティアよりもCPUコア数とRAMのほうが重要です。

Q: クリプトマットとは何ですか。クラウドコンポジティングにおいてなぜ重要なのですか？ A: クリプトマットは、3Dレンダーによって書き出される、プロシージャルに生成されたIDマットデータで、3Dシーンを再レンダリングせずに、後からコンポジターが個々のオブジェクト、マテリアル、アセットインスタンスを分離できるようにするものです。クラウドコンポジティングのジョブにおいて、クリプトマットデータはコンプが読み込む入力であり、コンプレンダーが生成するものではありません。クリプトマットを多用するコンプはフレームあたりより多くのチャンネルを読み込むため、レンダーノードのI/Oとメモリの負荷が増加します。

Q: 「Nuke」と「After Effects」のコンプは同じクラウドファームでレンダリングできますか？ A: はい、両方のアプリケーションに対応しているファームであれば可能です。ただし分散モデルは若干異なります。「Nuke」のコンプは設計上ほぼ常にフレーム並列です（各フレームが完全に自己完結しています）。「After Effects」のコンプはほとんどのプロダクションケースでフレーム並列ですが、特定のモーションブラーやパーティクルシミュレーションの設定など、フレームをまたいだ時間的状態に依存するコンポジションは、シームを避けるためにフレームレンジ分散ではなくシングルワーカーレンダリングが必要です。当社のNukeとAfter Effectsのガイドで、アプリケーション固有の仕組みを解説しています。

Q: ローカルでレンダリングする代わりにコンポジティングジョブをクラウドファームに送る意味があるのはどんな場合ですか？ A: クラウドコンポジティングが最も効果を発揮するのは、締め切り駆動のバースト、アーティストのワークステーションを拘束してしまう一晩がかりのバッチ作業、そしてフレームあたりのデータが重い大規模なシーケンス（ディープコンポジティング、4K以上のマルチチャンネルEXR、クリプトマットを多用するコンプ）です。最も効果が薄いのは、締め切りのプレッシャーがなく、ローカルのレンダー時間がすでに自己完結型プロジェクトバンドルをアップロード用に準備する時間よりも短い、少数のシンプルなコンプです。

Q: クラウドファームでコンポジティングレンダリングはどのように課金されますか？ A: 当ファームでは、ほとんどのコンポジティング作業のコストを左右するCPUコンピュートは、GHz時間単位で基本レート$0.004/GHz時間（優先度ティアは最大$0.016/GHz時間）で課金されます。GPUアクセラレーションされたノードは、基本レート$0.003/OBhでOctaneBench時間単位で別途課金されます。コストは経過時間ではなく消費した総コンピュートに連動するため、より多くのワーカーにジョブを分散させて早く終わらせても、それだけで総コストが変わることはありません。

Q: コンポジティングレンダーファームは通常どのようなファイル形式を扱いますか？ A: マルチレイヤー・マルチパートの「OpenEXR」が、VFXパイプラインの入出力の標準です。ビューティパス、AOV、クリプトマット、デプスデータを16ビットハーフフロートで扱い（完全な精度が必要なデータパスには32ビットを使用）します。最終納品物が画像シーケンスではなく動画ファイル（H.264、HEVC、ProRes）の場合、そのエンコードは通常、フレームごとのコンプレンダーの後に別パスとして実行されます。ビデオコーデックは一般に、独立した画像シーケンスのようにはワーカー間で分割できないためです。当社のH.264とH.265のガイドで、その最終エンコード工程を解説しています。