制限
EEVEE's goal is to be an interactive render engine. Some features may not be there yet or may be impossible to implement into EEVEE's architecture without compromising performance.
Here is a rather exhaustive list of all the limitations you can expect while working with EEVEE.
Cameras(カメラ)
現在、Perspective(透視投影)とOrthographic projections(平行投影)のみがサポートされています。
Lights(照明)
Only 128 active lights can be supported by EEVEE in a scene.
同時にサポートできる影ありサンライトは8つまでです。
現在のところ、ライトは1つの色しか持てず、ライトノードツリーをサポートしていません。
Light Probes(ライトプローブ)
EEVEE only supports up to 128 active Reflection Cubemaps.
EEVEE only supports up to 64 active Irradiance Volumes.
EEVEE only supports up to 16 active Reflection Planes inside the view frustum.
Indirect Lighting(間接照明)
Volumetrics(ボリューメトリック)は、Irradiance Volumes(イラディアンスボリューム)からのライトを受け取りませんが、ワールドのディフューズライトを受け取ります。
EEVEE does not support "specular to diffuse" light bounces nor "specular to specular" light bounces.
ベーキング中は、すべてのSpecular(スペキュラー)照明がオフになります。
Shadows(影)
Only 128 active lights can be supported by EEVEE in a scene.
同時にサポートできる影ありサンライトは8つまでです。
Volumetrics(ボリューメトリック)
単一散乱のみがサポートされています。
Volumetrics(ボリューメトリック)は、カメラの "レイ" に対してのみレンダリングされます。それらは反射/屈折およびプローブには現れません。
Volumetrics(ボリューメトリック)は、Irradiance Volumes(イラディアンスボリューム)からのライトを受け取りませんが、ワールドからのディフューズライトを受け取ります。
Volumetrics(ボリューメトリック)シャドウイングは、ボリューメトリックでのみ機能します。シーン内のソリッドオブジェクトに影を落とすことはありません。
Volumetrics(ボリューメトリック)シャドウイングは、ビュー錐台内のボリュームに対してのみ機能します。
Volumetrics(ボリューメトリック)照明は、ライトの形状を尊重しません。それらはポイントライトとして扱われます。
Depth of Field(被写界深度)
アルファブレンドされたサーフェスは、後処理ブラーでは正しく処理できませんが、サンプルベースの方法では正しく処理されます。このためには、 Max Size(最大サイズ) を0に設定して、後処理の被写界深度を無効にする必要があります。
Screen Space(スクリーンスペース) エフェクト
EEVEE is not a ray tracing engine and cannot do ray-triangle intersection. Instead of this, EEVEE uses the depth buffer as an approximated scene representation. This reduces the complexity of scene scale effects and enables a higher performance. However, only what is in inside the view can be considered when computing these effects. Also, since it only uses one layer of depth, only the front-most pixel distance is known.
これらの制限により、いくつかの問題が発生します:
スクリーンの境界に達すると、スクリーン空間のエフェクトは消えます。これは、 オーバースキャン 機能を使用して部分的に修正できます。
スクリーン空間のエフェクトには、詳細な情報(またはオブジェクトの幅)がありません。これが、ほとんどのエフェクトに、交差する可能性のあるピクセルを考慮する方法を制御するためのThickness(幅)パラメーターがある理由です。
ブレンドされたサーフェスは、これらのエフェクトによって考慮されません。これらは深度プレパスの一部ではなく、深度バッファーには表示されません。
Holdout(ホールドアウト)コレクション の一部がスクリーン空間のエフェクトでレンダリングされないオブジェクト。
Ambient Occlusion(アンビエントオクルージョン(AO))
オブジェクトは無限に厚いものとして扱われ、 Distance(距離) が本当に大きい場合は影が薄くなります。
Screen Space Reflections(スクリーンスペース反射)
1つの光沢のあるBSDFのみがスクリーンスペース反射を放出できます。
評価されたBSDFは、現在任意に選択されています。
Screen Space Reflections(スクリーンスペース反射)は、透明なオブジェクトとScreen Space Refraction(スクリーンスペース屈折)を使用するオブジェクトを反射しますが、1つのレイヤーの深度バッファーのために正確なポジショニングはありません。
Screen Space Refraction(スクリーンスペース屈折)
1つの屈折イベントのみが正しくモデル化されます。
屈折できるのは、不透明でアルファハッシュされたマテリアルのみです。
Subsurface Scattering(SSS)
1つのBSSRDFのみがスクリーン空間のサブサーフェススキャタリングを生成できます。
評価されたBSSRDFは、現在任意に選択されています。
最大254の異なるサーフェスがサブサーフェススキャタリングを使用できます。
スケーリングのみがピクセルごとに調整可能です。個々のRGB半径は、ソケットのデフォルト値で調整可能です。
各サーフェスからの入力放射輝度は、ブラー中に分離されないため、サーフェスからサーフェスへのライト漏れにつながります。
Motion Blur(モーションブラー)
Motion Blur((モーションブラー)) は最終レンダリングでのみ使用可能であり、3D Viewport(3Dビューポート)で、つまり Viewport Renders には表示されません。
Materials(マテリアル)
- Refractions(屈折)
Refraction(屈折)は、Glossy BSDF(光沢BSDF)で使用されているのと同じ反射プローブをサンプリングすることによって偽造されますが、反射ビュー方向の代わりに屈折ビュー方向を使用します。最初の屈折イベントのみが正しくモデル化されます。2番目の屈折イベントの近似値は、Refraction Depth(屈折の深度)を使用して比較的薄いオブジェクトに使用できます。Screen Space Refraction(スクリーンスペース屈折)を使用すると、ビュー内に表示されているものが屈折し、ヒットがない場合は最も近いプローブが使用されます。
Screen Space Reflections(スクリーンスペース反射)とAmbient Occlusion(アンビエントオクルージョン(AO))はScreen Space Refraction(スクリーンスペース屈折)と互換性がありません。それらを使用するサーフェスでは無効になります。Screen Space Refraction(スクリーンスペース屈折)を使用するサーフェスは、適切な場所のScreen Space Reflections(スクリーンスペース反射)に表示されません。Screen Space Refraction(スクリーンスペース屈折)を使用するサーフェスは、Ambient Occlusion(アンビエントオクルージョン(AO))を他のサーフェスにキャストしません。
- Volume Objects(ボリュームオブジェクト)
オブジェクトボリュームのシェーダーは、オブジェクトのバウンディングボックス全体に影響します。ボリュームの形状は、シェーダー内の手続き型テクスチャリングを使用して調整する必要があります。
Shader Nodes(シェーダーノード)
All BSDF's are using approximations to achieve realtime performance so there will always be small differences between Cycles and EEVEE.
Some utility nodes are not yet compatible with EEVEE.
参考
サポートされていないノードの完全なリストについては、 サポートされるノード を参照してください。
メモリの管理
In EEVEE, GPU Memory management is done by the GPU driver. In theory, only the needed textures and meshes (now referred as "the resources") for a single draw call (i.e. one object) needs to fit into the GPU memory.
したがって、シーンが非常に重い場合、ドライバーはすべてのオブジェクトが正しくレンダリングされるように、メモリの入れ替えをします。
実際には、GPUメモリを使いすぎると、GPUドライバーがクラッシュしたり、フリーズしたり、アプリケーションが強制終了したりする可能性があります。だから注意してください。
リソースがGPUメモリに収まるかどうか、および/または、GPUがリソースを正常にレンダリングするかどうかを見当する標準的な方法はありません。
CPU レンダリング
Being a rasterization engine, EEVEE only uses the power of the GPU to render. There is no plan to support CPU (software) rendering as it would be very inefficient. CPU power is still needed to handle high scene complexity as the geometry must be prepared by the CPU before rendering each frame.
マルチGPUサポート
現在、複数の GPU システムはサポートしていません。
ヘッドレスレンダリング
There is currently no support for using EEVEE on headless systems (i.e. without a Display Manager).