V-Ray 6 クラウドレンダーファーム：2026年実践ガイド

はじめに

V-Rayはプロダクションレンダリングの分野で20年以上にわたって使われてきたソフトウェアであり、V-Ray 6 は今もなお多くのスタジオが日常的に使用しているバージョンです。新しいメジャーリリースが登場しても、パイプラインの検証には時間がかかります。来週納品しなければならない4Kの建築ビジュアライゼーション案件が、バージョン移行を待ってくれることはありません。そのため、V-Ray 7が登場した現在でも、V-Ray 6 クラウドレンダーファームに届くシーンの多くは、バージョン6でビルド・ライティング・承認されています。そして、それらのシーンはワークステーション1台と同じように、数千コアのマシンでも正確に再現されなければなりません。

最後の点こそが、多くのトラブルの原因となっています。作成したマシン上では完璧にレンダリングできるV-Ray 6のシーンでも、プロジェクトフォルダを一度も見たことのないワーカーノード群にフレームを分散させた瞬間に、フリッカーが発生したり、アセットが欠落したり、意図しないエンジンにサイレントフォールバックしたりすることがあります。Super Renders Farmでは、どのステップがこの移行を乗り越えられるか、どのステップが破綻するかを長年にわたって観察してきました。本ガイドでは、実際にレンダリングを行う人にとって重要なV-Ray 6の変更点、対応しているホストアプリケーションごとの動作、V-Ray GPUとV-Ray CPUの使い分け（スケールアウト時の違い）、そして分散フレームをクリーンに仕上げるためのシーンパッケージング方法について解説します。自分でレンダーライセンスを購入したり、マシンにリモート接続してキューを監視したりする必要は一切ありません。

実際にレンダリングする人にとってのV-Ray 6の変更点

V-Ray 6の議論の多くは、モデリングやルックデブの利便性に焦点を当てています。レンダーファームで重要なのはより限定的な話です。レンダーノードの処理量、転送するファイルサイズ、必要なインストールプラグインを変化させる機能に絞られます。V-Ray 6のサイクルの中で、ファームに直接関係するものがいくつかあります。

Enmeshは、ソースメッシュをレンダリング時に面全体にタイル状に配置します。ジオメトリをシーンにベイクするのではなく、チェーンメール、穴あきファサード、織物、グレーティングなどを表現します。ジオメトリはファイルに保存されるのではなく、レンダリング中にノード上で生成されるため、各ワーカーに送られる .vrscene ファイルは小さいままです。重いジオメトリはレンダリングメモリ内にのみ存在します。これはレンダーファームにとって大きなメリットです。ネットワーク転送量が減り、RAMの使用量が保存ファイルではなくレンダリング処理に連動します。

Chaos Scatterは、V-Ray本体にネイティブのスキャタリング機能をもたらしました。植生、岩、地面の植被物などをレンダリング時にプロシージャルに解決します。ファーム側の利点は依存関係の削減です。Chaos Scatterでスキャタリングされたシーンは、すべてのノードにサードパーティのスキャタープラグインがライセンス済みでインストールされている必要がなく、フレームがワーカーに割り当てられたときに欠落する要素が一つ減ります。

V-Ray Decalsは、UVやトポロジーに手を加えることなく、マテリアルをサーフェスに投影します。ラベル、ステッカー、表面の傷、サイネージなどを表現できます。これらはV-Rayのパイプライン内で完結して解決されるため、ノードにはデカールのテクスチャマップへのアクセスのみが必要です。

プロシージャルスカイとボリューメトリッククラウドは、固定HDRIではなくパラメーターとして空を構築でき、クラウドはシーン内で本物のボリュームとして機能します。これらのレンダリングはフレームあたりの処理が重くなりますが、完全にフレームパラレルです。各ノードは隣接ノードに依存せずに独自のフレームを計算するため、クリーンに分散できます。注意点はV-Ray GPUのメモリです。密なボリューメトリックスカイはVRAMを消費するため、複雑なスカイはCPUの方が安全なことが多いです。

V-Ray Frame Bufferもレンダーファームのパイプラインで引き続き重要な役割を果たします。Light Mixにより、保存されたレンダーエレメントから、再レンダリングなしに個々のライトやライトグループをレンダリング完了後に分離・調整できます。ディレクターがシーケンス完了の翌日に「キーライトを温かく、フィルライトを落として」と要求した場合、その調整はコンポジティングで行われ、キューに戻す必要がありません。これはコスト面で最も負担の少ない変更です。そしてChaos Cosmosは内蔵アセットライブラリとしてビューポートでは便利ですが、私たちが最もよく見るファームの失敗原因を引き起こします。これはワークフローのセクションで詳しく説明します。正しく対処する価値があるためです。

レンダリング対応DCCにおけるV-Ray 6

V-Ray 6は別々のホストアプリケーションに対して別々のインテグレーションとして提供されますが、ファームに関連する重要な事実は、すべてが同じディスパッチフォーマット（V-Ray Standaloneでレンダリングされる .vrscene ファイル）に集約されるということです。モデリングに使用するホストはワークフローに影響しますが、書き出されたシーンを実行するだけのノードにはほとんど関係しません。

私たちのレンダーファームでV-Rayをレンダリングするホストアプリケーションは、3ds Max、Maya、Cinema 4D、Houdiniです。3ds MaxとV-Rayは建築ビジュアライゼーションのワークホースであり、最もよく見られるパス（インテリア、エクステリア、プロダクトビジュアライゼーション）です。MayaとV-RayはVFXとアニメーションパイプラインをカバーします。Cinema 4DとV-Rayはモーションとデザインスタジオに対応します。Houdini VFX向けのV-Rayはプロシージャルで構築されたシーンに対応しており、VEXとノードドリブンのジオメトリはエクスポート時にエクスポートされたシーンに解決されます。アプリケーションごとの詳細は、3ds Max、Maya、Cinema 4D、Houdiniのランディングページと、V-Ray クラウドレンダーファームページをご参照ください。

正直にお伝えすべき2つの制限事項があります。SketchUpにはV-Rayインテグレーションがありますが、SketchUpは私たちのファームで実行しているホストアプリケーションではありません。SketchUpユーザーにはクリーンな方法があります。V-Ray for SketchUpは .vrscene を直接エクスポートでき、そのファイルは3ds Maxからエクスポートしたものと同様にV-Ray Standaloneでレンダリングされます。つまり、私たちのサイドにSketchUpをインストールすることなくシーンをファームに届けられます。代替手段としては、モデルを3ds Maxに取り込んでマテリアルを再リンクし、そちらからエクスポートする方法もあります。より手間がかかりますが、クリーンアップのための3ds Maxのフルツールセットを使用できます。いずれの場合も、レンダリングはSketchUp内ではなく、サポートされているホストのエクスポートを通じて行われます。

もう一つの制限事項はBlenderです。私たちのレンダーファームでは、BlenderシーンはV-RayではなくBlenderのネイティブプロダクションレンダラーであるCyclesでレンダリングされます。そのため、V-Rayのパイプラインをお使いの場合は上記4つのホストをご使用ください。Blenderの場合はCyclesを使用することになり、それは別のワークフローです。

ファームでのV-Ray GPUとV-Ray CPU：実際の判断基準

V-Ray 6は、マテリアルとライティングを共有しながら、スケールアウト時の動作が大きく異なる2つのレンダリングエンジンを提供します。間違ったエンジンを選択することはファームで最もコストのかかるミスの一つです。フレームが返ってくるまで気づかないことが多いためです。

単純な事実から始めましょう：V-Rayの作業の大半は依然としてCPUの仕事です。私たちが見るジョブの約70%はCPUレンダリングです（V-Ray (CPU)、Corona、Arnold CPU）。その大部分は建築ビジュアライゼーションです。V-Ray CPUは物理コア数にほぼ線形にスケールするため、コア数の多いサーバーに非常に適しています。私たちのCPUフリートは、デュアル Intel Xeon E5-2699 V4マシンで構成され、それぞれ96〜256 GBのRAMを搭載し、合計20,000以上のCPUコアを持っています。ワークステーションで数時間かかる4Kインテリアシーンが、このプールにフレームごとに分散されます。重要な点として、CPUレンダリングはVRAMではなくシステムRAMにアクセスするため、4Kおよび8Kの PBRマテリアルが多用されたテクスチャ量の多いインテリアでも、GPUのようなメモリの壁にぶつかりません。大規模な最終品質の建築ビジュアライゼーションでは、CPUが安全なデフォルト選択です。

V-Ray GPUは残りの30%を占め、シーンが適合する場合は本当に高速です。2つのモードで動作します。広く互換性のあるCUDAモードと、RTXクラスのNVIDIA GPU上のハードウェアレイトレーシングコアを使用してシーン依存の高速化を実現するRTXモードです。私たちのGPUマシンはそれぞれ32 GBのVRAMを搭載したRTX 5090カードを使用しており、このVRAM数値がすべてを物語っています。VRAMはGPUレンダリングの主要な制約です。シーンのジオメトリとテクスチャが収まれば、V-Ray GPUはイテレーションや中程度の複雑さのインテリアに優れています。24 GB（典型的なハイエンドワークステーションカード）から32 GBへの移行は、シーンが完全にメモリに収まるかどうかの差であり、オンメモリとデータをページイン/ページアウトしなければならないアウトオブコアの差です。アウトオブコアはパフォーマンスコストを伴います。24 GBカードでページングが発生していたシーンでは、単純にヘッドルームがあることが高速化の大部分を占めることがあります。私たちはRTX 5090ハードウェアでこれを実測しました。詳細はV-Ray GPU速度テストとRTX 5090レンダリングパフォーマンスの記事をご覧ください。GPUクラウドレンダーファームページではこれらのノードのセットアップについて説明しています。

選択の基準をまとめると：

V-Ray GPUを選択する場合	V-Ray CPUを選択する場合
シーンのジオメトリとテクスチャがVRAMに収まる（もしくはほぼ収まる）場合	シーンがアウトオブコアでもVRAMを超える場合（大規模な都市セット、100 GB以上のテクスチャ）
高速なイテレーションとクイックテストフレームが必要な場合	最終納品に向けて最も成熟した機能セットが必要な場合
中程度の複雑さのインテリア・プロダクトビジュアライゼーション	GPUパリティにまだ不足している機能を使用するレンダリング
特にGPUノードでレンダリングする場合	主にCPUプールで予測可能な動作を望む場合

V-Ray 6は、同一ノード上のCPUコアとGPUが1つのレンダーに貢献するハイブリッドモードもサポートしています。GPUシーンがメモリ予算のギリギリにある場合に便利です。避けるべきことは「GPUは常に速い」と思い込むことです。大規模でテクスチャ量の多い建築ビジュアライゼーションシーンでは、V-Ray CPUがメモリの上限と戦わないため、全体として頻繁に高速です。シーンに合わせてエンジンを選択してください。流行に流されてはなりません。

V-Ray 6シーンをレンダーファームでクリーンにレンダリングするために

ここがフレームを使用可能な状態で取り戻せるかどうかを決める部分です。メカニズム自体は複雑ではありませんが、いくつかはサイレントに失敗します。これが最悪の失敗の仕方です。

ディスパッチパス。 V-Rayをレンダーファームでレンダリングするためのカノニカルな方法は、シーンを .vrscene としてエクスポートし、各ノード上でV-Ray Standaloneにレンダリングさせることです。重要な結果はライセンスの取り扱いです。V-Ray Standaloneを実行しているワーカーはレンダリングのために3ds Max、Maya、またはCinema 4Dのライセンスを必要とせず、必要なのはV-Rayのみです。私たちのレンダーファームでは、これらのレンダーライセンスはレンダリングに支払う料金に含まれています。独自のライセンスを持参する必要も、何もインストールする必要もありません。これが「フルマネージド」の実際の意味です。リモートデスクトップ接続も、ライセンスサーバーの監視も、ノードごとのソフトウェアセットアップも不要です。これはインフラレンタルモデルとの明確な違いでもあります。インフラレンタルモデルでは、ベアマシンをレンタルして自前でライセンスを用意する必要があります。

フレーム分散とDistributed Renderingの違い。 この2つは常に混同されます。レンダーファームはノード間にフレーム全体を分散します。ノードAがフレーム1をレンダリングし、ノードBがフレーム2をレンダリングするという形です。V-RayのDistributed Rendering（DR）は別の仕組みです。複数のマシンが単一フレームのバケットをネットワーク経由でリアルタイムに分割して協調作業します。DRはスタジオが1枚の巨大なヒーローフレームのために使うツールです。ネットワーク遅延が加わり、あらゆる場所で同一のV-Rayバージョンが必要であり、スケールでは効率が低下します。アニメーションや画像シーケンスの事実上すべてのケースでは、フレーム分散が適切なモデルであり、これがレンダーファームがデフォルトで行うことです。

フリッカーのないGI。 アニメーションではこの選択が問題を引き起こします。Brute Force GIとフレームごとのLight Cacheの組み合わせは、フレームごとに独立してライティングを計算します。フレームあたりは遅くなりますが、フリッカーがなく、フレーム間の依存関係もありません。そのため任意のノードが任意の順序でフレームをレンダリングできます。これが分散アニメーションに推奨するフリッカーセーフなデフォルトです。Irradiance Mapアプローチはフレームあたりが速くなります。GIソリューションを事前計算して再利用するためです。ただし、これはライトとオブジェクトが静止したカメラフライスルーアニメーションにのみ適用でき、すべてのノードが共有パスから同じ事前計算マップを読み取る必要があります。典型的な失敗パターン：マップが C:\Users\artist\scene.vrmap などのローカルパスに保存されており、ノードがそれを見つけられないため、すべてのフレームがGIをサイレントに再計算します。これがまさに避けようとしていたフリッカーを引き起こします。Irradiance Mapを使用する場合は、一度ベイクし、ファイルをジョブと一緒に送り、パスを変更してください。不明な場合はBrute Forceを使用してください。

デノイジング。 V-Ray 6はV-Ray Denoiser（CPU）、NVIDIA AI Denoiser（ノードにNVIDIA GPUが必要）、Intel Open Image Denoise（CPU、どこでも動作）の3つを提供します。3つともフレームごとにフレーム間の状態なしで動作するため、完全な並列レンダリングに対して安全です。標準的なアドバイスは：常にデノイジング済み出力と一緒に、未デノイジングの生のビューティーパスを保存することです。デノイザーが細部を潰してしまった場合、シーケンスを再レンダリングするのではなく、ポストでデノイズし直すことができます。

Chaos Cosmosアセット — サイレントキラー。 これは新規ユーザーにとって最も一般的なV-Ray 6ファームの失敗原因であり、サイレントに失敗します。CosmosアセットはローカルのCosmosキャッシュにダウンロードされます。.vrscene をエクスポートすると、これらのアセットはローカルパスで参照されます。ノードにはCosmosキャッシュがないため、ファイルが存在しないシーンが指定されます。結果として、植生が欠落したり、プロップがグレーになったり、スカイが空白になったりしますが、ハードエラーは出ません。修正方法は、送信前にアセットを収集することです。V-Rayのアセット収集／「プロジェクトのパック」ツールを使用して、すべてのCosmosおよびテクスチャファイルをシーンの隣の1つのフォルダにまとめ、すべてを相対パスに変更します。そうすれば、ジョブは完全に自己完結します。スキップすると再レンダリングが必要になります。通常のテクスチャにも同じ規律が適用されます。絶対ローカルパスで参照されているものはすべて、欠落アセットになる可能性があります。

アップロード。 プロジェクトを .tar.gz または .7z でパックしてください。.zip アーカイブはアップロードに対応していないため、zipされたプロジェクトを送る前に再パックしてください。非常に大きなシーンの場合、SFTPまたはデスクトップクライアントの方がブラウザアップロードより安定しています。レンダー出力は45日間利用可能なため、完成したフレームは早めにダウンロードするか、クライアントの自動ダウンロードを使用してください。

送信前のプリフライトチェックリスト

ほとんどのファームレンダリングの失敗は、4〜5つの繰り返し発生する原因にたどり着きます。2,000フレームのシーケンスをコミットする前にファームで1枚のテストフレームをレンダリングすれば、数分でほぼすべてを発見できます。私たちがユーザーにお伝えしている簡易版です：

チェック項目	ファームでの重要性	クイック修正
アセットを収集・パスを変更済み	絶対ローカルパス（テクスチャ、Cosmos）= ノード上でアセット欠落	プロジェクトをパック／アセットを相対パスに収集
GI方法を意図的に選択	動くシーンのIrradiance Map = フリッカー	アニメーションはデフォルトでBrute Force + Light Cache
エンジンがシーンに合っている	VRAMオーバーのGPUシーンは停止、CPUシーンをGPUで動かすと無駄	フレームバッファでVRAM需要を確認
生のパスとデノイズ済みパスを保存	悪いデノイズがあれば再レンダリングが必要になる	ビューティーとデノイズ済みエレメントの両方を出力
ファームで1枚テストフレームをレンダリング	ローカル成功 ≠ ファーム成功	フレーム1を送信して確認、その後レンジを送信
.tar.gz / .7zでプロジェクトをパック	.zipは対応外	アップロード前に再パック

コストはエンジンをまたいで同じユニット単位の論理に従うため、見積もりは簡単です。CPUレンダリングは$0.004/GHz時間、GPUレンダリングは$0.003/OctaneBench時間で課金され、すべてのレンダーエンジンライセンスはその料金に含まれています。新規アカウントには上記のような単一フレームテストを実行するための$25の無料レンダークレジットが付与され、クレジットは有効期限なしです。詳細な料金は料金ページをご覧ください。プロバイダーの比較を検討している場合は、V-Ray向けレンダーファームの比較記事で選定基準を紹介しています。

FAQ

Q: V-Ray 7にアップグレードせずにV-Ray 6をクラウドレンダーファームでレンダリングできますか？ A: はい。V-Ray 6のシーンはエクスポートされた .vrscene を通じてV-Ray Standaloneでレンダリングされるため、先に新しいメジャーバージョンへの移行は必要ありません。多くのプロダクションパイプラインは意図的にV-Ray 6を使用し続けており、レンダーファームはシーンが構築・承認されたバージョンでレンダリングします。

Q: クラウドレンダリングのために独自のV-Rayライセンスを購入する必要がありますか？ A: いいえ。私たちのレンダーファームでは、V-Rayレンダーライセンスはユニットごとのレンダー料金に含まれているため、レンダリングのために別途ライセンスを持参・支払いする必要はありません。これがフルマネージドファームとインフラレンタルモデルの違いです。インフラレンタルモデルでは、マシンをレンタルして自分でソフトウェアライセンスを用意する必要があります。

Q: レンダーファームではV-Ray GPUとV-Ray CPU、どちらを使うべきですか？ A: シーンのジオメトリとテクスチャがVRAMに収まり、インテリアやイテレーションのスピードが必要な場合はV-Ray GPUを選択してください。シーンが大規模でテクスチャ量が多い場合、または最終納品に最も成熟した機能セットが必要な場合はV-Ray CPUを選択してください。CPUはVRAMではなくシステムRAMにアクセスするため、GPUを低速なアウトオブコアページングに追い込むような大型の建築ビジュアライゼーションシーンを処理できます。

Q: 多数のノードに分散させたV-Ray 6アニメーションでGIフリッカーを防ぐにはどうすればよいですか？ A: デフォルトとしてBrute Force GIとフレームごとのLight Cacheを使用してください。これにより各フレームに対して独立してライティングが計算されるため、分散ノード間で不一致が発生しません。Irradiance Mapはライトとオブジェクトが静止したカメラフライスルーのみに使用し、事前計算されたマップがすべてのノードから読み取れる共有パスにあることを確認してください。

Q: ファームからフレームが返ってきたときにChaos Cosmosアセットが欠落しているのはなぜですか？ A: Cosmosアセットは自身のキャッシュにのみ存在するローカルパスで参照されているため、レンダーノードがそれらを見つけられず、オブジェクトはグレー、欠落、または空白でレンダリングされますが、ハードエラーは出ません。送信前にV-Rayのアセット収集ツールを使用して、すべてのアセットを自己完結するプロジェクトフォルダに収集・再パスしてください。これによりシーンが必要なものをすべて持ち運びます。

Q: V-Ray for SketchUpのシーンをレンダーファームでレンダリングできますか？ A: はい、エクスポートを経由することで可能です。SketchUpは私たちが実行しているホストアプリケーションではありませんが、V-Ray for SketchUpはV-Ray Standaloneで直接レンダリングできる .vrscene をエクスポートできます。または3ds Maxにモデルを取り込んでそちらからエクスポートすることもできます。レンダリングはSketchUp内ではなく、サポートされているホストのエクスポートされたシーンを通じて行われます。

Q: レンダーファームとV-Ray Distributed Renderingの違いは何ですか？ A: レンダーファームは多数のマシン間でフレーム全体を分散させます。これはアニメーションと画像シーケンスに適した効率的なモデルです。V-Ray Distributed Rendering（DR）は代わりに、単一フレームのバケットをリアルタイムでマシン間に分割します。1枚の非常に大きなヒーローフレームには便利ですが、スケールでは遅く不安定であり、ファームでシーケンスをレンダリングする方法ではありません。