Limitacions

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.

Attributes and Properties

  • Only 14 attributes from Geometry Nodes are supported in a material

  • Only 8 custom object properties are supported in a material

Càmeres

  • Only perspective and orthographic projections are currently supported.

Llums

  • Lights can only have one color and do not support light node trees.

  • Unlike in Cycles, the Size of spot lights does not change the softness of the cone.

  • L’opció de llum d’àrea Dispersió de raig no és compatible.

Light Probes

Indirect Lighting

  • La captura de la sonda de llum no admet reflexos especulars. L’energia especular es tracta com a difusiva.

Ombres

  • El Radiotraçat de mama d’ombres pot produir fuites de llum causades per propagados d’ombra que s’encavallen. Això es pot mitigar emprant recompte de passos, activant jitter o bé reduint la mida de la forma de la llum.

  • Els objectes prims (p. ex. parets sense gruix) podrien tenir fuites de llum pel costat ombrejat. Això es pot mitigar fent que l’objecte tingui un gruix mínim o reduint el Límit de resolució.

Volumetries

  • Only single scattering is supported.

  • Volumetrics are rendered only for the camera «rays». They don’t appear in reflections/refractions and probes.

  • Volumetric shadowing only work in volumetrics. They won’t cast shadows onto solid objects in the scene.

  • Volumetric shadowing only work for volumes inside the view frustum.

Profunditat de camp

  • Blended materials cannot be correctly handled by the post-processing blur, but will be correctly handled by the sample-based method. For this, you need to disable the post-process depth of field by setting the Max Size to 0.

Screen Space Effects

Ray-triangle intersection is not currently supported. 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.

These limitations creates a few problems:

  • The screen space effects disappear when reaching the screen border. This can be partially fixed by using the overscan feature.

  • Screen space effects lack deep information (or the thickness of objects). This is why most effects have a thickness parameter to control how to consider potential intersected pixels.

  • Aquests efectes no tenen en compte els objectes darrere d’altres objectes (oclosos).

  • Blended surfaces are not considered by these effects. They are not part of the depth prepass and do not appear in the depth buffer.

  • Objects that a part of Holdout Collections will not be rendered with screen space effects.

Raytracing

  • Els materials fusionats i els materials que empren refraccions de radiotraçat no apareixeran en els reflexos de materials distorsionats.

  • Els materials fusionats no són compatibles amb el radiotraçat.

  • Només un episodi de refracció queda correctament modelat. Es pot aconseguir una aproximació a un segon episodi de refracció mitjançant la Procedimentació de gruix.

  • Només es poden refractar els materials distorsionats que no utilitzinn Refraccions de radiotraçat.

Nodes aspectors

  • 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.

  • Algunes combinacions de FDDB provocaran més soroll que altres. Aquest és el cas quan es mescla FDDB difusiu amb FDDB refracció.

  • El desplaçament de superfícies aplanades aspectades dividirà la malla en triangles. Vegeu Desplaçament per a una circumsolució.

Vegeu també

For a full list of unsupported nodes see Nodes Support.

Memory Management

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.

So if the scene is really heavy, the driver will swap things in and out to make sure all objects are rendered correctly.

In practice, using too much GPU memory can make the GPU driver crash, freeze, or kill the application. So be careful of what you ask.

There is no standard way of estimating if the resources will fit into the GPU memory and/or if the GPU will render them successfully.

CPU Rendering

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.

Multiple GPU Support

There is currently no support for multiple GPU systems.

Headless Rendering

El revelat sense interfície (headless) no és compatible amb els sistemes de Windows sense interfície.