L’objectif d’Eevee est d’être un moteur de rendu interactif. Il se peut que certaines fonctions ne soient pas encore présentes ou soient impossibles à implémenter dans l’architecture d’Eevee sans compromettre la performance.

Voici une liste plutôt exhaustive de toutes les limitations auxquelles vous pouvez vous attendre dans le travail avec Eevee.


  • Seulement les projections perspective et orthographique sont actuellement prises en charge.


  • Seulement 128 lumières actives peuvent être prises en charge par Eevee dans une scène.

  • Seulement 8 lumières Sun Shadowed peuvent être prises en charge en même temps.

  • Pour le moment les lumières ne peuvent avoir qu’une couleur et ne prennent pas en charge les arborescences de nodes de lumière.

Light Probes

  • Eevee ne prend en charge que jusqu’à 128 Reflection Cubemaps actifs.

  • Eevee ne prend en charge que jusqu’à 64 Irradiance Volumes actifs.

  • Eevee ne prend en charge que jusqu’à 16 Reflection Planes actifs dans le view frustum.

Lumière indirecte

  • Les Volumetrics ne reçoivent pas la lumière des Irradiance Volumes mais reçoivent l’éclairage diffus du monde.

  • Eevee ne prend en charge ni les rebonds de lumière « specular to diffuse » ni les rebonds de lumière « specular to specular ».

  • Tout l’éclairage spéculaire est désactivé pendant le précalcul.


  • Seulement 128 lumières actives peuvent être prises en charge par Eevee dans une scène.

  • Seulement 8 lumières Sun Shadowed peuvent être prises en charge en même temps.


  • Seulement single scattering est pris en charge.

  • Les volumétriques* ne sont l’objet d’un rendu que pour les « rayons » de la caméra. Ils n’apparaissent pas dans les réflexions/réfractions et dans les sondes.

  • Volumetrics don’t receive light from Irradiance Volumes but do receive diffuse lighting from the world.

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

  • Volumetric lighting do not respect the lights shapes. They are treated as point lights.

Depth of Field

  • Rendered at half resolution which can create blocky pixel artifacts on tiny features that are nearly in focus.

  • The near and far defocus buffers are in fact one single continuous texture. This can make some bleeding appear on the left and right sides of the image. This can be fixed by using the overscan feature.

Screen Space Effects

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.

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.

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

Ambient Occlusion

  • Les objets sont traités comme infiniment épais, produisant un overshadowing si la Distance est réellement grande.

Screen Space Reflections

  • Seulement un BSDF glossy peut émettre des screen space reflections.

  • Le BSDF évalué est actuellement choisi arbitrairement.

  • Les Screen Space Reflections vont refléter des objets transparents et des objets utilisant la Screen Space Refraction mais sans positionnement précis en raison du tampon de profondeur en une couche.

Screen Space Refraction

  • Seulement un événement de réfraction est correctement modélisé.

  • Only opaque and alpha hashed materials can be refracted.

Subsurface Scattering

  • Seulement un BSSRDF peut produire une screen space subsurface scattering.

  • Le BSSRDF évalué est actuellement choisi arbitrairement.

  • Un maximum de 254 surfaces différentes peuvent utiliser la subsurface scattering.

  • Only scaling is adjustable per pixel. Individual RGB radii are adjustable in the socket default value.

  • Input radiance from each surfaces are not isolated during the blurring, leading to light leaking from surface to surface.



Refraction is faked by sampling the same reflection probe used by the Glossy BSDFs, but using the refracted view direction instead of the reflected view direction. Only the first refraction event is modeled correctly. An approximation of the second refraction event can be used for relatively thin objects using Refraction Depth. Using Screen Space refraction will refract what is visible inside the view, and use the nearest probe if there is no hit.

Screen Space Reflections and Ambient Occlusion are not compatible with Screen Space Refraction; they will be disabled on the surfaces that use it. Surfaces that use Screen Space Refraction will not appear in Screen Space Reflections at the right place. Surfaces that use Screen Space Refraction will not cast Ambient Occlusion onto other surfaces.

Bump Mapping

As of now, bump mapping is supported using OpenGL derivatives which are the same for each block of 2×2 pixels. This means the bump output value will appear pixelated. It is recommended to use normal mapping instead.


Si vous avez absolument besoin de faire le rendu avec des nodes Bump, faites le rendu à deux fois la résolution de la cible et réduisez l’échelle de la sortie finale.

Volume Objects

Object volume shaders will affect the whole bounding box of the object. The shape of the volume must be adjusted using procedural texturing inside the shader.

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 (e.g. Sky Texture node).

Voir aussi

For a full list of unsupported nodes see Nodes Support.

Gestion de la mémoire

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.

Aussi si la scène est réellement lourde, le pilote va interchanger les choses pour s’assurer que tous les objets sont rendus correctement.

En pratique, l’utilisation de trop de mémoire GPU peut faire planter le pilote GPU, ou tuer l’application. Aussi soyez prudent avec ce que vous demandez.

Il n’existe pas de manière standard pour estimer si les ressources vont tenir dans la mémoire GPU et/ou si le GPU va réussir à en faire le rendu.

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

Prise en charge de plusieurs GPU

Il n’y a actuellement pas de prise en charge pour des systèmes à GPU multiples.

Rendu sans affichage

Il n’y a actuellement pas de prise en charge pour utiliser Eevee sur des systèmes sans affichage (càd. sans un gestionnaire d’affichage).