Limitations

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.

Cameras

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

Lights (lumières)

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 nœuds de lumière.

Sondes de lumières

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.

Shadows (ombres)

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.

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.

Depth Of Field (Profondeur de champ)

Les surfaces lissées alpha ne peuvent pas être correctement gérées par le flou de post-traitement, mais le seront correctement par la méthode basée sur les échantillons. Pour cela, vous devez désactiver le post-traitement de la profondeur de champ en définissant Max Size sur 0.

Screen Space Effects

Eevee n’est pas un moteur de lancer de rayons et ne peut pas faire d’intersection rayon-triangle. Au lieu de cela, Eevee utilise le tampon de profondeur comme représentation de scène approximative. Cela réduit la complexité des effets d’échelle de scène et permet de meilleures performances. Cependant, seul ce qui se trouve à l’intérieur de la vue peut être pris en compte lors du calcul de ces effets. De plus, comme il n’utilise qu’une seule couche de profondeur, seule la distance du pixel le plus à l’avant est connue.

Ces limitations posent quelques problèmes :

Les effets d’espace d’écran disparaissent lorsque vous atteignez la bordure de l’écran. Cela peut être partiellement corrigé en utilisant la fonction overscan.
Les effets d’espace d’écran manquent d’informations profondes (ou d’épaisseur des objets). C’est pourquoi la plupart des effets ont un paramètre d’épaisseur pour contrôler la façon de considérer les pixels potentiels intersectés.
Les surfaces mélangées ne sont pas prises en compte par ces effets. Ils ne font pas partie de la passe de profondeur préalable (depth prepass) et n’apparaissent pas dans le tampon de profondeur.
Les objets qui font partie de Holdout Collections ne seront pas rendus avec les effets d’espace d’écran.

Ambient Occlusion (Occlusion ambiante)

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é.
Seuls les matériaux opaques et alpha peuvent réfracter.

Subsurface Scattering (Transluminescence)

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.
Seule la mise à l’échelle est ajustable par pixel. Les rayons RVB individuels sont réglables dans la valeur par défaut du socket.
L’éclat d’entrée de chaque surface n’est pas isolé pendant le flou, ce qui entraîne une fuite de lumière d’une surface à l’autre.

Motion Blur (flou de mouvement)

Motion Blur n’est disponible que dans les rendus finaux et n’est pas affiché dans la Vue 3D et donc Viewport Renders.

Materials

Refractions

La réfraction est simulée en échantillonnant la même sonde de réflexion utilisée par les Glossy BSDF, 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. L’utilisation de la réfraction de l’espace d’écran réfractera ce qui est visible à l’intérieur de la vue et utilisera la sonde la plus proche s’il n’y a pas de coup.

Les réflexions d’espace d’écran et l’occlusion ambiante ne sont pas compatibles avec la réfraction d’espace d’écran ; ils seront désactivés sur les surfaces qui l’utilisent. Les surfaces qui utilisent la réfraction d’espace d’écran n’apparaîtront pas dans les réflexions d’espace d’écran au bon endroit. Les surfaces qui utilisent la réfraction d’espace d’écran ne projetteront pas l’occlusion ambiante sur d’autres surfaces.

Volume Objects

Les shaders de volume d’objet vont affecter toute la boîte d’encombrement de l’objet. La forme du volume doit être ajustée en utilisant le texturage procédural dans le shader.

Les nœuds Shader

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.
Certaines nœuds utilitaires ne sont pas encore compatibles avec Eevee (ex. le nœud Sky Texture).

Voir aussi

Pour une liste complète de nœuds non pris en charge, voir Prise en charge des nœuds.

Gestion de la mémoire

Avec Eevee, la gestion de la mémoire des 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.

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

Étant un moteur de rastérisation, Eevee n’utilise que la puissance du GPU pour le rendu. Il n’y a pas de plan pour prendre en charge le rendu CPU (logiciel) car il serait très inefficace. La puissance du processeur est toujours nécessaire pour gérer une complexité de scène élevée car la géométrie doit être préparée par le processeur 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 à 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).