Blender クラウドレンダリング設定ガイド

当ファームでのBlenderはCycles（CPU・GPU/Optix）で動作します。これはBlenderジョブに対応したプロダクションレンダリングエンジンです。Eeveeは利用できません。Eeveeはアクティブなディスプレイコンテキスト（インタラクティブなOpenGL/GPUセッション）を必要とし、当ファームのレンダーノードが動作するヘッドレスサーバーモードでは実行できないためです（「Renderer-specific notes」のEeveeに関する注記を参照してください）。このページでは、プロジェクトのパッケージング（Blenderはアセットパスの処理方法により、他の多くのDCCよりも簡単です）、レンダラー別の注意事項、マルチカメラアニメーションレンダリング、Blender固有のトラブルシューティングについて説明します。

ファームでのBlenderの概要（料金例、GPU対CPUの選択、対応アドオン）については、の記事（Blenderに関する情報を含むV-Ray記事）をご覧ください。RTX 5090でのCycles GPUの具体的なベンチマークについては、をご参照ください。

対応バージョン

Blender 4.0、4.1、4.2（LTS）、4.3、および4.4がすべてのワーカーにプリインストールされています。Blender 4.2 LTSは2026年までバグ修正が提供され、多くのスタジオの安定版ターゲットとなっているため、プロダクション作業にはBlenderのLTSリリースをご使用ください。ファームは.blendファイルの保存バージョンに自動的に対応します。

Blenderのリリースサイクルについて：Blenderは3〜4ヶ月ごとにメジャーリリース、年に1回LTSリリースを提供しています。当ファームは公開から2週間以内に新バージョンのプロビジョニングを行います。BlenderのリリースサイクルはプロプライエタリなDCCよりも速いため、ファームも密接に対応しています。

Blenderプロジェクトのパッケージング

Blenderプロジェクトとは、.blendファイルと外部アセット（テクスチャ、サウンドファイル、シミュレーションキャッシュ、リンクされたライブラリの.blendファイル、環境照明用のEXR HDRIなど）のことです。Blenderのパス解決は他のDCCよりも柔軟（絶対パスと相対パスの両方を使用し、複数の検索場所をフォールバックします）ですが、クラウドレンダリングでは一貫したプロジェクトフォルダにすべてをまとめることをお勧めします。

最も簡単なパッケージング方法は、Blender組み込みの「Pack Into .blend」機能です。

プロジェクトを開きます。 File → External Data → Find Missing Files（ローカルで既に問題がないか確認します）。
アセットを.blendファイルにパックします。 File → External Data → Pack All Into .blend。Blenderはすべてのテクスチャ、サウンド、リンク画像を.blendファイル自体に埋め込みます。
プロジェクトを保存します。 .blendファイルはこれで自己完結型になります。テクスチャ数によっては、元のサイズの10〜100倍になることがあります。
単一の.blendファイルをアップロードします（.blendが数GB未満であればアーカイブは不要です。大きなファイルの場合は.tar.gzまたは.7zにまとめるとアップロードが速くなります）。

アップロードサイズを小さくする2つ目のパッケージング方法は「Make Paths Relative」＋手動フォルダ構成です。

File → External Data → Make All Paths Relative。 すべてのアセットパスが.blendファイルのディレクトリからの相対パスになります。
File → External Data → Report Missing Files でファイルが解決されるか確認します。 レポートに見つからないファイルが表示されないようにしてください。
すべての参照アセットを.blendファイルからの相対サブフォルダに配置します。 標準的な構成：project/scene.blendとproject/textures/、project/cache/、project/hdr/など。
フォルダ全体を.tar.gzまたは.7zにアーカイブしてアップロードします。

相対パス方式は、非常に大きなテクスチャライブラリ（Pack Into .blendで扱いにくい単一ファイルになる場合）や、複数のシーンで同じテクスチャライブラリを再利用するプロジェクトに適しています。

提出前に確認すること

簡単な事前チェックリストです。

アクティブなレンダリングエンジンをCyclesに設定します。 Properties → Render Properties → Render Engineで、ワーカーがCyclesまたはWorkbenchを使用するかどうかが決まります。プロダクションレンダリングではCyclesに設定してください。Eeveeはファームでは対応していません（Renderer-specific notesを参照）。プロジェクトの意図と一致しているか確認してください。
フレーム範囲を設定します。 Properties → Output Properties → Frame Start / Frame End。ファームはこの範囲を正確に処理します。
出力パスには相対トークンを使用します。 デフォルトの//tmp/####.pngで問題ありません。//プレフィックスは「.blendファイルからの相対」を意味します。D:\renders\のような絶対出力パスは避けてください。
出力フォーマットをダウンストリームパイプラインに合わせます。 コンポジット用にはアルファ付きPNGシーケンス、フルパス出力にはOpenEXR Multilayer、直接納品にはFFmpegビデオを使用します。アニメーションレンダリングでは、直接ビデオ出力よりもイメージシーケンスが強く推奨されます。
カラーマネジメントを設定します。 Properties → Render Properties → Color Management。デフォルトのFilmic + sRGBディスプレイはほとんどのプロジェクトで機能します。プロジェクトがACESまたはカスタムOCIOコンフィグを使用している場合は、OCIOコンフィグファイルをプロジェクトフォルダに含め、ワーカーでパスが解決されることを確認してください。
アクティブカメラを設定します。 シーンのアクティブカメラ（Properties → Scene Properties → Camera）がレンダリングするカメラを決定します。意図したカメラと一致しているか確認してください。

レンダラー別の注意事項

Cycles（CPU）

Cycles CPUは、当ファームのDual Intel Xeon E5-2699 V4ワーカーティア（ノードあたり最大256GB RAM）で動作します。GPU VRAMを超えるシーン、非常に大きなテクスチャライブラリを持つシーン、またはCycles CPUが生成する完全にビット精度の出力が必要なプロジェクトに適しています。

設定の注意事項：

ライセンス： Blenderはフリーかつオープンソースなのでファームでのライセンスに関する懸念はありません。
サンプリング： Cycles Render Properties → Sampling → Render Samples。ノイズ閾値0.01のAdaptive Samplingはアニメーションでクリーンな出力を生成します。より高品質なレンダリングには低い閾値（0.005、0.002）を使用しますが、レンダリング時間が増加します。
デノイジング： CyclesはOpenImageDenoise（OIDN）とOptix（GPU専用）に対応しています。OIDNはCPUで動作し、スチルとアニメーションで良好な結果を生成します。Render Properties → Sampling → Denoiseで設定できます。
ライトツリー： Blender 3.4以降には多灯シーン向けのライトツリーサンプリングが含まれています。数百の光源を持つシーンの場合、Render Properties → Samplingで有効にしてください。

Cycles（GPU / Optix）

Cycles GPUは、当ファームのNVIDIA RTX 5090ワーカーティア（カードあたり32GB VRAM）で動作します。ほとんどのシーン（特にヘビーなレイトレーシングを使用するプロジェクト）でCycles CPUよりも大幅に高速です（通常5〜15倍の高速化）。

設定の注意事項：

デバイス： Properties → Render Properties → Device → GPU Compute。OptixバックエンドはデフォルトでNVIDIA GPUのRTコアを使用し、ワーカーでデフォルトで有効になっています。
VRAMの制約： ワーカーあたり32GB VRAMは、ほとんどの建築ビジュアライゼーションおよびアニメーションプロジェクトに十分です。VRAMの上限に近づいているプロジェクトでは、Render Properties → PerformanceのPersistent Dataオプションでフレームごとのロード時間を短縮できますが、ピークVRAM使用量が増加します。32GBを超えるプロジェクトでは、Cycles CPUに切り替えるか、シーンをレンダリング可能なチャンクに分割してください。
Optixデノイザー： アニメーションではOIDNより高速です。Render Properties → Sampling → Denoise → Use OptiXで設定できます。NVIDIAのGPUが必要です（当ファームのワーカーティアで利用可能です）。

Eevee（未対応）

Eeveeはファームでは使用できません。Eeveeはアクティブなディスプレイコンテキスト（インタラクティブなOpenGL/GPUセッション）を必要とし、当ファームのレンダーノードが動作するヘッドレスサーバーモードでは実行できないため、Eeveeレンダリングは対応していません。アクティブエンジンがEeveeに設定されているプロジェクトはレンダリングできません。提出前にレンダリングエンジンをCyclesに切り替えてください。

Eeveeの高速なリアルタイム風の見た目が必要な場合は、ローカルでレンダリングしてください。クラウドレンダリングでは、RTX 5090フリートのCycles GPU（Optixデノイザー使用）が物理的に正確な出力で高速なイテレーションを実現します。これがファームでのBlenderの推奨プロダクションエンジンです。

Cycles CPU対Cycles GPU — どちらを選ぶか

RTX 5090ティアのCycles GPUがデフォルトです。フレームあたりCycles CPUより通常5〜15倍高速で、32GB VRAM内でほとんどの建築ビジュアライゼーション、アニメーション、レイトレーシング重視のシーンを処理できます。シーンが32GB VRAMを超える場合、非常に大きなテクスチャライブラリに依存している場合、またはCPUパスが生成する完全にビット精度の出力（ノードあたり最大256GB RAM）が必要な場合はCycles CPUを選択してください。どちらも同じ物理的に正確なCyclesの結果を生成します。GPUはフレームあたりの処理が速く、CPUはより大きなメモリ上限を持ちます。

マルチカメラアングルのレンダリング

単一の提出で複数のカメラアングルから同じシーンをレンダリングする必要があるプロジェクトでは、Blenderは2つのパターンに対応しています。

パターン1：異なるアクティブカメラを持つ複数のシーン

Blenderでは1つの.blendファイルに複数のシーンを含めることができます。各シーンは独自のアクティブカメラとレンダリング設定を持てます。

プロジェクトで、カメラアングルごとに新しいシーンを作成します（Scene → New Scene → Link Objects）。
各シーンのアクティブカメラを対応するカメラに設定します。
提出時、ファームは提出時に「アクティブ」として設定されているシーンをレンダリングします。複数のシーンをレンダリングするには、それぞれを別々のジョブとして提出してください。

パターン2：カメラごとのビューレイヤー（Blender 2.8以降）

多くのカメラアングルに対してより効率的なパターンは、異なるアクティブカメラでビューレイヤーを使用することです。

Properties → View Layerで、カメラアングルごとにビューレイヤーを作成します。
Properties → Output Properties → Output → Use Multi-Viewで、ステレオまたはマルチビューを設定します（該当する場合）。
出力ファイル名に{layer}トークンを使用して、ビューレイヤーごとに出力パスを設定します。
提出すると、ワーカーは有効なすべてのビューレイヤーを1パスでレンダリングします。

典型的な建築ビジュアライゼーションのターンテーブル（8〜16のカメラアングル）では、パターン2の方が大幅に効率的です。シーンはフレームごとに1回だけロードされ、同じロードされたシーンからすべてのビューをレンダリングするためです。

提出フロー

Blenderプロジェクトには3つの提出チャネルがあります。

ウェブアップロード＋ダッシュボードから提出。 パックされた.blend（またはアーカイブされたプロジェクトフォルダ）をアップロードし、ウェブサイトから提出します。Blenderユーザーに最も一般的な提出方法です。
クライアントアプリ。 1つのラッパーでアップロード＋提出＋自動ダウンロードができます。
提出プラグイン。 Blender内からワンクリックで提出するためのBlenderアドオンが利用できます。アカウントダッシュボードからインストールしてください。

DCC横断的なアップロード・提出・ダウンロードのフローについては、をご参照ください。

Blender固有のエラーのトラブルシューティング

DCCに共通する一般的なトラブルシューティングについては、をご参照ください。Blender固有のケース：

シーン内の一部のオブジェクトがレンダリングされない。 最も一般的な原因：オブジェクトの「レンダー可視性」トグルが無効になっています。アウトライナーでオブジェクトの行にカーソルを合わせ、カメラアイコン（レンダーで非表示）が有効になっているか確認してください。オブジェクトが非表示のビューレイヤーにないかも確認してください。
Pack Into .blendにもかかわらずテクスチャが見つからない。 最新のテクスチャ変更後にPack All Into .blendが実行されたか確認してください。パック後にテクスチャをリロードした場合、外部参照に戻っている可能性があります。再パックして再保存してください。
レンダリング結果が黒または間違った色になる。 カラーマネジメント設定（Properties → Render Properties → Color Management）を確認してください。最も一般的な原因はビュートランスフォームの不一致です。ワークステーションとワーカーの両方で同じビュートランスフォーム（Filmicがデフォルトかつ安全な選択肢）を使用していることを確認してください。
Cycles GPUジョブがCPUで実行される。 Properties → Render Properties → DeviceがGPU ComputeではなくCPUに設定されていないか確認してください。シーンがハードウェアレイトレーシングアクセラレーションを必要とする場合、Optixバックエンドが選択されていることも確認してください。
カスタムOSLシェーダーがレンダリングに失敗する。 CyclesはOSL（Open Shading Language）に対応していますが、カスタムOSLシェーダーはプロジェクトアーカイブに含める必要があります。OSLシェーダーファイル（.osl）はワーカーが見つけられる場所に置く必要があります。最も簡単なのは、.blendと同じフォルダに置いて相対パスで参照することです。
ワーカーにアドオンがない。 一般的なアドオン（Animation Nodes、BlenderKit、Sverchok、FLIP Fluidsなど）はプリインストールされていない場合があります。Animation Nodesや同様のプロシージャルアドオンについては、提出前にプロシージャルジオメトリをメッシュにベイクすることが回避策です。他のアドオンについては、ワーカーイメージへの追加についてサポートにお問い合わせください。

FAQ

Q: ファームが対応しているBlenderのバージョンはどれですか？ A: Blender 4.0、4.1、4.2 LTS、4.3、および4.4がすべてのワーカーにプリインストールされています。Blenderのリリースサイクルに追従し、公開から2週間以内に新バージョンをプロビジョニングします。Blender 4.2 LTSは2026年までバグ修正が提供されるため、プロダクション作業に推奨されます。 Q: ファームでEeveeシーンをレンダリングできますか？ A: いいえ。Eeveeはアクティブなディスプレイコンテキストを必要とし、ファームが使用するヘッドレスレンダーノードでは動作しないため、Eeveeレンダリングは対応していません。提出前にレンダリングエンジンをCyclesに設定してください。高速なイテレーションには、RTX 5090フリートのCycles GPU（Optixデノイザー使用）が同じシーンでCycles CPUより通常5〜15倍高速なため、シーンが32GB VRAMを超えない限りGPUがデフォルトの推奨です。 Q: BlenderKit / Sverchok / Animation Nodesを使用したシーンはレンダリングできますか？ A: ダウンロード済みで.blendに保存されたBlenderKitアセットは問題なくレンダリングできます（配置後は標準メッシュデータになります）。SverchokとAnimation Nodesはプロシージャルです。プロシージャルジオメトリが静的メッシュにベイクされていない場合、ワーカーが予期しない出力を生成する可能性があります。提出前にプロシージャルジオメトリをメッシュにベイクしてください（Sverchok：Set/Bake to Mesh、Animation Nodes：アクションにベイク）。 Q: テクスチャを.blendにパックする必要がありますか、それとも別ファイルとしてアップロードできますか？ A: どちらでも問題ありません。Pack Into .blendは単一の自己完結型ファイルになるため最も簡単です。相対パス＋フォルダ構成は、Pack Into .blendで扱いにくい単一ファイルになる非常に大きなテクスチャライブラリに適しています。いずれの方法でも、まず「Find Missing Files」を実行してローカルで問題がないことを確認してください。 Q: レンダリングは完了しましたが、ワークステーションのビューポートと色が異なります。 A: ほとんどの場合、カラーマネジメントまたはビュートランスフォームの不一致が原因です。Properties → Render Properties → Color Managementをワークステーションで確認し、保存された設定にView Transform: Filmic（デフォルト）が含まれているか確認してください。ルックトランスフォーム（高コントラスト、低コントラストなど）と露出値も.blendに埋め込まれており、ワーカーに適用されます。 Q: アニメーションをレンダリングしています。ビデオファイルまたはイメージシーケンスへの出力どちらが良いですか？ A: ほぼ常にイメージシーケンスです。アルファ付きPNG（コンポジット用）またはOpenEXR Multilayer（フルパス用）が標準です。直接ビデオ出力（FFmpeg）はファーム全体での並列処理に適していません。ジョブを受け取ったワーカーがすべてのフレームを順次レンダリングして1つのビデオファイルにエンコードします。イメージシーケンスを使用すると、ファームが複数のワーカーにフレームを並列分散でき、100フレームを超えるアニメーションでは大幅に速くなります。 Q: プロジェクトにカスタムOSLシェーダーが含まれています。ファームで動作しますか？ A: はい、.oslシェーダーファイルがプロジェクトアーカイブに含まれており、シェーダーノードで相対パスで参照されていれば動作します。最も簡単なパターンは、すべての.oslファイルを.blendファイルと同じフォルダに置くことです。 Q: ファームでのGPUレンダリングはCPUと比較してコストはどうですか？ A: GPUレンダリングはフレームあたりの処理が通常高速（Cyclesでは5〜15倍）ですが、GPU機器は高価なためワーカーあたりのコストは高くなります。レンダリング全体のコストは、ほとんどのシーンでCycles CPUとCycles GPUでほぼ同等です。GPUはフレームあたりの処理が速いですが、1分あたりのコストは高くなります。シーンに基づく具体的なコスト見積もりには、でフレームおよびジョブごとの比較ができます。 Q: Blenderのシミュレーション（流体、煙、ヘア）をファームでレンダリングできますか？ A: シミュレーションの場合、まずローカルでキャッシュファイルをベイクし、プロジェクトのアップロードに含める必要があります。ファームはベイクされたキャッシュに対してフレームをレンダリングします。ライブシミュレーションは実行しません。これはすべてのDCCに共通する標準パターンです。シミュレーションのベイクはワークステーションで行い、フレームレンダリングはファームで行います。

クラウドレンダリング向けBlenderのセットアップ