Blender レンダリングエンジン分析: Cycles と Eevee のアーキテクチャ、パフォーマンスダイナミクス、およびユースケース
コンピューターグラフィックス（CG）においてレンダリングエンジンとは、仮想シーンの数学的データを二次元ピクセルに変換する複雑なソフトウェアアルゴリズムです。3Dコンテンツ制作プロセスにおいて業界標準となったオープンソースソフトウェア「Blender」は、ユーザーに Cycles と Eevee という2つの主要なレンダリングエンジンを提供しています 1 。どちらのエンジンも「物理ベースレンダリング」（Physically Based Rendering - PBR）の原則に基づいているものの、光の計算方法、処理能力の要件、そして最終的な視覚的出力のリアリズムのレベルの点で互いに完全に異なります 1 。これら2つのエンジンの存在により、Blender はフォトリアルなビジュアライゼーションの専門家にとっても、リアルタイムアニメーションスタジオにとっても不可欠なツールとなっています 3 。このレポートでは、なぜ Cycles がフォトリアルである一方で計算面で非常に重いのか、そしてなぜ Eevee（および次世代の Eevee Next アーキテクチャ）が信じられないほど高速であるにもかかわらず特定のリアリズムの限界に行き当たるのかを、アーキテクチャ、数学、およびハードウェアのレベルで深く検証します。最新のハードウェアアクセラレーション（OptiX、HIP、Metal）、パスガイディング（Path Guiding）、AI支援によるノイズ除去（Denoising）、およびスクリーンスペース（Screen Space）アルゴリズムがこれら2つのエンジンに与える影響を詳細に分析し、プロフェッショナルな制作ワークフローにおいてどのエンジンをどのような状況で選択すべきかを明らかにします。
1. アーキテクチャの基礎：パストレーシング（Path Tracing）とラスタライゼーション（Rasterization）の数学
Blenderのレンダリングエンジン間における溝の根本には、光がデジタル環境でどのようにシミュレートされるかに関する、ラディカルに異なるアプローチが存在します。Cyclesは、光が物理法則に従って空間をどのように移動するかを計算する統計的モデルを使用する一方、Eeveeは、3Dジオメトリを2D画面に投影して光を予測する一連のアルゴリズムに依存しています。
1.1. Cycles：後方パストレーシング（Backward Path Tracing）アーキテクチャ
Cyclesは、プロダクションレベルのフォトリアルティを目標とする、物理ベースのパストレーサーエンジンです 1 。その核心において、レンダリング方程式（rendering equation）をモンテカルロ積分と呼ばれるランダムサンプリング手法で解くことによって動作します 7 。現実世界では、光源（例えば太陽や電球）から何兆もの光子が飛び出し、これらの光子は表面に衝突し、バウンドし、そのごく一部がカメラのレンズに到達します。デジタル環境で光源から発せられるこれら何兆もの光子を計算することは、膨大なデータの無駄とハードウェアの不足につながるため、Cyclesは「逆光線追跡」（backward ray tracing）のロジックで動作します 8 。このシステムでは、エンジンはカメラのビューファインダー内の各ピクセルの中心からシーンに向けて仮想的な光線（rays）を放ちます 8 。光線がシーン内のオブジェクトに衝突すると、オブジェクトのマテリアル特性を定義する双方向散乱分布関数（BSDF - Bidirectional Scattering Distribution
Function）に従って異なる応答を示し、方向を変えます 1 。Cyclesエンジンは、これらの複雑な光線の相互作用を基本的に4つのメインカテゴリに分類して処理します。
● カメラレイ（Camera Rays）：カメラから直接発せられ、シーンジオメトリと最初に接触する一次レイです 1 。
● 反射レイ（Reflection Rays）：表面から反射するレイです。表面の微細な粗さ（roughness）に応じて、拡散（Diffuse）、光沢（Glossy）、または完全鏡面（Singular）のサブカテゴリに分類されます 1 。
● 透過・屈折レイ（Transmission Rays）：ガラス、水、透明なプラスチックなどの表面を通過するレイです。光が媒質を変更する際に速度が変化する原則（屈折率 - IOR）に従って方向を変えます 1 。
● 影レイ（Shadow Rays）：表面が照らされているかどうかをテストするために、衝突点から光源に向かって放たれる透明度テストレイです 1 。これらの光線の挙動は、無限ループの中でシーン内をバウンド（bouncing）し続けます。しかし無限の計算は不可能なため、エンジンが特定のバウンド制限、または「ロシアンルーレット」（Russian Roulette）と呼ばれる確率的終了アルゴリズムに達すると、光線の旅は終了します。多数の光線（サンプル - sample）を放つことは、ピクセルの色の平均が現実の最も近い値に収束（convergence）することを保証し、これにより画像内のザラつき（ノイズ）が減少しますが、処理時間が直接的かつ線形的に増加します 6 。
1.2. EeveeとEevee Next：リアルタイムラスタライゼーション（Rasterization）とハイブリッドアプローチ
EEVEE（Extra Easy Virtual Environment Engine）は、フォトリアリズムよりも速度とインタラクティビティに焦点を当てた、元々はOpenGLベースで構築されたリアルタイムレンダリングエンジンです 2 。Cyclesとは異なり、Eeveeは基本的に各光線のシーン内の何兆もの可能なパスを計算しません。その代わりに、コンピュータゲームで標準となっている「ラスタライゼーション」（Rasterization）と呼ばれる、はるかに高速な投影処理を使用します 2 。ラスタライゼーションは、3D空間内のポリゴン（三角形）を2D画面上のピクセルに直接変換し、さまざまな深度テスト（Z-buffering）やシェーダー（shaders）を介してこれらのピクセルの色を数学的に予測します 2 。Eeveeの驚異的な速度は、光の計算を物理的空間で行うのではなく、スクリーン空間（Screen Space）や、事前に計算された（ベイクされた）ボリュームデータ構造（Light Probes）で行うことに由来します 6 。Blender 4.0以降で導入されたEevee Nextはエンジンの近代化であり、純粋なラスタライゼーションを超えて、ハードウェアおよびスクリーン空間のレイトレーシング機能（Ray Tracing）をハイブリッドに統合しています 3 。しかし、Eevee Nextのコアアーキテクチャは依然としてラスタライゼーションに基づいているため、生成される視覚的精度は常にカメラがその瞬間に見ている領域、またはシーンに事前に配置されたデータポイントに制限されます 14 。
2. リアリズムの幻想：なぜEeveeはフォトリアルではないのか？
ユーザーの「なぜ一方が非常に遅く、もう一方があまり現実的ではないのか？」という質問に対する答えは、Eeveeが光を物理的にシミュレートする代わりに、光学的な「イリュージョン」を作り出すことにあります。
リアリズムは、速度のために巧みに設計されたショートカットの犠牲にされています。
2.1. スクリーン空間の制限（Screen Space Limitations）とジオメトリの喪失
Eevee（および一般的にすべてのラスタライゼーションエンジン）の最大の弱点は、反射や間接光を計算する際に「スクリーン空間」（Screen Space）データに依存していることです 6 。スクリーン空間テクノロジーは、反射や影の計算を、カメラがその瞬間に見ているピクセル（深度バッファ - depth buffer）の色と位置データのみを使用して行います 15 。これが実務上の物理的観点で非常に問題となるのは、高い反射率を持つ地面（例えば濡れたアスファルトや鏡）の上に立っているキャラクターがいる場合、Eeveeはこのキャラクターの反射を、画面上の既存のピクセルを反転させて地面に描画することで作成するためです。しかし、カメラが下向きに傾き、キャラクターがカメラの視野（ビューファインダー）から外れると、地面の反射は突然消えるか、途切れます 14 。なぜなら、キャラクターはもはやスクリーン空間（depth buffer）の一部ではなく、Eeveeには見えないものを反射することができないからです。Eevee Nextは、この問題を軽減するためにスクリーン・トレース（Screen-Trace）手法を導入しました。この新しいパイプラインは、スクリーン空間でレイトレーシング（Screen Space Ray Tracing - SSRT）を実行し、レイがカメラの視野から外れた場合、シーンに事前に配置されたライトプローブ（light-probes）にフォールバック（fallback）します 15 。Eevee Nextにおけるこのシステムの成功は、精度（Precision）、厚み（Thickness）、および裏面（Backface）などのパラメータに依存します。例えば、「Thickness」の値が高く保たれている場合、深度バッファ内の表面が厚いと見なされ、レイがオブジェクトをすり抜けるのを防ぎますが、今度は反射に伸びやちらつき（flickering）などのアーティファクトが発生します 15 。これらのスクリーン空間のイリュージョンは、Cyclesのすべてのジオメトリを常に考慮に入れた完璧なグローバル反射には遠く及びません。
2.2. グローバルイルミネーション（Global Illumination）と光のバウンス
光は、現実世界でオブジェクトに衝突したとき、そのすべてのエネルギーを失うわけではありません。一部を吸収し、残りを反射し、この反射がカラーブリーディング（color bleeding）を引き起こします（例えば、赤い壁の隣にある白い椅子が赤みがかって見えること）。Cyclesは、この間接照明（indirect illumination）を「ディフューズバウンス（Diffuse Bounces）」設定で数学的に正しく計算します 6 。光エネルギーが環境内で完全に減衰するまで、オブジェクト間を移動します。一方Eeveeは、間接照明を従来「ライトプローブ」（イランディアンスボリューム）を使用して取得する必要があります。アーティストがシーンにプローブボリュームを配置すると、Eeveeはそれらのプローブを介して光がシーン内でどのように分散するかを計算し、テクスチャにベイク（baking）します 13 。Eevee Nextは、この面倒なプロセスを克服するために、地平線スキャン（horizon scan）ベースの「高速GI近似（Fast GI Approximation）」と呼ばれるシステムを導入しました 15 。粗さ（roughness）の高い表面で各レイを個別に追跡する代わりに、スクリーン空間内の照明を近似的に計算するこのシステムは、パフォーマンスを向上させノイズを減少させますが、表面間の光の複数のエネルギー伝達、光漏れ（light leaking）、および接触点オクルージョン（contact occlusion）をCyclesほど正確に解決することはできません 15 。アンビエントオクルージョン（Ambient Occlusion）は、影の交点に偽りの暗さを加えることで、この光の不足と奥行きの欠如をごまかそうとします 13 。
2.3. ボリュームエフェクト（Volumetrics）とサブサーフェス散乱
（Subsurface Scattering）有機マテリアル（人間の肌、ロウ、大理石、牛乳、葉）は光を直接反射せず、光は表面の内部に浸透し、内部の粒子に衝突して散乱し、弱められた状態で外に出てきます。Cyclesは、このエフェクトを解決するために「ランダムウォーク（Random Walk）」と呼ばれる、オブジェクト（メッシュ）内部の真のボリューム散乱（true volumetric scattering）をシミュレートする高度なアルゴリズムを使用します 18 。ランダムウォークは、閉じたジオメトリ内で光がスペクトル的にどのように減衰するか（例えば、人間の肌で赤いアンダートーンが現れること）を物理的に正確に計算します 18 。Eevee側では、SSS（Subsurface Scattering）は、マテリアル表面に入射光に応じてぼかし（blurring）を適用するという原則に基づいています 13 。ボリューム内部に入る光の実際の距離計算が行えないため、特に人間の肌のような複雑なマテリアルにおいて、Cyclesが提供できる光学的奥行きの感覚（細かいテクスチャで光がスペクトル的に減衰し、半透明性を生み出すこと）を再現することは非常に困難です 21 。同様に、霧や煙などのボリューム（volumetric）レンダリング処理においても、Eeveeは3D空間をスクリーン軸に沿ってスライス（slices）に分割して処理を行います 13 。Eevee Nextはこれらの領域で改善を行っていますが、ボリュームシェーディングの精度は常にハードウェアのラスタライゼーション解像度（volumetric tile size）の制限に引っかかっています 22 。
2.4. 遮蔽（Shadowing）と透明度の問題
Cyclesは、光線が固体のオブジェクトや半透明の表面に当たるかどうかに基づき、完全にピクセル単位の精度を持つリアルな光学影を生成します。光源のサイズが大きくなるにつれて、影の輪郭は自然にぼかされます。一方、Eeveeは歴史的に「シャドウマップ」（Shadow Maps）を使用しています 6 。シャドウマップの解像度は制限されています（例：ライトごとに1024〜4096ピクセル） 6 。この制限された解像度により、影の輪郭がピクセル化（エイリアシング）して見えたり、オブジェクトが地面に接する点で影が途切れたり（ピーターパンニング効果）する原因となります。さらに、ガラスのような屈折するオブジェクトが互いに重なり合う（透過バウンス：Transmission Bounces）シーンにおいて、Cyclesは完璧な屈折率（IOR）を適用し、光がガラスを通過して別のガラスを照らすことを許可する一方で 6 、Eeveeは深度の複雑さから逃れるために特別な透明度のトリック（アルファブレンド／ハッシュド）や屈折面を必要とします。画面空間において複数の透明なオブジェクトが重なり合うと、深度ソート（depth sorting）エラーが発生します。
3. 処理負荷とボトルネック：Cyclesはなぜこれほど遅いのか？
Cyclesが高品質な結果をもたらす一方で、制作プロセスにおける最大の障壁はその速度（あるいは速度の欠如）です。1フレームのレンダリングに秒単位ではなく、分または時間単位を要するのは、バックグラウンドで処理されている想像を絶する巨大な数学的ワークロードに起因しています。フォトリアルティはその代償をプロセッササイクルで支払わせます。
3.1. 光線のバウンス（Bounces）、サンプリング（Sampling）、およびノイズ（Noise）
Cyclesのレンダー設定にある「最大バウンス数」（Max Bounces）は、シミュレーションエンジンによって終了（terminate）させられる前に、光線が表面で何回反射できるかを決定します 6 。完全で説得力のあるグローバルイルミネーション（Global Illumination）を実現するためには、拡散反射（Diffuse）、光沢反射（Glossy）、および透過（Transmission）のバウンス制限を現実的なレベルに保つ必要があります。例えば、合わせガラスや、窓から差し込む光に照らされた白い壁を持つ深いインテリアを正確に計算するには、8〜12回、あるいは重なり合ったガラスオブジェクトの場合は16回ものバウンスが必要になることがあります 6 。各反射において光線は方向を変え、潜在的に新しい光線へと分裂します。ピクセルの色の正確性を確保するために、各ピクセルから数百、時には数千のサンプル（sample）が放たれると、処理量は対数的に増加します 6 。光源が小さく到達しにくい場合（例：小さな天窓からのみ差し込む拡散した日光）、ランダムに発射された光線の大部分は光源に到達することなく壁や地面に衝突して終了します 25 。光源を見つけられなかったピクセルは、暗いデータを返します。レンダリングが進むにつれて、隣接するピクセル間のこの照明の違いが、画像上に激しい「ノイズ」（Noise）や、点滅する明るい誤ったピクセル（ホタル：Fireflies）として現れます 15 。ノイズを除去するために必要なサンプル数を増やすこと（例：256から4096へ増やすこと）は、レンダー時間が線形に倍増する原因となります 6 。
3.2. 境界ボリューム階層（BVH - Bounding Volume Hierarchy）のコスト
レイトレーシングの全体的なパフォーマンスは、光線がシーン内に存在する三角形（ポリゴン）とどれほど高速に交差テストを行うかに依存します。近代的なシーンに何百万ものポリゴンが存在する場合、レンダーエンジンは発射したすべての光線がどの三角形に衝突したかを総当たり（ブルートフォース）で検索することはできません。そんなことをすれば何年もかかってしまいます。その代わり、エンジンはBVH（Bounding Volume Hierarchy）と呼ばれる空間データ構造を使用します 8 。BVHはシーン内のオブジェクトを入れ子になった仮想的な箱（Bounding Volumes）の中に収め、ツリー（tree）構造を構築します 8 。光線が発射されると、エンジンはまず光線が最大の箱に衝突するかどうかを確認し、衝突する場合は内部のより小さな箱へと進み、この絞り込み処理が正確に衝突した三角形に到達するまで継続されます 8 。このシステムにより、交差テストは劇的に高速化されます。しかし、BVHツリーの構築（「Building BVH」）は、レンダリングが開始される前にプロセッサ（CPU）が実行しなければならない集中的な事前準備です。静的なシーンではこの処理が一度だけ実行されるのに対し、キャラクターアニメーションや流体シミュレーションなどの変形するオブジェクトが存在するアニメーションでは、フレームごとにBVHを再計算または更新する必要があります。シーンに何百万ものパーティクルや葉が存在する場合、BVHの構築時間（パッキングBVHノード）がレンダリング時間そのものよりも長くなることがあり、システムに深刻な追加負荷をかけます 8 。
3.3. コースティクス（Caustics）とMNEE（Manifold Next Event Estimation）の数学
グラスの内部を通過した光がテーブル上に作り出す鮮やかな明るい模様や、プールの底の水面の揺らぎは「コースティクス」（Caustics）と呼ばれます 7 。標準的なパストレーシング（path tracing）アルゴリズムにとって、コースティクスは解決が最も困難な問題の筆頭に挙げられます。なぜなら、カメラから出たランダムな光線がガラスオブジェクトに衝突し、正確な屈折角でその内部を通過し、特定の小さな光源（例えばスポットライト）にピンポイントで到達する確率は10億分の1だからです 10 。このため、従来のパストレーサーではコースティクスは常に過度にノイズまみれのままとなります。この慢性的な問題を解決するために、BlenderはMNEE（Manifold Next Event Estimation）技術をCyclesに統合しました 7 。MNEEは、屈折面（屈折コースティクス：refractive caustics）を介して光源に到達するための特別な直接接続（次のイベント推定：next event estimation）を確立します 7 。アルゴリズムは、光源からカメラに向かって、多層の屈折面（媒質境界面：medium interfaces）の間で複雑な数学的投影（根探し問題：root finding problem）を用いて、「正しい」光の経路を解析的に強制します 10 。この機能は、Cyclesのリアリズムを最高潮に高め、不可能な照明状況を解決するものの、バックグラウンドで膨大な微分計算を必要とするため、レンダー時間を直接的かつアグレッシブに引き延ばします。
4. ハードウェアアクセラレーション、API、およびメモリ管理
両方のエンジン、特にCyclesのパフォーマンスのポテンシャルは、使用されているコンピュータのハードウェアの仕様およびそのハードウェアがどのように制御されるかに直接関連しています。Cyclesは何兆回もの数学的交差テストを実行するため、高度な並列処理を提供するGPU（グラフィックス処理装置）のパワーを強く必要とします。一方、Eeveeはテクスチャフィルタリング、VRAM帯域幅、およびラスタライゼーション能力に基づいて動作します。
4.1. コンピューートバックエンド（Compute Backends）とハードウェアAPI
Blender財団は、市場にあるほぼすべての最新GPUアーキテクチャを活用できるように、Cyclesをクロスプラットフォームとして最適化しました 4 。レンダリング処理を従来のCPU（プロセッサ）からGPUへ委譲することで、処理時間が対数的に短縮されます 29 。BlenderがサポートしているアクセラレーションAPIは以下の通りです：
APIテクノロジーサポートするハードウェア技術的利点と詳細CUDANVIDIA (GTX/RTX)NVIDIAの「Compute Capability 5.0」以降のカード向けの標準的な汎用ハードウェアアクセラレーション環境。GPUの並列処理能力をCPUから引き継ぐが、ハードウェアレイトレーシングコアは使用しない28。OptiXNVIDIA RTXシリーズNVIDIAのハードウェアレイトレーシングコア（RTコア）を直接利用する専用ライブラリ。ユーザーテストによると、OptiXはCUDAのみを使用する場合と比較して、レンダー時間を55%から90%短縮することが示されています。特にBVH（バウンディングボックス）の交差テストにおいて信じられないほどのパフォーマンスの飛躍をもたらします6。HIPAMD (RDNA1以降)AMD製グラフィックスカード（RX 5000シリーズ以降）向けに開発されたCUDA類似のオープンなアクセラレーション環境。RDNA2およびRDNA3シリーズ（RX 6000/7000シリーズ）においてハードウェアレイトレーシングのサポート（ハードウェアレイトレーシング）も有効化し、AMDユーザーに大幅な速度向上をもたらします28。MetalApple Silicon (M1/M2/M3)macOSエコシステム向けのAppleの直接ハードウェアアクセスAPI。VRAMとシステムRAMが同じプールを共有するため、Mシリーズプロセッサの統合メモリ（Unified Memory）構造から大きな恩恵を受ける6。oneAPIIntel Arc (Xe HPG)IntelのArcシリーズ製グラフィックスカード向けに提供されている、レイトレーシングアクセラレーションを含むフルサポートを備えたオープンソースAPI28。
OptiXとHIP技術の統合は、3D制作プロセスを根本から変革しました。かつてマルチコアCPUで何日もかかっていた複雑なアニメーションのレンダリングは、現在ではRTX 4090のようなカードを搭載した単一のワークステーション上でわずか数時間のうちに完了させることが可能です 3 。
4.2. VRAMのボトルネックとアウトオブコア（Out-of-Core）レンダーアーキテクチャレンダリング処理が開始されると、シーン内に存在するすべてのジオメトリ（数百万のポリゴン）、高解像度のPBRテクスチャ（4K/8Kのディフューズ、ノーマル、ラフネスマップ）、パーティクルシステム、およびボリュームデータが、グラフィックスカードのビデオメモリ（VRAM）にロードされる必要があります 3 。しかし、標準的なコンシューマー向けグラフィックスカードは通常8 GBから24 GBの限られたVRAMしか備えていません。シーンがVRAMの制限を超過した場合、GPUレンダリングはクラッシュし、Blenderユーザーにお馴染みの「CUDA/OptiX out of memory」（メモリ不足）エラーが発生します 31 。この重大な問題を克服するために、Cyclesはアウトオブコア（Out-of-Core）メモリアーキテクチャをサポートするようにアップデートされました 32 。アウトオブコアレンダリングとは、GPUのVRAMが完全に満杯になった際、不足しているデータのためにシステムメモリ（DDR RAM）プールを利用し始めることを意味します 33 。VRAMに収まりきらないテクスチャやジオメトリはホスト（システム）メモリに転送されます（スワッピング） 28 。しかし、このシステムには非常に重い代償があります。マザーボード上のPCIeバス（PCIe bus）を介してCPUとGPUの間でデータが常に行き来するため、帯域幅のボトルネックを引き起こし、レンダーパフォーマンスが劇的に低下します（極端な状況では、直接CPUレンダリングを使用する方が高速になることさえあります） 34 。速度低下はあるものの、シーンのクラッシュを防ぎ処理を完遂させるため、これは不可欠な「セーフティネット」です 33 。VRAMを保護し、このボトルネックに陥らないようにするために、レンダリング中にバックグラウンドの3Dビューポートを閉じること 32 、「簡易化」（Simplify）設定を介して「テクスチャ制限」（Texture Limit）により最大テクスチャサイズを制限すること、あるいは遠方のオブジェクトに対してカメラ／距離カリング（Distance Culling）を使用することが、プロフェッショナルが実践する基本的な戦略です 31 。
4.3. レンダーファーム（Render Farms）とクラウドのスケーリング
個人のハードウェアでは不十分な大規模な商業プロジェクトにおいて、アーティストは「レンダーファーム（Render Farms）」に活路を見出しています 3。これらのプラットフォームは、数百台のサーバーを相互接続することで、レンダリング時間を劇的に短縮します 11。例えば、Superluminalのようなレンダーファームでは、大規模なプロジェクト（Classroomベンチマークシーンなど）の処理時間を、1台のマシンの411秒から、30ノード（サーバー）を使用して90秒に短縮できます 11。Superluminalは、フレームごとにBlenderを再起動することによる負荷を排除する「Persistence Engine」を使用することでパフォーマンスを向上させます 11。一方、RenderStreetプラットフォームは、48 GBのVRAMを搭載したNVIDIA L40sカード（1時間あたり$4.49）を提供することでVRAMのボトルネックを克服し、OptiXハードウェアアクセラレーションとOSL（Open Shading Language）のサポートを同時に提供できます 5。また、iRenderのようなクラウドコンピューティングサービスは、8基のRTX 4090を搭載したサーバーにより、ユーザーがマシンに直接接続して独自のカスタムワークフローを構築できるようにします 3。
5. モダン最適化とBlender 4.x/5.xの革新
CyclesとEevee Nextの違いは、パフォーマンスと品質のギャップを埋めるべくレンダリングの世界を揺るがす新しいアルゴリズムによって、常に進化を続けています。
5.1. AIを活用したノイズ除去（デノイズの革命）
Cyclesのレンダリング時間が過度に遅いという問題は、AIベースの「Denoiser（デノイザー）」アルゴリズムによって劇的に解決されました 6 。ノイズ除去技術は、低いサンプル数（例えば4096ではなくわずか128や256）で生成された「粒状の」出力を、アルベドや法線マップ（パス）とともに解析し、ディープラーニングアルゴリズムを用いてピクセルをスムーズにします 6 。デノイザーのおかげで、何時間もかかるようなクリーンなCyclesの出力が、数秒または数分に短縮されます 6 。Blenderのデフォルトのツールには、2つの巨大な存在があります。 ● Intel OpenImageDenoise (OIDN): 当初はCPU上だけで動作していた、インテルのハードウェア非依存のAIベースのシステムでした。プロセッサのSSE4、AVX2、AVX-512、およびAMXセットを使用していました 37 。しかし、OIDN 2.0のリリースに伴い大規模なアップデートが行われ、完全なGPUハードウェアアクセラレーションのサポートを開始しました 37 。現在ではIntel Arc（XMX）だけでなく、NVIDIA（Turing、Ampere、Ada）、AMD（RDNA2、RDNA3）、Apple Silicon（M1+）のGPUでも動作し、卓越したパフォーマンスを発揮します 37 。細かいディテールの再構築に非常に優れており、GPUメモリが不足した場合には自動的に即座にCPUへフォールバックすることができます 37 。 ● OptiX Denoiser: NVIDIAのRTXハードウェア専用です。機械学習コアを使用し、特にビューポート上のインタラクティブなフィードバック（瞬時のカメラ移動中など）をスムーズにするのに信じられないほど高速です 6 。一方、Eevee Nextはノイズ除去を異なる方法で処理します。時間的蓄積（Temporal Accumulation）によって直前のフレームを重ね合わせ、空間的再利用（Spatial Reuse）手法を用いて画面上のノイズをリアルタイムで抑制します 13 。
5.2. パスガイディング（Path Guiding）とIntel OpenPGLの統合
特に建築ビジュアライゼーション（ArchViz）のように、小さな窓から差し込む太陽光でシーンが照らされ、大規模な間接照明が必要とされるシナリオでは、Cyclesのランダムな（ブルートフォース）光線追跡は膨大な時間の無駄です 25 。この問題を克服するために、インテルのOpenPGLライブラリがCyclesに統合され、「Path Guiding（パスガイディング）」機能が導入されました 44 。Path Guidingが有効な場合、レンダリング処理中にシステムがシーン内の照明状態を解析して学習します 44 。どの方向からより強い光エネルギーが来ているか（光の分布）をマッピングします。これらの「トレーニングサンプル（training samples）」が完了すると、エンジンは次の光線をランダムに放出するのではなく、光が来ている重要な方向（例えば暗い部屋の中の小さな窓の隙間や、開いたドアから漏れる光）へと直接導きます 25 。このスマートな「ガイディング」メカニズムにより、複雑な多重反射におけるノイズの量が劇的に削減されます 36 。当面は主にCPU（プロセッサ）上で安定して動作しますが、GPUをサポートするバージョンも急速に開発が進められています 36 。さらにCyclesは、「Light Tree（ライトツリー）」技術により、シーン内に数百の光源がある場合（例えば大都市のシルエットなど）、ピクセルがその領域に影響を与える可能性が最も高い（近接している、または強力な）光のみを計算するようにすることでレンダリング時間を短縮する、もう一つの強力な最適化構造を提供しています 6 。
5.3. ライトとシャドウのリンク（Light and Shadow Linking）
Blender 4.0ではCycles向けに、4.2以降ではEevee Next向けに、革新的な「Light Linking（ライトリンク）」機能が導入されました 49 。現実世界では点灯した電球は周囲のすべてを照らしますが、3Dアーティストはしばしば物理法則を曲げてシネマティックなコントロールを求めます。例えば、スポットライトがメインキャラクターの顔だけを照らし、背後の壁は暗いままにすることを要求する場合があります 49 。Light Linkingはまさにこれを実現します。光源が選択された「コレクション（Collections）」上のオブジェクトのみを照らす（包含 - include）、または特定のオブジェクトを無視して暗いままにする（除外 - exclude）ことを可能にします 49 。一方、Shadow Linkingは、どのオブジェクトがその光によって影を落とし、どれが落とさないかを制御します 49 。パフォーマンスの観点から見ると、これはライトツリー（Light Tree）構造を使用している場合は非常に効率的に動作しますが、シャドウリンクでは直接光と間接光が異なる経路をたどるため、追加の計算が必要になる場合があります 49 。Eevee Nextがこの機能のサポートを開始したことは、リアルタイムアニメーションの監督にとって大きな飛躍です 50 。
5.4. 空間の歪み：Ray Portal BSDF（Cycles専用）
Blender 4.2とともに、Cyclesエンジンでのみ動作し、レンダリングのパラダイムを変える「Ray Portal BSDF」ノードが導入されました 54 。この特殊なシェーダーは、ジオメトリを変更することなく、光線（ray）の空間内の位置を歪める能力を持っています。通過する光線を、シーン内の別の座標や回転（X、Y、Z）にテレポートさせます 55 。これにより、内側が外側よりも大きい「不可能な空間」の作成や、セキュリティカメラが見ているアングルをモニター上に直接映し出す（Camera Feed）エフェクトが、リアルタイムレンダリング内で（外部のテクスチャベイクなしで）可能になります 55 。透明（Transparent）BSDFのように機能してレンダリングの限界を広げますが、光線の通過は一方向であり（双方向にするにはターゲットポイントにもポータルを配置する必要があります）、直接照明のサンプリングを弱めるため、ポータルの背後にある小さな光源は激しいノイズ（noise）を引き起こす可能性があります 55 。光学的屈折の代わりに解析的な光線の位置/ベクトルの変更を提供するため、VFX（視覚効果）の専門家にとってかけがえのないツールです。
6. スタイライズドグラフィックス（NPR - 非写実的レンダリング）と「Shader to RGB」のパラドックス
すべての3Dプロジェクトがフォトリアリズムを必要とするわけではありません。アニメ、トゥーン（セル）シェーディング、あるいはコミック調のスタイライズドレンダリングは、業界で非常に一般的です 58 。しかしこの点において、EeveeとCyclesのアーキテクチャ上のコードの違いにより、アーティストは根本的な選択を迫られます。どちらのエンジンを使用するかという疑問は、ここで技術的な限界にぶつかります。
6.1. Eeveeのアニメ/トゥーンにおける優位性
スタイライズド（トゥーン）レンダリングを行う際、アーティストは自然な影と光の間の滑らかなグラデーション（gradient）を排除し、2Dアニメーションのようなシャープなバンド（カラーの停止位置）を作成したいと考えます 58 。そのためには、Blenderで標準的なシェーダー（例えばDiffuse BSDF）の照明データを取得し、その光のデータを色（RGB）に変換し、その上に「Color Ramp（カラーランプ - 一定/Constant補間）」を適用する必要があります 58 。まさにこの重要なワークフローにおいて、Shader to RGBという特別なノードが登場します。このノードは
Eeveeレンダリングエンジンでのみ動作します 58 。
6.2. 物理的なエネルギー保存とCyclesの制限
ユーザーから最も多く寄せられる質問の1つである「なぜShader to RGBはCyclesにないのか？」という質問の答えは、レイトレーシングの数学に基づいています 60 。Eeveeはラスタライゼーションエンジンであるため、レンダリング中に特定オブジェクトの画面上のライティングをオブジェクトから独立して孤立した状態で計算し、その結果をカラーデータとして即座に返すことができます 62 。一方、Cyclesは非同期で動作する巨大な「パストレーシング」ネットワークです 62 。レイがオブジェクトAに当たってもそこで終わりではありません。そこからオブジェクトBへ、さらにオブジェクトCへと跳ね返ります 62 。もしオブジェクトBの色が、オブジェクトAからの光の結果に応じてリアルタイムで変更される場合（Shader to RGBはまさにライティングに応じた色の変更を要求します）、光の経路は無限のパラドックスに陥ります。オブジェクトの色が環境内の光に影響を与える一方で、環境内の光もオブジェクトの色に影響を与えることは、循環的な論理エラーを生み出し、物理的な「エネルギー保存（energy conservation）」の法則が破られます 62 。Cyclesを使用するアーティストは、このようなスタイライズドなルックのために「Toon BSDF」を使用したり、シーンをレンダーパス（render passes）に分割してマルチ合成（compositing）を行ったり、光のデータをテクスチャとしてベイク（baking）したりするような迂回路を通る必要があります 60 。そのためEeveeは、2D/アニメスタイルのプロジェクトにおいて、議論の余地のない比類なき王様です 3 。
7. 戦略的な意思決定：どのエンジンをどのシナリオで使用すべきか？
ハードウェアの仕様、アートディレクション、物理シミュレーションの要件、および制作時間の制限に応じて、制作ワークフローにおける両エンジンの位置づけは明確です 3 。
7.1. Eevee（およびEevee Next）を使用すべき場合
● 時間的制約のある長編アニメーション：Eeveeは、フレームあたりわずか数秒（またはミリ秒）しか費やさず、アーティストが5分間のアニメーション（7000フレーム以上）を1つのワークステーションで1日以内に完了させることができます。Cyclesではこれが何ヶ月もかかったり、数万ドルのクラウドコストが発生したりする可能性があります 3 。 ● スタイライズド / NPRプロジェクト：「Shader to RGB」機能のおかげで、アニメ風のシャープなセルシェード作品において唯一の実用的な選択肢です 58 。 ● プレビズ（事前ビジュアライゼーション）とモーショングラフィックス：物理的な正確さ（ガラス、微細な反射）が重要ではなく、流動性とライブプレビューが必要とされる迅速なコンセプト承認プロセス 3 。Eevee Nextのハードウェアレイトレーシング統合により、この分野は以前よりもはるかに満足のいくものになっています 65 。
7.2. Cyclesを使用すべき場合
● 建築ビジュアライゼーション（ArchViz）およびプロダクトデザイン：光が複数の表面から跳ね返り、空間を有機的に照らす（大域照明）、コンタクトシャドウが完璧でなければならない高品質なインテリアや製品のレンダリング。Intel OpenPGL Path Guidingと組み合わせることで業界標準となります 3 。 ● VFX（視覚効果）とフォトリアリズム：実写のカメラ映像とCGIを組み合わせるコンポジット処理、複雑な合わせガラスの反射（Transmission）やRandom Walkを必要とする現実的な人間の皮膚（Subsurface Scattering）の作品 3 。 ● 複雑なボリュメトリック効果とコースティクス：霧の中を進む光線が周囲を照らす効果（マルチスッキャテリング）や、プールの底の鋭いコースティクスの屈折（MNEE）の物理的正確さ 10 。
7.3. ハイブリッドワークフローとビューポートコンポジター
実際のプロフェッショナルなシナリオでは、これら2つのエンジンは互いの敵ではなく、同じパイプラインの補完者です。EeveeとCyclesは完全に同じ「Shader Node（シェーダーノード）」インフラストラクチャとPBRロジックを共有しています 2 。この強力な機能により、アーティストはライティングのセットアップ、シーンのレイアウト、マテリアル開発（LookDev）のプロセスをEeveeのインタラクティブでスムーズな速度で行い、最終出力（ファイナルレンダー）を1つのメニューの切り替えだけでCyclesに移行し、高品質なハードウェアアクセラレーション（OptiX/HIP）環境で取得する機会が得られます 2 。さらに、Blenderの新しい「Viewport Compositor（ビューポートコンポジター）」機能のおかげで、ボリュメトリックデータやグレア（ブルーム）などのポストプロセスエフェクトをEeveeで数秒以内に取得し、レンダリングされたクリーンなCyclesの出力の上にビューポート内で直接合成する（Compositing）特別なハイブリッドシナリオを作成することで、コスト効率よく両者の長所を組み合わせることができます 22 。
結論
Blenderが3D制作の世界に提供する2つの巨大なレンダリングエンジンであるCyclesとEevee（および新しいEevee Next）の間の根本的な違いは、基本的には制作スピードと光学的な物理的完璧さとの間の容赦ないトレードオフ（trade-off）に起因しています。Cyclesは計算の面で重いです。なぜなら、光を模倣するわけではないからです。数学と現代のハードウェアが許す限りにおいて、空間内における光の実際の物理的な跳ね返り、屈折、衝突を、容赦ないモンテカルロ積分によって何十億回も再シミュレートします。高度なハードウェアAPIアクセラレータ（OptiX/HIP）、AI支援による革命的なデノイザー（OIDN 2.0）、Intel OpenPGLベースのパスガイディング（Path Guiding）アルゴリズムにより、この重い数学的負荷は今日では大幅に軽減されていますが、Cyclesはいまだに絶対的なフォトリアリズムの代償としてハードウェア投資と処理時間を要求します。その一方で、Eeveeはコンピューターグラフィックスの歴史における光学的イリュージョン能力に依存しています。ラスタライゼーション技術はスクリーン・スペース（Screen Space）の制限によって枠組みられているため、反射、ボリュメトリック散乱、間接照明を「カメラが見て予測できる範囲でのみ」生成します。このことは物理的正確さの観点では遅れをとる原因となりますが（そのため現実感は劣ります）、数秒で魅力的アニメーションを生成でき、メモリ消費を最適化し、NPR（Shader to RGB）ワークフローをサポートするため、ほとんどの中規模から大規模なプロダクションのバックボーンとなっています。プロジェクトを始めるにあたり、最終的な目標が物理的正確さなのか、それとも芸術的な柔軟性、予算、スピードなのかという問いに対する答えこそが、どちらのエンジンを選択するかを直接決定する唯一の要素です。
*情報：画像はGoogle Geminiによって生成されました。