Cartes d'ombres virtuelles

Les cartes d'ombres virtuelles (VSM) constituent la nouvelle méthode de cartographie des ombres permettant de fournir des ombres cohérentes et haute résolution compatibles avec des ressources de qualité cinématographique et de grands mondes ouverts à éclairage dynamique à l'aide des fonctionnalités Géométrie virtualisée Nanite, Illumination globale et reflets Lumen et World Partition de l'Unreal Engine 5.

Objectifs des cartes d'ombres virtuelles

Les cartes d'ombres virtuelles ont été développées avec les objectifs suivants :

• Augmenter de façon significative la résolution des ombres selon la géométrie Nanite hautement détaillée
• Créer des ombres douces plausibles avec des coûts de performance raisonnables et contrôlables
• Fournir une solution simple qui fonctionne par défaut et minimise le nombre d'ajustements nécessaires
• Remplacer les nombreuses techniques d'ombrage de la lumière fixe par une méthode unique et unifiée

D'un point de vue conceptuel, les cartes d'ombres virtuelles ne sont que des cartes d'ombres à très haute résolution. Dans leur implémentation actuelle, elles présentent une résolution virtuelle de 16k x 16k pixels. Les clipmaps sont utilisés pour optimiser la résolution des lumières directionnelles. Pour maintenir des performances élevées à un coût de mémoire raisonnable, les VSM divisent la carte d'ombres en carreaux (ou pages) de 128 x 128 chacun. Ces pages sont allouées et rendues uniquement en fonction des besoins pour ombrer les pixels à l'écran, sur la base d'une analyse du tampon de profondeur. Les pages sont mises en cache entre les images, à moins qu'elles ne soient invalidées par des objets en mouvement ou par la lumière, ce qui améliore encore les performances.

Nanite ne prend pas en charge la plupart des techniques d'ombrage de la lumière fixe, notamment les ombres préalables et les ombres par objet (ou par incrustation). Bien que les parties les plus dynamiques des ombres de la lumière fixe puissent fonctionner, à savoir les cartes d'ombres en cascade à proximité du viseur de la caméra, Nanite et les lumières fixes avec des cartes d'ombres conventionnelles ne sont pas prises en charge. Si vous utilisez Nanite dans votre projet, vous devez soit utiliser des lumières mobiles soit utiliser des cartes d'ombres virtuelles.

Activer les cartes d'ombres virtuelles

Dans les paramètres du projet, accédez à la section Ombres du menu Moteur > Rendu pour définir la méthode de cartes d'ombres que votre projet prend en charge, qu'il s'agisse de cartes d'ombres virtuelles ou de cartes d'ombres conventionnelles utilisées dans les versions précédentes de l'Unreal Engine.

Les projets existants doivent être activés en utilisant les paramètres du projet ou la variable de console r.Shadow.Virtual.Enable. Les nouveaux projets utilisent les cartes d'ombres virtuelles par défaut.

Qu'advient-il des méthodes d'ombres existantes lorsque les VSM sont activées ?

Lorsque les VSM sont activées, elles remplacent diverses méthodes d'ombres existantes dans l'Unreal Engine :

• Ombres fixes précalculées, y compris le champ de distance 2D et le facteur d'ombre « cartes d'ombres ».
• Ombres préalables
• Ombres par objet/par incrustation
• Cartes d'ombres en cascade (CSM)
• Ombres dynamiques mobiles pour les lumières locales

Les ombres entièrement générées à partir de lumières statiques fonctionnent toujours comme avant (si vous n'utilisez pas le système Lumen). Leurs contributions sont entièrement représentées dans les lightmaps générées et aucun éclairage n'est évalué au moment de l'exécution. Les lumières fixes utilisent la contribution diffuse indirecte de n'importe quelle lightmap générée, mais leur éclairage direct et leurs ombres sont évalués dynamiquement (comme pour les lumières mobiles) lorsque les VSM sont activées.

Les ombres de champ de distance ne sont pas remplacées et peuvent être utilisées en tandem avec les cartes d'ombres virtuelles pour les lumières directionnelles. Les ombres de champ de distance prennent le relais de la géométrie non Nanite au-delà de la distance d'ombrage dynamique des lumières mobiles (définie sur une lumière directionnelle à l'aide de la propriété Lumière mobile de distance d'ombre dynamique des cartes d'ombres en cascade). L'utilisation des ombres de champ de distance est utile pour réduire les coûts d'exécution dans les scènes complexes, notamment celles comportant un feuillage non Nanite dense.

La géométrie Nanite est toujours rendue sur la carte d'ombres virtuelles, quelle que soit la distance, car il s'agit de l'option la plus performante et qui offre la meilleure qualité. Il est possible de faire en sorte que la géométrie non Nanite se comporte de la même manière que la géométrie Nanite à l'aide de la variable de console r.Shadow.Virtual.UseFarShadowCulling 0.

Les lumières locales (lumières ponctuelles et projecteurs) ne sont pas concernées, et la sélection des ombres de champ de distance correspondantes continue de remplacer la méthode de carte d'ombres active.

Grâce à la haute résolution et à la précision des VSM, la fonctionnalité Ombre de contact dans l'espace écran, contrôlée par la propriété Longueur de l'ombre de contact, n'est plus nécessaire pour obtenir des ombres de contact nettes. Cette fonction peut être utile pour capter des ombres moins onéreuses auprès d'objets configurés pour ne pas être rendus dans des cartes d'ombres, mais nous vous déconseillons de l'utiliser dans d'autres contextes, car elle est moins précise que les ombres créées par les VSM.

Les ombres à lancer de rayons ont toujours la priorité sur les VSM, car elles fournissent généralement une solution de meilleure qualité.

Ombres douces par ray-tracing de la carte d'ombres

Ray-tracing de la carte d'ombres (SMRT) est un algorithme d'échantillonnage utilisé avec les cartes d'ombres virtuelles pour produire des ombres douces plus plausibles et un durcissement du contact. Les objets dont les ombres se projettent sur une plus longue distance présentent des ombres plus douces que les objets qui projettent des ombres plus près d'une surface réceptrice d'ombres. Par exemple, le grand maillage illustré ci-dessous projette son ombre sur une longue distance. Les ombres à proximité de la base sont plus nettes que les ombres plus éloignées.

Exemple avec une lumière ponctuelle projetant des ombres douces et des ombres dures par contact à l'aide de la méthode Ray-tracing de la carte d'ombres.

Les méthodes antérieures basées sur le filtrage en pourcentage plus proche (PCF) avaient pour effet d'estomper et de réduire l'impact visuel de la géométrie haute résolution et des ombres.

L'algorithme SMRT projette un certain nombre de rayons vers la source lumineuse, mais au lieu d'évaluer les intersections avec la géométrie (comme le fait le ray-tracing conventionnel), un certain nombre d'échantillons le long du rayon sont projetés et testés par rapport à la carte d'ombres virtuelles pour obtenir un ombrage doux et un durcissement du contact. Les rayons d'ombre sont distribués en fonction de la lumière en utilisant le rayon de la source sur les lumières locales ou l'angle de la source sur les lumières directionnelles.

Les lumières locales n'ont pas de rayon de source par défaut, contrairement aux lumières directionnelles qui commencent avec un angle de source faible. Lorsque l'une ou l'autre propriété est définie avec une valeur appropriée, SMRT produit des ombres douces en temps réel avec un durcissement par contact, comme dans l'exemple ci-dessous utilisant une lumière ponctuelle avec un rayon de source de 10.

Contrôler la qualité des ombres de pénombre

La douceur et la qualité des ombres de pénombre sont définies par des variables de console pour les lumières locales et directionnelles. Elles incluent leurs propres paramètres d'extensibilité qui conviennent généralement à la plupart des scènes.

Le bruit dans la pénombre dépend du nombre de rayons utilisés, et les lumières locales et directionnelles utilisent huit rayons par défaut lorsque l'évolutivité des ombres est définie sur Épique.

Utilisez les variables de console r.Shadow.Virtual.SMRT.RayCountLocal et r.Shadow.Virtual.SMRT.RayCountDirectional pour ajuster le nombre de rayons. Un nombre inférieur de rayons présente un bruit visible dans la pénombre. En définissant la variable de console associée sur 0, vous désactivez SMRT et revenez à des ombres dures à échantillonnage unique.

Il est en outre possible de définir le nombre d'échantillons d'ombre pris le long du trajet de chaque rayon pour les lumières locales et directionnelles afin de contrôler la douceur maximale. Un nombre inférieur d'échantillons de cartes d'ombres réduit le coût de rendu, mais limite la douceur de la pénombre pouvant être obtenue par les ombres de la lumière. Pour un contrôle plus fin que les paramètres d'évolutivité des ombres, utilisez les variables de console r.Shadow.Virtual.SMRT.SamplesPerRayLocal et r.Shadow.Virtual.SMRT.SamplesPerRayDirectional pour ajuster le nombre d'échantillons utilisés. Nous vous conseillons d'utiliser des valeurs comprises entre 4 et 8 échantillons.

Limites du ray-tracing de la carte d'ombres

Le paramètre par défaut produit généralement un SMRT de bonne qualité, mais il existe certaines limites inhérentes à l'utilisation des données d'une seule projection de carte d'ombres (par rapport au test de la géométrie réelle).

Limites de taille de la pénombre

La pénombre d'ombre est fixe pour les lumières locales et directionnelles afin d'éviter toute divergence d'échantillon par rapport à l'origine du rayon, qui peut progressivement « dévier » du test idéal le long du rayon proprement dit. L'utilisation de valeurs raisonnables pour le rayon de la source sur les lumières locales et l'angle de la source sur les lumières directionnelles évite des résultats extrêmes en limitant les plages de divergence du rayon. Des valeurs trop élevées peuvent avoir un impact sur les performances et provoquer une déformation visuelle des pénombres d'ombre lorsque la caméra s'en approche.

Les lumières locales et directionnelles peuvent utiliser les variables de console r.Shadow.Virtual.SMRT.MaxRayAngleFromLight et r.Shadow.Virtual.SMRT.RayLengthScaleDirectional pour ajuster les valeurs définies.

Pénombre incohérente

Dans la mesure où la carte d'ombres virtuelles ne stocke que la première couche de profondeur où l'itération naïve n'interagit avec aucun obturateur derrière le premier, divers artefacts de fuite de lumière peuvent se produire là où les obturateurs se chevauchent. Ces types de fuites de lumière sont résolus à l'aide d'une heuristique de remplissage qui extrapole les profondeurs derrière le premier obturateur sur la base des profondeurs apparaissant avant le point d'occlusion.

Cette méthode résout efficacement les fuites de lumière, mais entraîne une diminution de la taille des pénombres sur les surfaces parallèles à la lumière. Il n'existe actuellement aucun moyen direct de contrer cet effet, si ce n'est en maintenant des tailles de pénombre raisonnables.

Exemples d'ombres de pénombre incohérente.

Artefacts de pénombre

Par défaut, les cartes d'ombres virtuelles garantissent uniquement la présence des échantillons autour de l'origine du rayon (le pixel récepteur). Lorsque l'algorithme traverse le rayon, il peut rencontrer des pages non mappées où les données d'ombre sont inexistantes. Diverses techniques sont utilisées pour réduire l'impact de ce phénomène, notamment en dilatant légèrement les mappages de pages et en mettant en place différentes solutions de repli pendant l'itération. Malgré tout, des artefacts occasionnels dus à des pages manquantes peuvent se produire, notamment sur les bords de l'écran lors d'un zoom sur une pénombre douce. Ces artefacts se manifestent par des fuites de lumière qui génèrent du bruit dans les zones d'ombre. Comme pour les autres limitations relatives aux VSM, il est possible d'éviter ces problèmes en maintenant des pénombres d'ombre de taille raisonnable et en évitant d'effectuer un zoom au point qu'elles couvrent de grandes parties à l'écran.

Clipmaps pour la lumière directionnelle

Une seule carte d'ombres virtuelles n'offre pas une résolution suffisante pour couvrir de grandes zones. Les lumières directionnelles utilisent une structure de clipmap de plages d'expansion autour de la caméra, chaque niveau de clipmap ayant sa propre VSM de 16K. Chaque niveau de clipmap a la même résolution, mais couvre deux fois le rayon du précédent.

Par défaut, les niveaux de clipmap 6 à 22 sont affectés à des tables de pages de carte d'ombres virtuelles. Cela signifie que les paramètres par défaut permettent au clipmap le plus détaillé de couvrir 64 cm (2^6 cm) à partir de la position de la caméra, et au clipmap le plus large de couvrir environ 40 kilomètres (2^22 cm). Le coût des niveaux de clipmap virtuels est insignifiant si ceux-ci ne contiennent aucun élément ; par conséquent, ces valeurs par défaut permettent de couvrir de très grandes scènes avec une résolution suffisamment élevée à proximité de la caméra.

Il est possible d'ajouter le premier et le dernier niveaux en utilisant les variables de console r.Shadow.Virtual.Clipmap.FirstLevel et r.Shadow.Virtual.Clipmap.LastLevel.

La résolution attribuée à un pixel donné est fonction de la distance par rapport à l'origine du clipmap, à savoir la caméra. Elle est définie par l'évolutivité de l'ombre à l'aide de la variable de console r.Shadow.Virtual.ResolutionLodBiasDirectional. Une valeur de 0 sélectionne la résolution requise en fonction de la projection en perspective de la caméra. Le crénelage projectif (ombre projetée sur une surface presque parallèle à la direction de la lumière) est toujours possible, même à haute résolution, mais vous pouvez le réduire partiellement en polarisant la résolution. À l'instar de la polarisation MIP des textures, la diminution de cette valeur de -1 multiplie par deux la résolution des ombres avec les compromis de performance associés. La valeur par défaut de -1,5 sur l'évolutivité des ombres Épique fournit un équilibre raisonnable pour de nombreuses scènes.

Lumières locales

Les lumières directionnelles utilisent une seule VSM de 16k avec une chaîne MIP plutôt que des clipmaps pour gérer le niveau de détail des ombres. De même, les lumières ponctuelles utilisent une cube map avec une VSM 16k pour chaque face.

Les lumières locales offrent une augmentation significative de la résolution par rapport aux cartes d'ombres traditionnelles. L'utilisation de lumières locales de très grande taille risque d'entraîner une baisse de la résolution virtuelle ; dans ce cas, veillez donc à utiliser des lumières directionnelles lorsque cela est possible.

Les niveaux MIP appropriés sont choisis en projetant la taille des pixels de l'écran dans l'espace de la carte d'ombres. Comme pour les lumières directionnelles, il est possible de polariser la résolution avec les paramètres d'évolutivité de l'ombre, ou en utilisant la variable de console r.Shadow.Virtual.ResolutionLodBiasLocal.

Les contrôles de résolution par lumière ne sont pas disponibles, mais peuvent être ajoutés dans une prochaine version.

Pages grossières

L'analyse du tampon de profondeur est la méthode principale utilisée pour marquer les pages devant être rendues. Certains systèmes doivent cependant échantillonner les ombres à des emplacements plus arbitraires, comme le brouillard volumétrique et la translucidité à rendu direct. La plupart des systèmes n'ont besoin que de données d'ombre à faible résolution qui sont filtrées et floutées par d'autres structures de données.

Pour tenir compte de l'ombrage dans ces situations, les pages grossières sont marquées de façon à disposer au minimum de données d'ombrage à faible résolution sur l'ensemble du domaine à échantillonner. Les lumières locales se contentent de marquer la page MIP racine, tandis que les lumières directionnelles peuvent marquer une série de pages à différents niveaux de détails faibles pour former des clipmaps grossiers. Selon la scène, les pages grossières peuvent entraîner des problèmes de performance. Cela est particulièrement vrai pour les géométries dynamiques non Nanite, qui rendent effectivement des ombres à faible résolution sur de vastes régions de l'espace, ce qui peut entraîner des goulots d'étranglement lors d'appels de génération.

Nous vous recommandons d'essayer de désactiver le rendu des objets non Nanite dans les pages grossières en utilisant la variable de console r.Shadow.Virtual.NonNanite.IncludeInCoarsePages 0.

De nombreuses scènes, en particulier celles qui se composent principalement de géométrie Nanite, n'ont pas besoin d'objets non Nanite projetant des ombres sur le brouillard volumétrique ou sur d'autres systèmes. La désactivation de cette fonction peut améliorer significativement les performances.

Vous pouvez désactiver les pages grossières de la lumière locale avec la variable r.Shadow.Virtual.MarkCoarsePagesLocal, si elles sont inutiles. Vous pouvez désactiver les pages grossières de la lumière directionnelle avec la variable r.Shadow.Virtual.MarkCoarsePagesDirectional, ou modifier la plage de niveaux du clipmap dans laquelle les pages grossières sont marquées avec les variables r.Shadow.Virtual.FirstCoarseLevel et r.Shadow.Virtual.LastCoarseLevel.

Dans une prochaine version, une solution plus élégante consisterait à marquer au préalable certains de ces effets pour les pages localisées directement plutôt que d'utiliser les pages grossières actuelles, trop conservatrices.

Visualisation

Les options de visualisation des cartes d'ombres virtuelles sont accessibles à partir du hublot du niveau en utilisant le menu déroulant Modes d'affichage et en sélectionnant Carte d'ombres virtuelles.

Ces options sont les suivantes :

Par défaut, les visualisations de la carte d'ombres virtuelles affichent les résultats de la lumière directionnelle. En sélectionnant une lumière dans l'Organiseur du monde, vous pouvez afficher les visualisations correspondantes.

Vous pouvez également activer la visualisation à l'aide de la console (sauf dans les builds d'expédition), notamment pour profiler et déboguer un jeu en direct. Si l'un de ces paramètres est défini dans l'éditeur, il annule toute sélection de mode effectuée dans l'interface utilisateur de l'éditeur.

L'activation des modes de visualisation a une incidence subtile, mais mesurable, sur les performances des cartes d'ombres virtuelles. Veillez à désactiver la visualisation avant de procéder au profilage des performances.

Mise en cache

La réutilisation des pages de cartes d'ombres des images précédentes est essentielle pour maintenir des performances élevées avec les cartes d'ombres virtuelles, en particulier dans les scènes complexes. La mise en cache est activée par défaut, mais vous pouvez la désactiver à des fins de débogage en utilisant la variable de console r.Shadow.Virtual.Cache 0.

Étant donné que les pages ne sont rendues que pour les pixels à l'écran, le changement de visibilité de la caméra en raison du mouvement de désocclusion peut révéler de nouvelles pages devant être rendues. En règle générale, tant que le mouvement de la caméra est relativement fluide, il ne constitue pas une source importante de nouvelles pages. En revanche, vous devez faire attention aux mouvements très rapides à proximité des objets, aux grandes désocclusions et aux coupures de caméra.

Dans la plupart des scènes, les pages de cartes d'ombres devant être nouvellement générées en raison de changements dans la géométrie de la scène exigent généralement beaucoup d'efforts. Les sources courantes d'invalidation des pages de cache sont les suivantes :

• Tout mouvement ou toute rotation de la lumière invalidera les pages mises en cache pour cette lumière.
• Géométrie projetant des ombres qui se déplace, ou est ajoutée ou supprimée de la scène, ce qui invalide toutes les pages qui chevauchent sa cage de délimitation du point de vue de la lumière.
• Cela peut inclure des objets tels que les blueprints définissant des propriétés sur des composants de primitive qui déclenchent l'invalidation de l'état de rendu, même s'ils ne se déplacent pas réellement.
• Géométrie utilisant des matériaux susceptibles de modifier les positions du maillage, tels que le décalage de la position du monde (WPO) ou le décalage de la profondeur du pixel (PDO).

Si une lumière se déplace lentement ou si une lumière directionnelle changeante modifie l'heure du jour, les pages de VSM ne sont pas mises en cache du tout. Dans des situations telles que les changements en fonction de l'heure du jour, il est recommandé de quantifier les changements par petits incréments pour permettre aux pages en cache d'exister pendant un certain nombre d'images, car les légères différences de direction ne seront pas perceptibles.

Dans une prochaine version, la mise en cache devrait être améliorée par l'ajout d'un système de priorité et de budget de mise à jour par image pour permettre un contrôle plus fin du coût de rendu des ombres, par exemple en diminuant temporairement la résolution de l'ombre dans les cas où un trop grand nombre de pages doit être mis à jour.

Gérer les invalidations du cache

La meilleure façon de réduire les invalidations du cache est de visualiser les invalidations, puis de rechercher et de réduire les éléments qui les provoquent. La visualisation des pages en cache est un bon point de départ.

Visualisation des pages en cache

Dans cette visualisation, les pages qui sont entièrement mises en cache s'affichent en vert. Les nouvelles pages ou celles invalidées s'affichent en rouge. Lorsque vous déplacez la caméra, attendez-vous à voir de petits anneaux rouges près des bords de l'écran, des limites de clipmap et de la géométrie désoccluse. Avec une caméra statique, la plupart des nouvelles pages proviennent des invalidations du cache.

Si vous activez séparément la mise en cache statique (voir ci-dessous), les pages qui sont partiellement mises en cache (où seule la partie statique est valide) apparaissent en bleu.

Une fois les zones problématiques détectées, il est souvent utile d'activer une visualisation des limites de l'objet qui sont à l'origine des invalidations en utilisant la variable de console r.Shadow.Virtual.Cache.DrawInvalidatingBounds 1. Inspectez ces objets et leurs limites pour vous assurer qu'il s'agit bien d'objets devant invalider les ombres, et que leurs limites sont aussi étroites que possible. Étant donné que toutes les pages qu'un objet d'invalidation peut potentiellement chevaucher à l'intérieur de ses limites doivent être invalidées, même des limites modérément augmentées combinées à des angles de lumière de faible intensité peuvent entraîner de nombreuses invalidations inutiles.

Pages en cache et visualisation des limités invalidées

Les invalidations qui se trouvent entièrement dans l'ombre des objets Nanite peuvent être ignorées, bien que ce ne soit pas le cas pour les objets non Nanite. C'est pourquoi il est particulièrement important de s'assurer que les grands objets qui projettent des ombres, comme les bâtiments, utilisent Nanite.

Dans les scènes complexes, il peut parfois être difficile de déterminer avec précision l'origine des invalidations, même avec ces visualisations. Vous pouvez faire appel à un autre outil, à savoir le mode de visualisation Générer uniquement la géométrie à l'origine de l'invalidation de la VSM, qui se trouve dans le hublot du niveau sous Afficher > Visualiser.

Lorsque cette fonction est activée, toute géométrie qui ne provoque pas d'invalidations du cache est masquée.

En raison de détails de mise en œuvre, le mode Générer uniquement la géométrie à l'origine de l'invalidation de la VSM présente parfois des objets qui ne sont pas liés à l'ombrage (tels que les particules et les effets visuels), et qui font l'objet d'un rendu distinct et sont générés au-dessus.

Les statistiques ne sont pas fiables lors de l'utilisation de cette visualisation, car le rendu de la scène principale a une incidence différente sur les pages mappées et invalidées. Il est préférable de commencer par d'autres modes de visualisation et d'utiliser celui-ci pour effectuer une vérification.

Il existe un problème connu avec les composants de capture de scène susceptible d'entraîner l'invalidation de l'ensemble du cache.

Déformation et feuillage non Nanite

La géométrie qui peut être déformée à l'aide de l'animation squelettique, ou les matériaux utilisant le décalage de la position du monde ou le décalage de la profondeur de pixel invalident toujours les pages mises en cache à chaque image. Par définition, ces cas doivent également être non Nanite (ce qui est plus coûteux) ; il est donc extrêmement important d'utiliser ces fonctionnalités avec soin et de maîtriser les limites.

Dans certains cas, par exemple l'herbe et parfois le feuillage, l'utilisation des ombres de contact suffit à se substituer aux cartes d'ombres haute résolution. Dans les cas où il est nécessaire de disposer d'ombres très détaillées au premier plan, envisagez de prendre les mesures suivantes pour réduire le coût des performances :

• Les objets non Nanite respectent toujours les paramètres habituels de suppression des ombres du CPU, tels que r.Shadow.RadiusThreshold. Utilisez-les pour contrôler le coût de rendu de ces objets dans les cartes d'ombres virtuelles.
• Dans les scènes où le feuillage est dense, il est fortement recommandé de désactiver les objets non Nanite dans les pages grossières avec r.Shadow.Virtual.NonNanite.IncludeInCoarsePages 0. Vous pouvez également envisager de désactiver entièrement les pages grossières si elles ne sont pas nécessaires.
• Utilisez les LOD du maillage pour basculer sur des matériaux qui n'utilisent pas le décalage de la position du monde ou le décalage de la profondeur de pixel à des distances où l'effet n'est plus évident. Dans certains cas, il est possible de désactiver la projection d'ombres dynamiques pour ces objets éloignés et de se fier entièrement aux ombres de contact de l'espace écran.

Pour les lumières directionnelles, des options supplémentaires sont disponibles :

• Les ombres de champ de distance prennent le relais de la géométrie non Nanite au-delà de la distance Lumière mobile de distance d'ombre dynamique définie par la section Cartes d'ombres en cascade de la lumière. Le basculement sur les ombres de champ de distance pour les objets non Nanite éloignés peut améliorer considérablement les performances, car cette géométrie ne dispose pas de la mise à l'échelle LOD plus détaillée qu'offre Nanite.

• Dans certains cas, la création de LOD de matériaux qui suppriment le décalage de la position du monde ou le décalage de la profondeur de pixel peut s'avérer peu pratique, mais l'effet final de ces transformations a peu d'impact sur la distance. Utilisez r.Shadow.Virtual.Cache.MaxMaterialPositionInvalidationRange pour définir une distance (en centimètres) au-delà de laquelle les invalidations du cache de ces matériaux sont ignorées.

  Cela peut créer des ombres « maculées » et entraîner l'auto-ombrage incorrect des objets si le mouvement est important, bien que les artefacts permettent souvent d'obtenir un équilibre entre performances et praticité.

Mise en cache statique distincte

Cette fonctionnalité est encore expérimentale.

De nombreuses scènes se composent d'une grande quantité de géométrie statique (qui ne bouge jamais) ainsi que d'une quantité nettement plus faible de géométrie dynamique (ou mobile). Par défaut, cela signifie que la géométrie dynamique, relativement bon marché, invalide les pages qui entraînent ensuite un nouveau rendu de la géométrie statique coûteuse, uniquement pour mettre à jour la partie dynamique.

Pour une meilleure optimisation dans ces cas, vous pouvez activer un mode facultatif appelé Mise en cache statique distincte en utilisant r.Shadow.Virtual.Cache.StaticSeparate 1. Ce mode multiplie par deux la taille du pool de pages physiques afin que la géométrie statique d'une page spécifique puisse être mise en cache séparément de la géométrie dynamique. Même lorsque la géométrie dynamique se déplace, il n'est pas nécessaire de la générer à nouveau. Au lieu de cela, il est possible de composer la page statique mise en cache par-dessus à un faible coût. Dans certains cas, comme celui du projet d'exemple Valley of the Ancients, il peut s'agir d'une optimisation significative des performances, car le terrain statique est très coûteux alors que les éléments dynamiques sont relativement bon marché.

Lorsque vous utilisez ce mode, il est important de définir avec précision la mobilité des acteurs dans la scène. En particulier, si un acteur défini sur la mobilité statique se déplace, voire utilise un matériau avec un décalage de la position du monde ou des matériaux non pris en charge, il invalide à la fois les pages dynamiques et statiques mises en cache, ce qui entraîne des frais généraux sans aucun gain. À l'inverse, si une trop grande partie de la géométrie coûteuse est définie comme mobile, la mise en cache distincte ne présente que peu d'avantages.

Les statistiques de la carte d'ombres virtuelles sont un bon moyen d'obtenir une vue d'ensemble de l'efficacité de la mise en cache statique. En particulier, le nombre de pages statiques « invalidées » doit être proche de 0. Rechercher les instances qui invalident fréquemment le cache statique et les faire passer en mode Mobile est un moyen efficace de garantir la validité du cache statique.

Nanite comprend un mode de visualisation avancé pour déterminer la mobilité des objets dans le monde, ce qui est également utile pour les cartes d'ombres virtuelles.

Mode de visualisation statique des cartes d'ombres virtuelles avancées de Nanite

Vous pouvez activer ce mode de visualisation de deux façons :

• Activez les options de visualisation avancées de Nanite avec r.Nanite.Visualize.Advanced 1, puis utilisez le hublot du niveau pour sélectionner Mode d'affichage > Visualisation Nanite et choisir Carte d'ombres virtuelles statique dans la liste des options de visualisation.

  Cliquez sur l'image pour l'afficher à sa taille réelle.

• Vous pouvez éventuellement activer la visualisation Carte d'ombres virtuelles statique avec la commande r.Nanite.Visualize vsmstatic.

Profilage et optimisation du processeur graphique

L'Unreal Engine dispose d'outils vous permettant de vérifier les performances de vos projets. Le profileur du processeur graphique (ou un outil propre à la plateforme) est un bon point de départ pour résoudre et déboguer les problèmes de performances.

Les coûts du VSM apparaissent dans deux compartiments principaux de performances : Profondeur des ombres et Projection des ombres (sous Lumières). Les compromis dans chacune de leurs catégories sont relativement indépendants les uns des autres.

N'oubliez pas que les commandes utilisées pour répertorier les statistiques, telles que stat gpu et les compteurs associés, peuvent fournir des délais peu fiables, en particulier si les performances de votre projet sont liées au processeur graphique.

Profondeurs des ombres

La catégorie Profondeurs des ombres désigne le coût de rendu de la géométrie dans les cartes d'ombres.

• RenderVirtualShadowMaps(Nanite) contient le rendu complet de la géométrie Nanite en VSM. Toutes les lumières directionnelles sont rendues en une seule passe Nanite, et toutes les lumières locales sont exécutées dans une seconde passe.
• RenderVirtualShadowMaps(Non-Nanite) gère le rendu de la géométrie non Nanite. Chaque lumière visible fait l'objet d'une passe distincte avec des appels de génération individuels pour les différents objets et instances, comme pour le rendu conventionnel des cartes d'ombres.
• Atlas et Cubemap, ainsi que d'autres passes similaires qui suivent les passes VSM, effectuent un rendu des cartes d'ombres conventionnelles. Certains types de géométries, bien que peu nombreux, ne sont pas encore pris en charge par la méthode Cartes d'ombres virtuelles ; ceux-ci doivent suivre l'ancienne méthode. En l'absence de géométrie non prise en charge qui projette des ombres, ces passes ne sont pas exécutées ou n'allouent pas de stockage de cartes d'ombres. Ces passes et les frais généraux associés peuvent être désactivés entièrement avec la variable de console r.Shadow.Virtual.ForceOnlyVirtualShadowMaps 1 ; dans ce cas, tous les types de géométries non pris en charge ne projettent pas d'ombres.

Le coût du passage des profondeurs d'ombres avec les VSM est directement lié au nombre de pages d'ombre à rendre et à la quantité de géométrie à rendre dans ces pages. Le rendu de la géométrie non Nanite est beaucoup plus onéreux dans les VSM que celui de la géométrie Nanite. Pour cette raison, il est recommandé d'activer Nanite sur toutes les géométries prises en charge, y compris les maillages Low Poly. La seule exception concerne les fonctionnalités qui ne sont pas encore prises en charge par la géométrie virtualisée Nanite.

Comprendre le nombre de pages en cours de génération

Les statistiques à l'écran concernant les pages VSM utilisées peuvent donner une idée du nombre de pages utilisées et indiquer où rechercher les problèmes éventuels en vue de les résoudre.

Utilisez successivement les variables de console suivantes pour activer les statistiques :

• r.ShaderPrintEnable 1
• r.Shadow.Virtual.ShowStats 1 (ou 2 pour afficher uniquement les statistiques de la page)

Le nombre total de pages est fonction du nombre moyen de lumières ayant une incidence sur chaque pixel à l'écran. Il est possible de diminuer ce nombre en réduisant la résolution de l'écran, la résolution des ombres (à l'aide des variables de console pour la polarisation LOD de résolution), l'étendue des lumières ou le nombre de lumières projetant des ombres.

Les mauvaises performances dans les profondeurs d'ombres sont généralement associées à l'utilisation d'un nombre élevé de pages et à une invalidation dynamique importante, ce qui entraîne une mise en cache incorrecte des VSM. Consultez la section Mise en cache pour en savoir plus sur le diagnostic et la réduction des invalidations du cache.

Améliorer les performances non Nanite

Outre l'amélioration de la mise en cache, il existe différents moyens d'améliorer les performances du rendu des ombres non Nanite.

Tenez compte des points suivants pour améliorer les performances des objets non Nanite :

• Activez Nanite sur autant de géométries possibles pour votre projet.
  • La géométrie Nanite est beaucoup plus efficace dans les cartes d'ombres virtuelles, et vous devez privilégier son utilisation dans tous les cas, quel que soit le nombre de polygones.
  • La géométrie Nanite peut occulter la géométrie non Nanite et éviter les invalidations intempestives du cache. Ainsi, les seuls objets non Nanite doivent être ceux qui ne sont pas pris en charge par Nanite proprement dit, à savoir les objets déformants (maillages dépouillés), ou les matériaux utilisant le décalage de la position du monde (WPO) et le décalage de la profondeur de pixel (PDO).
• Les objets non Nanite doivent disposer d'une configuration des hiérarchies de LOD de maillage complète.
  • Il est important que les maillages non Nanite disposent d'une configuration de LOD, auquel cas leur rendu devient extrêmement coûteux dans les petites pages.
  • Dans la mesure du possible, il est conseillé de passer à des maillages non déformants (sans matériaux WPO/PDO) au-delà d'une distance où l'effet est évident.
• Les variables de console d'escamotage du CPU sont toujours utiles pour les maillages non Nanite rendus dans des cartes d'ombres virtuelles.
  • Ajustez les valeurs d'escamotage du CPU sur les objets non Nanite rendus dans les cartes d'ombres virtuelles avec la variable de console r.Shadow.RadiusThreshold. Celles-ci peuvent permettre de contrôler le coût des petits objets distants.
• Utilisez des ombres de champ de distance pour l'ombrage à distance des objets non Nanite.
  • Pour les lumières directionnelles, il est souvent nécessaire de basculer sur les ombres de champ de distance au-delà d'une certaine plage, comme pour les cartes d'ombres en cascade. Avec les cartes d'ombres virtuelles, seule la géométrie non Nanite bascule sur l'utilisation d'ombres de champ de distance, tandis que la géométrie Nanite possède toujours des ombres détaillées.
• La désactivation de la géométrie non Nanite dans les pages grossières peut améliorer les performances.
  • La désactivation de la géométrie non Nanite dans les pages grossières peut souvent permettre un gain de performances important, car le rendu de la géométrie non Nanite est généralement inefficace dans les grandes pages.

Les statistiques des cartes d'ombres virtuelles peuvent donner un aperçu du nombre d'instances non Nanite :

Projection des ombres

La catégorie Projection des ombres correspond au coût d'échantillonnage des cartes d'ombres via la méthode de ray-tracing des cartes d'ombres. Ces passes sont situées sous Lumières | Éclairage direct | UnbatchedLights, et il existe généralement une passe de projection VSM par lumière associée. La passe la plus coûteuse est généralement la boucle SMRT principale dans VirtualShadowMapProjection. Les autres doivent être relativement peu coûteuses.

Si la passe de projection est étiquetée RayCount:Static au lieu de RayCount:Adaptive, cela signifie qu'une méthode lente a été adoptée.

La passe de projection VSM décrite dans cette section est différente de la projection expérimentale monopasse décrite dans la section suivante.

La projection d'ombres est purement fonction du nombre total d'échantillons de cartes d'ombres pris sur l'écran, et les performances ne dépendent pas du nombre de pages ou de la mise en cache.

Lors de l'utilisation du SMRT, tenez compte des points suivants :

• Nombre moyen de lumières par pixel
  • Plus le nombre de lumières en contact avec de grandes parties de l'écran est élevé, plus le rendu est coûteux. Les lumières couvrant un petit nombre de pixels à l'écran sont moins onéreuses, bien qu'il y ait toujours des coûts fixes par lumière.
  • Vous devez veiller à ce que la majorité des pixels de l'écran ne soit pas occupée par plusieurs grandes lumières.
• Rayons par pixel
  • La douceur visible des ombres a une incidence sur les performances en raison du nombre de rayons adaptatifs. Essayez de réduire le rayon source des lumières locales ou l'angle source des lumières directionnelles avant de réduire le nombre de rayons et d'échantillons.
• Échantillons par rayon

Ces paramètres sont définis par le paramètre d'évolutivité Ombre, mais vous pouvez les ajuster davantage si nécessaire. Consultez la section Ray-tracing des cartes d'ombres de cette page pour en savoir plus.

En général, les coûts de projection des ombres sont beaucoup plus faciles à contrôler (compromis entre qualité et bruit) que les coûts de profondeur des ombres.

Projection monopasse

Cette fonctionnalité est encore expérimentale. Les noms des variables de console dans cette section sont susceptibles de changer.

Même si le coût de rendu des petites lumières est inférieur, des frais généraux fixes sont quand même associés à chaque passe. Pour résoudre ce problème, nous sommes en train de développer une solution de projection d'ombres monopasse où la plupart des lumières locales d'une scène peuvent évaluer efficacement leur ombrage en une seule passe. Il est alors possible d'appliquer la contribution ombrée de ces lumières en une seule fois en utilisant l'ombrage groupé.

Pour activer cette méthode, utilisez les variables de console r.UseClusteredDeferredShading 1 et r.Shadow.Virtual.OnePassProjection 1. Pour les scènes comportant un grand nombre de petites lumières locales, cela peut se traduire par une amélioration significative des performances.

L'utilisation de certaines fonctionnalités d'éclairage ne permet pas d'intégrer une lumière à un groupe même si la projection monopasse est activée :

• Profils de texture
• Fonctions d'éclairage
• Canaux d'éclairage
• Lumières rectangulaires
• Lumières directionnelles (il n'y a aucun avantage à regrouper ce type de lumières, car elles couvrent la totalité de l'écran)

Dans les captures ci-dessous, la partie gauche montre une passe de projection d'ombre par lumière, et la partie droite une projection monopasse.

Cliquez sur l'image pour l'afficher à sa taille réelle.

Dans la méthode par défaut de gauche, chaque lumière locale est accumulée une par une avec plusieurs passes par lumière. Cette procédure est inefficace pour les petites lumières qui couvrent une petite surface à l'écran.

Dans la nouvelle méthode de droite, toutes les lumières locales ombragées sont réunies en une seule passe d'ombrage groupé (lumières groupées). La lumière directionnelle est toujours rendue dans une passe distincte ; dans la mesure où elle couvre l'ensemble de l'écran, il n'y a aucun avantage à la regrouper.

Chaque lumière locale est toujours injectée séparément dans le volume de translucidité. Cela est moins un problème de performances que de projection, mais il est probable que ces lumières soient également regroupées à l'avenir.

Lorsque la projection monopasse est activée, il est possible de limiter le nombre de lumières ombragées entièrement filtrées par pixel en ajustant le paramètre r.Shadow.Virtual.OnePassProjection.MaxLightsPerPixel, dont la valeur par défaut est de 16. Ceci est utile à la fois pour contrôler les performances et pour économiser une petite quantité de mémoire graphique transitoire.

Si le nombre de lumières ombragées est supérieur à la valeur maximale dans un pixel donné (ou, en pratique, un carreau d'ombrage différé regroupé), les lumières supplémentaires sont ombragées via une recherche d'ombre dure unique et peu coûteuse. Cela peut provoquer des discontinuités visuelles si la valeur est définie de manière trop agressive, mais cela vaut généralement mieux que de désactiver entièrement les ombres des lumières en trop.

Cette passe est encore en développement et n'est pas activée par défaut. La principale mise en garde concerne les cas où une lumière locale disposerait à la fois d'une carte d'ombres virtuelles et d'une carte d'ombres classiques (en raison d'un type de géométrie non pris en charge dans la scène) ; dans ce cas, la méthode Projections monopasse ignore cette dernière, ce qui fait disparaître ces ombres.

Si vous utilisez déjà r.Shadow.Virtual.ForceOnlyVirtualShadowMaps, il est plus sûr d'activer également la projection monopasse. Une fois les limitations actuelles traitées, cette méthode deviendra probablement la méthode par défaut.

Plateformes prises en charge

Les cartes d'ombres virtuelles sont actuellement prises en charge sur les consoles PlayStation 5, Xbox Series S|X et sur les PC équipés de cartes graphiques répondant à ces spécifications et utilisant les derniers pilotes avec DirectX 12 :

• NVIDIA : cartes Maxwell ou plus récentes
• AMD : cartes GCN ou plus récentes
• Toutes les nouvelles versions de Windows 10 (ultérieures à la version 1909.1350) et de Windows 11 prenant en charge le kit SDK Agility DirectX 12 sont prises en charge.
  • Windows 10 version 1909 : le numéro de révision doit être supérieur ou égal à .1350.
  • Windows 10 versions 2004 et 20H2 : le numéro de révision doit être supérieur ou égal à .789.
  • DirectX 12 (avec Shader Model 6.6 atomics), ou Vulkan (VK_KHR_shader_atomic_int64)
• Derniers pilotes graphiques

Problèmes et limites

Les cartes d'ombres virtuelles sont toujours en cours de développement. Leur utilisation présente un certain nombre de problèmes et de limites connus ; par ailleurs, elles sont actuellement destinées aux ordinateurs de bureau haut de gamme et aux consoles de nouvelle génération.

Performances des lumières multiples

Les performances dans les scènes comportant de nombreuses petites lumières locales restent encore à améliorer. Pour l'heure, la meilleure stratégie consiste à activer la projection monopasse et à faire très attention aux invalidations pour maintenir le plus grand nombre possible de pages dans le cache. Étant donné que les lumières locales multiples sont bien plus performantes avec la géométrie Nanite qu'avec la géométrie non Nanite, escamoter ou désactiver la projection d'ombres distantes sur la géométrie non Nanite peut s'avérer très utile. Dans certains cas, il peut être souhaitable de désactiver entièrement la projection d'ombres dynamiques sur les lumières distantes et de se fier uniquement aux ombres de contact de l'espace écran.

À l'avenir, des commandes plus puissantes seront disponibles pour trouver des compromis algorithmiques et de qualité ainsi que pour limiter les mises à jour dans ces cas.

Géométrie Low Poly

Les géométries Low Poly (c'est-à-dire ayant un nombre relativement faible de polygones) avec une forte courbure et des normales lisses peuvent présenter des artefacts. Ce phénomène est appelé « problème de terminateur d'ombres ». Il se produit également dans le ray-tracing et d'autres requêtes de visibilité très précises. Ce problème provient de la discordance entre la géométrie Low Poly réelle et les normales d'ombrage « lisses » : dans la zone proche du terminateur, certaines de ces faces se trouvent géométriquement dans l'ombre, mais les normales d'ombrage non géométriques sont légèrement orientées vers la lumière. Il est courant de contourner cet artefact en appliquant une polarisation basée sur les normales à la recherche d'ombre. Cet artefact particulier se manifeste davantage avec les cartes d'ombres virtuelles car, par défaut, celles-ci sont configurées pour créer des ombres très détaillées à partir de la géométrie Nanite.

La meilleure façon de résoudre ce problème est d'augmenter le nombre de polygones dans ces objets/régions. Limitez la divergence entre les normales géométriques et les normales d'ombrage pour réduire ou éliminer ces artefacts sans nuire à la qualité des ombres ailleurs. Avec Nanite, l'ajout de polygones supplémentaires est simple et généralement peu coûteux. Si les objets incriminés ne peuvent pas utiliser Nanite, l'ajout d'un niveau de détail (LOD) plus élevé fonctionne bien aussi, car ces artefacts sont surtout visibles lorsque les objets sont proches de la caméra.

S'il n'est pas possible d'ajouter plus de géométrie, vous pouvez augmenter la polarisation basée sur les normales de la carte d'ombres virtuelles en utilisant r.Shadow.Virtual.NormalBias (par défaut de 0,5). Envisagez d'adopter cette procédure uniquement lorsque les ajustements de contenu ne sont pas possibles, car elle aura un impact négatif sur la qualité des ombres dans toute la scène, mais particulièrement dans les zones détaillées.

Dans les exemples ci-dessous, les artefacts sont visibles sur une sphère Low Poly près de la caméra avec une géométrie très détaillée en arrière-plan. L'ajout de polygones à la sphère améliore les artefacts sans aucun impact négatif sur le paysage détaillé en arrière-plan.

L'ajustement de la polarisation améliore également les artefacts, mais les détails sont visiblement perdus dans la géométrie de l'arrière-plan.

Réalité virtuelle

La réalité virtuelle n'est pas encore totalement prise en charge par les cartes d'ombres virtuelles. Des artefacts risquent probablement de se produire avec les lumières directionnelles dans l'œil droit.

Écran partagé

L'écran partagé n'a pas été suffisamment testé et peut présenter des performances médiocres.

Débordement du pool de pages physiques

Avec les cartes d'ombres virtuelles, toutes les données relatives aux ombres de la scène pour l'ensemble des lumières sont stockées dans un vaste pool de textures unique. La taille du pool par défaut dépend du paramètre d'évolutivité Ombre, mais il peut être nécessaire de l'ajuster dans les scènes comportant de nombreuses lumières faisant appel à des ombres haute résolution.

Il peut également être nécessaire d'ajuster ce paramètre sur du matériel bas de gamme en vue d'économiser la mémoire vidéo.

Pour ajuster la taille du pool de pages, utilisez r.Shadow.Virtual.MaxPhysicalPages. Activer les statistiques de la carte d'ombres virtuelles avec r.ShaderPrintEnable 1 et r.Shadow.Virtual.ShowStats 2, successivement, permet d'afficher des statistiques sur l'utilisation du pool de pages actuel.

Exemple d'utilisation du pool de pages actuel à partir des statistiques à l'écran de la carte d'ombres virtuelles.

Si le nombre de pages dépasse la valeur Pages max., une erreur risque de se produire, qui se manifeste parfois visuellement par un motif en damier, ou des ombres endommagées ou manquantes. En cas de débordement du pool de pages d'ombres, un avertissement s'affiche à l'écran et dans le journal.

Exemple de cartes d'ombres virtuelles endommagées en raison d'un nombre excessif de pages dans le pool de pages.

Dans ce cas, augmentez la taille du pool de pages ou diminuez la résolution de l'ombre ou le nombre de lumières de la carte d'ombres virtuelles.

Capture de la scène

Dans certains cas, les composants Capture de la scène peuvent entraîner l'invalidation de la totalité du cache de la carte d'ombres virtuelles. Ce problème se manifeste généralement par un nombre d'invalidations faible dans les statistiques de la carte d'ombres virtuelles, et par un nombre de pages mises en cache également faible (voire nul) ; par ailleurs, la visualisation des pages mises en cache est uniformément rouge.

Dans ce cas, essayez de masquer/supprimer tous les acteurs de capture de scène dans la scène pour vérifier s'ils sont à l'origine du problème.

Il n'existe actuellement aucune solution temporaire autre que la désactivation de la capture de scène.

Matériaux

Seuls les matériaux de subsurface simples sont pris en charge. Le profil et la transmission de subsurface ne sont pas encore mis en œuvre. Si un matériau les utilise, il est ombragé même s'il est opaque.

Résolution des ombres

Bien que les cartes d'ombres virtuelles offrent une bien meilleure résolution que les cartes d'ombres conventionnelles, les angles de lumière superficiels (ou le crénelage projectif) et les lumières locales très volumineuses peuvent épuiser la résolution virtuelle disponible. Ce problème peut se traduire par des ombres carrées et des problèmes de polarisation selon la surface de la géométrie.

Les clipmaps de lumière directionnelle sont beaucoup moins susceptibles de manquer de résolution, mais les champs de vision très étroits de la caméra peuvent également l'épuiser.

Il n'existe pas de solution simple pour résoudre le crénelage projectif avec les cartes d'ombres. Même avec les cartes d'ombres virtuelles, vous devez éviter les pires cas, et trouver un équilibre entre résolution et performances.

Avertissements de vérification des cartes

Les cartes d'ombres virtuelles génèrent des avertissements de vérification de cartes inexactes :

• Le message L'éclairage doit être recréé n'apparaît pas lorsque les cartes d'ombres virtuelles sont activées, même si l'éclairage doit être recréé si vous n'utilisez pas les fonctionnalités Illumination globale et reflets Lumen. Bien que l'éclairage direct fixe soit dynamique lorsque les cartes d'ombres virtuelles sont activées, l'éclairage indirect fixe est toujours généré.
• Les avertissements concernant les ombres préalables peuvent être ignorés, car ils ne sont pas pertinents lors de l'utilisation de cartes d'ombres virtuelles.