Réglage de la fréquence d'images des scènes 3DGS sous UE5

Étape un : localiser le goulot d'étranglement

Avant de toucher au moindre paramètre, confirmez que la baisse de fréquence d'images est bien causée par le 3DGS. L'éclairage, les ombres, le post-traitement, les modèles classiques et la logique Blueprint de la scène peuvent tous être le véritable goulot d'étranglement, et dans ce cas aucun réglage des paramètres LCC n'apporte d'amélioration.

Confirmer que le goulot d'étranglement vient du 3DGS

Masquez ou supprimez tout ce qui n'est pas du 3DGS dans la scène et comparez la fréquence d'images :

1. Relevez la fréquence d'images actuelle comme référence (stat fps ou stat unit).
2. Masquez le LCC Actor, gardez le reste de la scène et relevez la fréquence d'images.
3. Faites l'inverse : ne gardez que le LCC Actor, masquez ou supprimez les autres modèles, les lumières, les Post Process Volumes et l'UI, puis relevez la fréquence d'images.

Quand la scène d'origine contient beaucoup d'éléments et qu'un masquage un par un est impraticable, la méthode la plus propre est de créer un niveau vide contenant un seul LCC Actor qui charge les mêmes données, puis de relever la fréquence d'images sous le même angle de vue. Cela écarte toute interférence de la scène d'origine et donne la référence de performance du 3DGS lui-même.

Comparez les trois séries de mesures :

Écarter d'abord les éléments de scène par défaut du moteur

Un nouveau niveau embarque un lot d'Actors par défaut, dont plusieurs ne sont pas gratuits, ce qui les fait facilement passer pour un coût du 3DGS. Le plus typique est VolumetricCloud : il effectue un ray marching volumétrique à chaque image et continue de consommer du GPU même quand seule une petite portion de ciel est visible.

Quand le projet n'a pas besoin d'effets de ciel, supprimez directement les Actors suivants du niveau :

Les données 3DGS contiennent déjà généralement l'information d'environnement, ces effets sont donc inutiles dans la plupart des cas. Mesurez à nouveau la fréquence d'images après suppression, puis évaluez s'il reste des paramètres LCC à ajuster.

Gardez les conditions de test identiques, sinon les mesures ne sont pas comparables : même map et même point de départ, même position ou même trajectoire de caméra, même résolution et même Screen Percentage, et même état d'activation pour Lumen, les Virtual Shadow Maps, le post-traitement et SceneCapture. Faites d'abord un passage de préchauffage avant de relever les mesures, pour que la première compilation de shaders et le premier accès disque ne se mélangent pas à la fréquence d'images stabilisée. Ne changez qu'une catégorie de réglages à la fois.

Commandes d'observation courantes :

stat fps         // Frame rate
stat unit        // The four frame times: Frame / Game / Draw / GPU
stat gpu         // GPU Pass breakdown
stat rhi         // Draw calls, primitives, video memory
ProfileGPU       // Per-frame GPU Pass detail

Utiliser les statistiques LCC une fois le 3DGS confirmé

Ouvrez le panneau de statistiques avec Actions > Stats dans le panneau de l'Actor, ou saisissez stat xgrids dans la console.

Consultation des statistiques de performance LCC en temps réel avec stat xgrids

Pour le détail des paramètres, voir Paramètres de performance : statistiques

Regardez en priorité Current Render Main Splats et Current Render Nodes : la cause directe de la plupart des problèmes de performance est un nombre de points rendus simultanément à l'écran trop élevé.

Activer en même temps la visualisation du LOD

Pendant la lecture des statistiques, utilisez Actions > Debug Node Bound dans le panneau de l'Actor pour visualiser les Levels des nœuds et confirmer directement la répartition du LOD dans la vue courante. Plus la couleur est chaude, plus le Level est bas et le détail élevé.

L'idée de l'optimisation est de réduire autant que possible le nombre de points à l'écran tant que le rendu visuel reste acceptable, en regardant jusqu'où le Level 0 s'étend :

• Jusqu'où les zones aux couleurs chaudes s'étendent-elles dans l'image ? Les données de précision maximale sont-elles réellement nécessaires à cette distance ?
• Si le passage aux Levels plus grossiers survient plus tôt, la perte visuelle est-elle perceptible ?

Dans la plupart des scènes, le Level 0 porte bien plus loin que nécessaire, et le faire basculer plus tôt vers des Levels plus grossiers fait chuter le nombre de points immédiatement : c'est le moyen le plus rentable parmi tous ceux qui échangent la qualité d'image contre les performances. Une fois la marge confirmée, essayez d'abord la rastérisation Tiled de la section suivante, puis passez à l'étape deux pour régler Level Factor.

Avant de régler les paramètres : essayer la rastérisation Tiled [expérimental, édition Pro, pipeline LCC2 uniquement]

Toutes les étapes suivantes échangent la qualité d'image contre les performances. Pas celle-ci : passer Rasterizer de Pipeline à Tiled sur l'Actor laisse le résultat visuel inchangé. Quelques minutes d'essai valent la peine, car si cela fonctionne, les compromis de qualité restants seront moindres.

Une seule propriété change, aucun autre paramètre n'est à ajuster en conséquence :

LCC2Component->SetRasterizer(ELCC2Rasterizer::Tiled);

C'est un chemin expérimental et le gain n'est pas garanti : il est net sur les images à forte densité de splats et à fort recouvrement écran, et il peut n'y avoir aucun changement sur les images éparses ou quand le goulot d'étranglement ne se situe pas au départ dans le tri et le remplissage des pixels. Mesurez donc après le changement : comparez le temps d'image GPU avant et après avec stat unit sous le même angle de vue. S'il ne baisse pas, le goulot d'étranglement est ailleurs ; repassez à Pipeline et poursuivez avec les étapes suivantes.

Trois cas rendent cette étape inutile : des données .lcc chargées, le mode de rendu nuage de points employé, ou aucune App Key enregistrée (repli automatique sur Pipeline). Pour le périmètre d'application et le comportement de repli, voir Rastérisation Tiled.

Notez également que Tiled réduit le coût de l'étape de rendu ; le travail de chargement, de traversal et d'upload reste inchangé, il n'aide donc pas quand le goulot d'étranglement se situe du côté du chargement.

Étape deux : ajuster le LOD

C'est l'étape au bénéfice le plus net. Dans la plupart des scènes, le Level 0 porte bien au-delà du nécessaire, et le faire basculer plus tôt vers des Levels plus grossiers fait chuter immédiatement le nombre de points à l'écran, le plus souvent sans changement perceptible du rendu visuel. Faites cette étape en premier, puis envisagez les moyens suivants.

Le LOD possède trois boutons indépendants (Level Factor, Start Level, End Level)

Configuration de Level Factor, Start Level et End Level

2.1 Déterminer d'abord comment agit Level Factor

Les deux pipelines choisissent les Levels selon des mécanismes différents, donc Level Factor agit également différemment, mais le sens est le même : plus la valeur est grande, plus les nœuds basculent tôt vers des Levels de détail plus faible.

Pipeline LCC2 : erreur en espace écran

LCC2 n'utilise pas RangeForLevel : il calcule pour chaque nœud une erreur en espace écran, c'est-à-dire le nombre de pixels que couvre l'erreur géométrique du nœud lui-même une fois projetée à l'écran. Quand l'erreur dépasse le seuil, l'affinage se poursuit vers les nœuds enfants plus fins ; sinon il reste au Level courant.

Cette erreur dépend à la fois de la distance du nœud, de l'angle de vue et de la résolution d'écran : un même Level Factor ne donne donc pas la même distance de bascule réelle selon les résolutions ou les FOV. Cela signifie aussi que la répartition du LOD de LCC2 ne se calcule pas à l'avance avec une table de distances et ne peut être observée qu'en pratique avec le Debug Node Bound de la section 2.5.

Le réglage fonctionne comme sur la pipeline LCC, passez directement à l'échelle de test de la section 2.2.

Pipeline LCC : table de distances

Level Factor divise le tableau global RangeForLevel par sa valeur. Plus la valeur est grande, plus la distance d'action de chaque Level est courte et plus les nœuds entrent tôt dans un Level de détail plus faible.

Valeurs par défaut de RangeForLevel (11 entrées, ProjectSettings > Plugins > LCC4Unreal > Level) :

Level:  0    1    2    3    4    5    6    7    8    9    10
meters: 15   50   80  110  140  170  190  220  250  280   350

Distances d'action après division par Level Factor (en mètres, valeurs non entières affichées arrondies) :

Comment lire cette table : avec Level Factor = 2, la précision maximale s'appliquait auparavant dans les 15 mètres et ne s'applique plus que dans les 7,5 mètres. C'est bien plus précis que la formule « moitié du détail » : ce qui change, c'est la distance d'action de chaque Level, pas la proportion de points.

La manière exacte dont les Levels sont comparés aux distances (borne supérieure ou inférieure, intervalle ouvert ou fermé) relève de l'implémentation interne ; la table ci-dessus sert à estimer l'ampleur du réglage, et la répartition réelle des Levels se confirme avec le Debug Node Bound de la section 2.5. Cette table ne vaut que pour la pipeline LCC.

Au-delà de la dernière entrée de RangeForLevel, un nœud utilise simplement le Level le plus grossier dont il dispose : il n'existe pas de cas où aucun Level n'est trouvé. Monter Max Distance au-delà de 350 mètres ne demande donc aucun ajustement de cette table.

Configuration du tableau de distances Range For Level dans les paramètres du projet

2.2 Level Factor

Pour la plage et la valeur par défaut, voir Paramètres de performance : Level Factor

C'est le bouton de LOD à privilégier, parce qu'il agit progressivement et ne supprime pas tout un niveau de détail d'un coup.

Échelle de test :

1.0 → 1.25 → 1.5 → 2.0

À vérifier en priorité : les contours, les lignes fines, les petits objets, les détails du sol et les zones de transition entre Levels. C'est là que le manque de détail et le popping de LOD se révèlent en premier.

Changements de LOD après ajustement de Level Factor

2.3 Start Level

Pour la plage et la valeur par défaut, voir Paramètres de performance : Start Level

L'augmenter saute purement et simplement les Levels aux numéros les plus bas (les plus fins) :

0 → 1 → 2

C'est bien plus agressif qu'un léger ajustement de Level Factor : il écarte des niveaux entiers au lieu de mettre des distances à l'échelle. À n'utiliser que si les deux conditions sont réunies : stat xgrids montre que Level0 Splats est bien le poste de coût principal, et une qualité plus grossière au premier plan est acceptable. Revenez à 0 dès que le premier plan devient visiblement flou.

Saut des Levels de détail élevé après augmentation de Start Level

2.4 End Level (normalement inchangé)

Pour la plage et la valeur par défaut, voir Paramètres de performance : End Level

Le baisser limite le Level le plus grossier utilisable : les Levels plus grossiers présents dans les données ne sont jamais utilisés, le contenu lointain ne peut rester qu'à End Level, et plus de points sont rendus que nécessaire. Ce n'est pas un bouton d'accélération : restez à la valeur par défaut, sauf si la structure des Levels des données est déjà comprise.

Start Level <= End Level doit être respecté ; le Setter ne le vérifie pas pour vous.

Limitation des Levels de détail faible après ajustement de End Level

2.5 Vérifier avec Debug Node Bound

Actions > Debug Node Bound dans le panneau de l'Actor visualise les limites des nœuds et leurs Levels. La séquence de couleurs est rouge, orange, jaune, vert, bleu, violet, où le rouge est le Level le plus bas (le détail le plus élevé) et le blanc représente le Level le plus haut (le détail le plus faible).

Utilisez-le après un changement des paramètres de LOD pour vérifier : si le premier plan reste rouge/orange (détail élevé), si le lointain passe régulièrement vers les couleurs froides, et s'il existe une zone qui bascule à répétition entre Levels à distance égale.

Vérification de la répartition du LOD avec Debug Node Bound

Points de vérification du LOD

• Si le nombre de nœuds et le nombre de splats baissent ;
• Si le premier plan devient grossier trop tôt ;
• Si un popping de LOD net apparaît pendant les déplacements de caméra ;

Étape trois : distance de rendu maximale

Pour la plage et la valeur par défaut, voir Paramètres de performance : Max Distance(m)

Réglage de la distance de rendu maximale Max Distance

En quoi cela diffère du LOD

Max Distance supprime franchement les données au-delà de la distance et réduit l'étendue spatiale rendable ; le LOD baisse la précision à l'intérieur de cette étendue. Les deux sont complémentaires : utilisez-le pour resserrer encore l'étendue quand la pression persiste après le réglage du LOD.

Il peut réduire les nœuds candidats ainsi que le travail de traversal, de chargement, d'upload, de tri et de remplissage qui suit, mais l'ampleur de la réduction dépend de l'implémentation et des données : vérifiez donc avec de vraies statistiques au lieu de supposer un ratio de gain fixe.

Cochez d'abord la case, sinon les changements n'ont aucun effet

Chaque paramètre de la catégorie Performance possède une case à cocher sur sa gauche. Tant que la case n'est pas cochée, la valeur du champ de texte n'a aucun effet, et la valeur par défaut intégrée au plugin est utilisée à l'exécution. Vérifiez ici en premier quand un ajustement ne change rien.

Étapes de réglage de la distance

1. Placez-vous à l'endroit de la scène où les données du modèle doivent être visibles le plus loin possible, et mesurez la distance réellement nécessaire.
2. Cochez la case à gauche du paramètre.
3. Réglez sur « distance maximale de visibilité réelle + marge nécessaire ».
4. Resserrez progressivement, sans descendre d'un coup à une valeur très basse :

300 m (default) → 225 m → 150 m → fine-tune to the actual project distance

Ce qui précède est une échelle de test, pas une valeur recommandée. Les valeurs sensées diffèrent beaucoup entre intérieurs, quartiers, grandes scènes et vues aériennes : mesurez selon le projet.

Changements de l'étendue de rendu après ajustement de Max Distance

Points de vérification de la distance

• Si Current Render Nodes et Current Render Splats baissent ;
• Si les GPU ms ou le Traversal Time baissent ;
• Si du contenu disparaît brusquement en s'approchant de la limite lointaine ;
• Si les zones non chargées deviennent plus visibles pendant les déplacements rapides ;

Étape quatre : fixer une limite stricte du nombre de points

Pour la plage et la valeur par défaut, voir Paramètres de performance : Max Splat Num

Max Distance contrôle l'étendue spatiale, mais la densité des données dans une même étendue peut varier énormément. Max Splat Num fournit une limite supérieure de la charge par image, qui évite que le nombre de points explose à l'entrée d'une zone à forte densité. Il est complémentaire du LOD et de la distance, et ne remplace ni l'un ni l'autre.

Notez que les valeurs trop grandes sont automatiquement ramenées au volume que le GPU peut rendre en une image : pousser la valeur du panneau jusqu'à la limite ne dépasse pas la capacité matérielle et rend simplement cette limite inopérante. Pour qu'elle agisse réellement, réglez-la sous le nombre de points effectif de la vue courante.

Réglage de la limite de points par image Max Splat Num

Étapes de réglage de la limite de points

1. Cochez la case à gauche du paramètre.
2. Baissez-la proportionnellement à partir de la valeur par défaut, l'unité étant 10 000 :

3000 → 2250 → 1500 → 1000

3. Après chaque baisse, observez dans une zone à forte densité, pas seulement dans les zones dégagées.

Changements du nombre de points et de l'image après ajustement de Max Splat Num

Points de vérification de la limite de points

• Si les GPU ms et Current Render Splats baissent en même temps que la limite ;
• Si un amincissement local, un scintillement ou des structures transparentes brisées apparaissent.

Si ni le nombre de points ni les GPU ms ne changent après la baisse de la limite, c'est que la vue courante n'atteint jamais cette limite et que ce n'est pas le goulot d'étranglement actuel : revenez à l'étape un pour le localiser à nouveau.

Étape cinq : réduire le coût de remplissage des pixels

5.1 SplatScale

Pour le détail du paramètre, voir Réglages visuels : SplatScale

Le réduire diminue la surface écran couverte par un splat isolé et réduit donc le recouvrement translucide.

Méthode : le baisser par petits pas depuis la valeur de qualité actuelle, en vérifiant à haute résolution, au premier plan et le long des contours d'objets. Une baisse excessive fait apparaître des trous dans les surfaces ou les rend visiblement fines.

Ajustement de SplatScale pour réduire la surface écran couverte par les points gaussiens

5.2 Small Splat Threshold (px) (pipeline LCC2 uniquement)

Pour la plage et la valeur par défaut, voir Paramètres de performance : Small Splat Threshold (px)

Testez-le en direct avec une CVar, sans redémarrage :

r.LCC2.SmallSplatThreshold 0
r.LCC2.SmallSplatThreshold 0.5
r.LCC2.SmallSplatThreshold 1

Plus la valeur est haute, plus le gain potentiel est grand et plus l'aspect granuleux du lointain est marqué. Ne continuez à l'augmenter que si le GPU ou le calcul des SH est réellement le goulot d'étranglement ; quand les données elles-mêmes n'ont pas de SH, le gain du saut des SH est limité.

Réglage du seuil en pixels Small Splat Threshold

5.3 Quad Extent Threshold (pipeline LCC2 uniquement)

Pour la plage et la valeur par défaut, voir Paramètres de performance : Quad Extent Threshold

Augmenter cette valeur produit des quads plus serrés et réduit l'overdraw, mais peut couper les bords semi-transparents.

r.LCC2.QuadExtentThreshold 0.006 → 0.008 → 0.01

Revenez en arrière quand les contours durcissent, que des bords manquent ou que les formes de splats semblent anormales.

Réglage de Quad Extent Threshold pour contrôler l'étendue du quad de splat

5.4 Frustum Cull Margin (pipeline LCC2 uniquement)

Pour la plage et la valeur par défaut, voir Paramètres de performance : Frustum Cull Margin

Il contrôle la marge de culling, pas la limite du nombre de points.

N'essayez de le baisser vers 1.0 par petits pas que si aucune apparition brusque ne survient en bordure d'écran :

r.LCC2.FrustumMargin 1.2 → 1.1 → 1.0

Du contenu qui apparaît et disparaît en bordure pendant les rotations rapides de caméra signifie que la baisse est allée trop loin.

Réglage de la marge de culling de frustum Frustum Cull Margin

5.5 Anticrénelage

Le coût GPU de l'anticrénelage n'est pas faible, et TSR est particulièrement notable. Quand la scène ne contient que du 3DGS, sans maillages classiques ni UI, régler l'option correspondante sur None perd généralement très peu de qualité d'image pour un gain de fréquence d'images substantiel.

Pour la méthode par défaut de chaque pipeline et les compromis, voir Paramètres de performance : méthodes d'anticrénelage.

Configuration de la méthode d'anticrénelage de chaque pipeline LCC

Étape six : désactiver les fonctionnalités inutiles

Les gains de cette étape sont clairs mais chacun a un coût fonctionnel : confirmez point par point que le projet n'en a réellement pas besoin, plutôt que de tout désactiver.

Pour le détail de chaque fonctionnalité, voir Réglages visuels et Paramètres de performance.

Étape sept : tri et mémoire vidéo

Le tri de la translucidité et la gestion de la mémoire vidéo se traitent par pipeline : Sort Factor et le préchargement supplémentaire n'existent que sur LCC1, et le budget de mémoire vidéo GPU n'existe que sur LCC2.

7.1 Sort Factor (pipeline LCC uniquement)

Pour la plage et la valeur par défaut, voir Paramètres de performance : Sort Factor

Il s'applique à la table globale SortFrequencyForLevel et contrôle la fréquence à laquelle les nœuds de chaque Level sont retriés. Plus la valeur est grande, moins il y a de tris et meilleures sont les performances, mais l'ordre de la translucidité se met à jour plus lentement après un changement de caméra ou de nœuds, ce qui peut provoquer de brèves erreurs d'interpénétration.

Réglage de Sort Factor pour ajuster la fréquence de tri du LCCActor

Configuration de la Sort Frequency de chaque niveau de LOD

7.2 Nœuds de préchargement supplémentaires (pipeline LCC uniquement)

Pour la plage et la valeur par défaut, voir Paramètres de performance : Add Extra Preload Nodes

Son rôle est d'atténuer les trous en bordure d'écran pendant les rotations rapides, au prix d'un travail de nœuds accru.

Cette option a deux niveaux d'état et se comprend facilement de travers :

• Tant que la case de gauche n'est pas cochée, elle revient à la valeur par défaut interne, donc le résultat effectif reste activé ;
• Pour la désactiver réellement, cochez d'abord la case, puis réglez la valeur sur désactivé.

Ne la désactivez que si les statistiques montrent que le nombre de nœuds et le préchargement sont réellement une charge nette et que le projet accepte des trous en bordure pendant les rotations rapides. Rétablissez-la dès que des trous apparaissent : ne masquez pas des données non prêtes en ajoutant des threads.

Configuration des nœuds de préchargement supplémentaires pour atténuer les trous lors des rotations rapides

7.3 LCC2 GPU Memory Budget (pipeline LCC2 uniquement)

Pour la plage et la valeur par défaut, voir Paramètres de performance : LCC2 GPU Memory Budget (MB)

Réglage du budget de mémoire vidéo LCC2 GPU Memory Budget

Il ne compte que les données de position, de couleur et d'harmoniques sphériques d'un seul modèle LCC2, et n'agit que sur les .lcc2, où les nœuds peuvent être échangés. Les formats à fichier unique (.sog / .spz / .ply) doivent rester entièrement résidents, et leur capacité est déterminée par la limite de Buffer de la plateforme et la mémoire vidéo réellement disponible ; modifier cette valeur n'a aucun effet sur eux.

Augmenter le budget ne peut aider que dans ces cas :

• Le GPU a encore assez de mémoire vidéo libre ;
• Les saccades se produisent surtout à l'entrée d'une nouvelle zone ou lors du travail avec plusieurs viewports.

Il ne réduit pas le nombre de splats, le volume de tri ni la couverture de pixels. Sans problème d'éviction ni de fragmentation, un budget plus élevé n'augmente que la mémoire vidéo résidente, sans améliorer la fréquence d'images.

Étapes de réglage :

1. Relevez d'abord le pic de mémoire vidéo de la machine entière, pas seulement le budget LCC.
2. Partez de la valeur par défaut et augmentez par paliers de 1024 Mo.
3. Redémarrez le moteur après chaque modification.
4. Retestez les angles de vue les plus exigeants, toutes les vues SceneCapture / nDisplay et les exécutions longues.
5. Laissez de la mémoire vidéo aux textures de scène d'UE, aux Render Targets, à Nanite, Lumen, VSM, aux buffers de tri et au système d'exploitation.

Ne réglez pas directement sur 8192 Mo sans surveillance complète de la mémoire vidéo.

Le journal affiche également une décomposition de l'occupation de la mémoire vidéo, utile pour vérifier si le budget est raisonnable :

GPU footprint: %u slots (%s), %.2f MB total - gaussian %.2f, SH %.2f, sort %.2f (1 view), other %.2f MB

L'entrée sort est le buffer de tri. Le journal est calculé pour 1 view : multipliez par le nombre de vues en cas de viewports multiples.

Étape huit : chargement, threads, mémoire

8.1 Ne commencez pas par ajouter des threads (pipeline LCC uniquement)

Pour la plage et la valeur par défaut, voir Paramètres de performance : réglages des pools de threads

Ajouter des threads peut augmenter la concurrence CPU, et peut tout autant augmenter la contention entre threads, les changements de contexte, la pression disque ponctuelle et les pics d'upload. Les threads Exporter n'ont pas de rapport direct avec le rendu à l'exécution : les ajuster n'améliore pas la fréquence d'images.

Critère : n'ajoutez 2 à 4 threads à la fois et ne retestez que si les statistiques montrent que la file correspondante s'accumule pendant que le CPU a encore des cœurs disponibles. Quand le CPU est déjà saturé, réduisez la charge de travail au lieu de continuer à ajouter des threads.

Si l'entrée Create Thread affiche un coût en temps de manière continue, c'est que le pool de threads s'agrandit à répétition : ajustez alors le nombre de threads précréés plutôt que la limite supérieure.

8.2 Splat Number For Discard Per Node (pipeline LCC uniquement)

Pour la plage et la valeur par défaut, voir Paramètres de performance : Splat Number For Discard Per Node

Réglage du seuil d'abandon des splats épars de chaque nœud

L'intention est d'ignorer les nœuds extrêmement épars : certains jeux de données contiennent de nombreux nœuds ne portant qu'un ou deux splats, et gérer ces nœuds coûte plus qu'ils n'apportent à l'image.

L'augmenter peut réduire le coût de gestion des nœuds de faible densité, et peut tout autant supprimer des détails isolés. Vérifiez sur les lignes fines, les branches d'arbres, les garde-corps et les petits objets lointains, sans vous limiter à la fréquence d'images globale. Rechargez les données après modification, sinon le résultat affiché reste l'ancien.

8.3 Seuils de libération de la mémoire et de la mémoire vidéo

Configuration des seuils d'occupation et de libération de la mémoire CPU et GPU

Pour la plage et la valeur par défaut des quatre seuils, voir Paramètres de performance : catégorie Usage

C'est une stratégie de libération sous pression mémoire, pas un bouton habituel de fréquence d'images :

• Un seuil trop bas ou une proportion de libération trop grande → peut provoquer une oscillation « libérer, recharger, libérer à nouveau » ;
• Un seuil trop haut → peut retarder la libération et augmenter la pression sur la mémoire système et la mémoire vidéo ;
• Ne l'ajustez qu'après des tests longs confirmant une pression mémoire ou des évictions répétées.

Jugez-le d'après la relation entre CPU Occupy Percentage / GPU Occupy Percentage et les seuils correspondants, et d'après la croissance continue ou non de Released CPU Node Num / Released GPU Node Num. Sur la capture, une occupation de la mémoire vidéo de 86 % dépasse déjà le seuil de 80 % et le nombre de libérations côté mémoire vidéo atteint 1943, ce qui est un signal typique de pression sur la mémoire vidéo.

Étape neuf : viewports multiples, collision, eau

9.1 Plusieurs caméras et SceneCapture

Chaque vue supplémentaire participant réellement au rendu peut ajouter du travail de traversal, de rendu ou de tri ; LCC2 ajoute en plus un buffer de tri par vue.

Vérifiez point par point :

1. S'il existe un SceneCapture inutilisé mais toujours mis à jour à chaque image ;
2. Si la résolution du Render Target est trop élevée ;
3. Si la fréquence de mise à jour doit vraiment être à chaque image ;
4. Si ShowOnlyActors ne contient que le contenu nécessaire ;
5. Si la minimap peut passer en PointCloud ou à une résolution plus basse ;
6. Si nDisplay, l'écran partagé ou MRQ ont créé des vues supplémentaires en même temps.

Vérifiez avec Camera Num(Render) de stat xgrids que le nombre de vues participant réellement au rendu correspond aux attentes ; Camera Num est le nombre de caméras participant aux mises à jour, et les deux peuvent différer. Une valeur supérieure aux attentes signifie que des vues rendent sans que vous le sachiez.

SceneCaptureComponent Support peut être désactivé quand SceneCapture n'est pas utilisé du tout, voir Paramètres de performance.

Configuration de SceneCaptureComponent Support pour les viewports multiples

9.2 Mode de traversal

Pour la plage et la valeur par défaut, voir Paramètres de performance : Default Traversal Type

Choix du mode de traversal par défaut Frustum ou Circle

Circle convient aux écrans courbes, à nDisplay et aux panoramas 360 degrés qui ont besoin des données dans toutes les directions environnantes ; Frustum est la référence par défaut pour un viewport unique.

Ne passez pas un projet ordinaire à caméra unique en Circle juste pour « éviter les blocs manquants dans toutes les directions » : cela intègre au traversal tout le disque autour de la caméra, alors que le mode frustum ne traite que la partie visible. Si le flux de travail exige Circle, resserrez en conséquence Max Distance, la limite de points et la résolution en viewports multiples.

La pipeline LCC2 n'a pas besoin d'ajuster cette option, restez sur Frustum.

9.3 Collision et navigation

Pour la description fonctionnelle, voir Collision et Prise en charge du système de navigation ; cette section ne traite que des compromis de performance.

Avec la collision désactivée, il n'y a pas de distance de collision à régler. Une fois activée, la lecture de la collision, le bake physique asynchrone et les mises à jour du NavMesh peuvent augmenter le coût CPU, la mémoire et les saccades. Notez que ce genre de coût n'apparaît pas nécessairement dans les FPS et demande d'examiner séparément les statistiques liées à la collision.

Pour la plage et la valeur par défaut de la distance de collision, voir Paramètres de performance : Max Load Collision Distance(m)

1. Dans les projets purement de présentation, désactivez complètement la collision.
2. Quand la collision est nécessaire, cochez la case à gauche du paramètre et réglez Max Load Collision Distance(m) sur l'étendue d'interaction réelle.

Réglage de la distance de chargement de la collision Max Load Collision Distance

Changements de l'étendue de collision dynamique après ajustement de la distance de chargement

3. Ne réglez pas mécaniquement la distance de rendu et la distance de collision sur la même valeur. Visible au loin ne signifie pas qu'une collision physique y est nécessaire.
4. Réduire la distance de collision limite directement l'étendue disponible pour l'interaction du joueur et l'IA : faites un test de régression fonctionnelle après modification, sans vous limiter à la fréquence d'images.

La stratégie est inverse avec la navigation : la distance de collision doit couvrir autant que possible toute la zone accessible au joueur, pour que la collision de ces zones se charge en une seule fois. La collision est chargée dynamiquement par blocs, et l'arrivée d'un nouveau bloc de collision à l'exécution déclenche une reconstruction des données de navigation, ce qui provoque des saccades marquées.

Points d'accompagnement :

• Faites couvrir par NavMeshBoundsVolume l'étendue d'activité du joueur, et confirmez que la collision y est entièrement chargée
• Privilégiez le bake Static et évitez le bake Dynamic, ce dernier reconstruisant en continu à chaque changement de collision

9.4 Eau à couche unique (pipeline LCC2 uniquement)

Pour la description fonctionnelle et la configuration complète, voir Prise en charge de l'eau à couche unique ; cette section ne traite que des compromis de performance.

SingleLayerWater Support est une option globale des paramètres du projet, mais son implémentation repose sur la profondeur médiane de LCC2 : elle ne prend donc pas effet sur les Actors de la pipeline LCC.

• Laissez-la désactivée quand l'eau à couche unique n'est pas utilisée ;
• Après activation, un redémarrage est obligatoire ;
• Le coût est que les pixels d'eau perdent la qualité d'ombre des Virtual Shadow Maps, ce qui est un compromis fonctionnel et non purement de performance ;
• Ne l'activez que quand le 3DGS est occulté à tort par un matériau d'eau à couche unique.