Limitations

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.

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

Cameras

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

Lights

  • Les ombres ne sont pas pris en charge sur les instances de lumière (dupli objects, instanciation de groupe).

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

  • As of now, lights can only have one color and do not support light node trees.

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.

Volumetrics

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

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

  • L’ombrage volumétrique ne fonctionne que sur d’autres volumétriques. Ils ne vont pas projeter des ombres sur des objets solides dans la scène.

  • L’ombrage volumétrique ne fonctionne que pour les volumes se trouvant dans le view frustum.

  • L’éclairage volumétrique ne respecte pas la forme des lumières. Elles sont traitées comme des lumières Point.

Screen Space Reflections

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

  • Le BSDF choisi est actuellement choisi arbitrairement.

  • Screen Space Reflections will reflect transparent objects and objects using Screen Space Refraction but without accurate positioning due to the one layer depth buffer.

Screen Space Refraction

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

  • Only opaque and alpha hashed materials can be refracted.

Ambient Occlusion

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

Materials

Refraction

La réfraction est simulée en échantillonnant la même sonde de réflexion utilisée par les BSDF glossy, mais en utilisant la direction de vue de la réfraction au lieu de la direction de vue de la réflexion. Seulement le premier événement de réfraction est modélisée correctement. Une approximation du second événement réfraction peut être utilisée pour des objets relativement fins en utilisant la Refraction Depth.

Bump

Pour le moment le bump mapping est pris en charge en utilisant des dérivés d’OpenGL qui sont les mêmes que pour chaque bloc de 2x2 pixels. Ce qui signifie que la valeur de sortie de bump apparaîtra pixelisé. Il est recommandé d’utiliser à la place le mapping de normales.

Astuce

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.

Volumes 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

  • Tous les BSDF utilisent des approximations pour obtenir de bonnes performances en temps réel, aussi il y aura toujours de petites différences entre Cycles et Eevee.

  • Some utility nodes are not yet compatible with Eevee (e.g. Sky Texture node).

Voir aussi

Pour une liste complète de nodes non pris en charge, voir Prise en charge des Nodes.

Gestion de la mémoire

Pour le moment Eevee utilise OpenGL, et la gestion de la mémoire GPU est assurée par le pilote OpenGL. En théorie, seuls les textures et les maillages nécessaires (dorénavant désignés comme « les ressources ») pour un appel de tracé unique (càd. un seul objet) doivent tenir dans la mémoire GPU.

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.

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.

Rendu CPU

Étant un moteur OpenGL, Eevee n’utilise que la puissance du GPU pour faire le rendu. Il n’y a pas de plan pour prendre en charge le rendu CPU (software) car il serait très inefficace. La puissance CPU est toutefois nécessaire pour gérer une scène de haute complexité car la géométrie est toujours préparé par le CPU avant le rendu de chaque trame.

Prise en charge de plusieurs GPU

Il n’y a actuellement pas de prise en charge pour des systèmes à :abbr:`GPU (Graphic Processing Unit, aussi appelé carte graphique) 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).