Architecture Nanite d'Unreal Engine 5 : Analyse technique approfondie, stratégies d'optimisation et guide de développement pour PlayStation 5

Fondamentaux de la géométrie micropolygonale virtualisée et changement de paradigme

L'une des plus grandes contraintes de l'industrie du rendu en temps réel et de l'informatique graphique depuis des décennies, pour une utilisation efficace des ressources matérielles, réside dans les goulots d'étranglement inévitables que créent les budgets de polygones et le nombre d'appels de dessin (draw calls) dans la communication entre le processeur (CPU) et le processeur graphique (GPU). 1 Dans les flux de production de jeux vidéo traditionnels, il était obligatoire pour les artistes 3D et les directeurs techniques d'effectuer manuellement une optimisation de la topologie, de créer des chaînes de niveaux de détail (Level of Detail ou LOD) et de cuire (baking) des détails haute résolution dans des cartes normales (Normal Maps) afin de pouvoir importer des modèles hautement détaillés (par exemple, des sculptures ZBrush de qualité cinématographique, des balayages laser ou des données de photogrammétrie) dans les moteurs de jeux. 1 Ce processus créait à la fois une charge de travail ardue qui rallongeait le calendrier de production et enfermait le niveau de détail à l'écran dans une limite artificielle en raison de contraintes de mémoire. 1 Devenue un standard de l'industrie avec Unreal Engine 5 (UE5), la technologie Nanite est un système de géométrie micropolygonale virtualisée (virtualized micropolygon geometry) qui élimine fondamentalement ces obstacles traditionnels. 1 Nanite fait des budgets de polygones une contrainte technique du passé, permettant de charger directement des fichiers sources composés de milliards de polygones de qualité cinématographique dans la scène en temps réel, sans nécessiter aucune opération de LOD manuelle. 1 Le système est conçu pour traiter uniquement les détails visibles à ce moment-là par la caméra du joueur à l'écran ; aucun triangle ou fragment de géométrie plus petit que la taille d'un pixel n'est rendu inutilement. 3 Cette technologie offre un système de LOD automatique continu, fluide et ininterrompu, remplaçant entièrement le pipeline de rendu traditionnel par une architecture de flux de données (streaming) axée sur le GPU. 1 Les innovations fondamentales de Nanite se regroupent sous quatre grands titres 1 :

1. Géométrie virtualisée : Toute la scène est traitée comme un seul maillage statique (mesh) massif, et seules les parties visibles à l'écran sont intégrées au traitement.

2. Niveau de détail automatique (LOD) : Au lieu de changements de LOD progressifs et discrets (LOD popping), un changement de détail continu et fluide est assuré en fonction de la distance et de la résolution de l'écran.

3. Pipeline axé sur le GPU : Les appels de dessin (draw calls) et les opérations d'élimination (culling) sont retirés du CPU pour être confiés à la puissance de traitement parallèle du GPU.

4. Flux efficace (Efficient Streaming) : Un flux de mémoire direct via SSD garantit que seules les données géométriques nécessaires sont chargées instantanément en mémoire.

Ce rapport de recherche examine dans un cadre analytique complet les principes de fonctionnement approfondis du système Nanite, les étapes nécessaires à son integration de projet, les exigences d'optimisation, la manière de surmonter les goulots d'étranglement, et les dynamiques de développement de jeux ciblant particulièrement la plateforme PlayStation 5 (PS5), dotée d'une compression unique au niveau matériel et d'un flux de données à haute vitesse (I/O).

Architecture technique et structures de données de Nanite

La philosophie sous-jacente au cœur du système Nanite n'est pas de traiter les données géométriques comme des maillages statiques (static meshes) massifs que l'on essaie de faire tenir dans les limites de la mémoire, mais plutôt de les traiter comme des ensembles de données fragmentés gérés à la demande et diffusés en continu (streaming) de manière dynamique, tout comme pour les textures virtuelles (virtual texturing). 3 Alors que les moteurs traditionnels tentent de charger et de traiter l'intégralité d'un objet en mémoire même si seule une petite partie de celui-ci se trouve dans le champ de vision de la caméra (frustum), Nanite évalue cette visibilité avec une précision millimétrique au pixel près. 3

Structure de grappes hiérarchiques (Hierarchical Cluster Structure)

Lors de la phase d'importation (import), les algorithmes Nanite analysent les modèles 3D et les divisent en arbres de grappes (clusters) hiérarchiques. 1 Chaque maillage statique traité est divisé en petits paquets de données (clusters) composés exactement de 128 triangles, de manière à offrir les meilleures performances au niveau matériel. 1 Cette taille fixe de 128 triangles correspond exactement aux tailles de front d'onde (wavefront) ou de warp des GPU modernes, ce qui en fait une unité optimale spécialement choisie pour obtenir un rendement de traitement maximal à partir des unités de traitement parallèle et des limites de mémoire cache (cache limits). 1 Ces grappes forment entre elles une structure de données arborescente de type Graphe Orienté Acyclique (Directed Acyclic Graph - DAG) contenant des informations de boîte englobante (bounding box), des métriques d'erreur géométrique pour la sélection du LOD dans l'espace écran (screen space), ainsi que des relations parent-enfant. 1 À mesure que la caméra s'approche ou s'éloigne de l'objet concerné, le système parcourt cette structure arborescente en temps réel pour décider quelle grappe convient le mieux à la densité de pixels à l'écran pour chaque région de l'écran. 1 Contrairement aux approches traditionnelles, l'ensemble de l'objet ne change pas soudainement. Au lieu d'un changement de LOD discret, différentes régions de la surface de l'objet peuvent être traitées simultanément à différents niveaux de détail de grappes, et se rejoignent en douceur sur les bords sans créer de déchirure visuelle ou de fissure (crack) dans la rastérisation matérielle. 3

Tampon de visibilité (Visibility Buffer) et ombrage découpé

La structure la plus critique qui permet à Nanite de surmonter les goulots d'étranglement du CPU et de révolutionner les architectures de rendu modernes est le transfert d'une grande partie du pipeline de rendu directement vers le GPU, remplaçant la logique d'ombrage (shading) Forward ou Deferred traditionnelle par le « Visibility Buffer » (Tampon de visibilité). 1 Le concept de tampon de visibilité dans la boucle de rendu de Nanite fonctionne comme suit : dans les structures G-Buffer traditionnelles, lors du calcul des pixels, des données de taille massive telles que la couleur, la normale et la rugosité (roughness) sont écrites en mémoire pour chaque pixel. Nanite enregistre à la place un numéro d'identification (Primitive ID et Cluster ID) d'une taille de seulement 32 bits ou 64 bits pour chaque pixel à l'écran. 1 Cette mémoire tampon ne contient pas de données de couleur ou d'ombrage ; il s'agit uniquement d'une carte de référence indiquant quel triangle et quelle grappe sont visibles à ce pixel spécifique sur l'écran. 1 Une fois le tampon de visibilité entièrement rempli, les données de matériau ne sont appelées qu'une seule fois pour chaque pixel de l'espace écran et l'opération d'ombrage est effectuée. Grâce à cette architecture « découpée » (decoupled), aucun calcul de matériau n'est effectué inutilement pour des millions de triangles qui restent derrière la caméra, sont cachés derrière un autre objet ou n'apportent aucune contribution à l'image finale. Cette situation élimine complètement le problème d'"Overdraw" (sur-dessin), l'un des plus grands ennemis du GPU, sur la base du calcul des matériaux. 9

Mécanismes d'élimination (Culling) axés sur le GPU

Dans l'architecture Nanite, les opérations d'élimination (culling) ne sont pas effectuées par objet (actor) sur le CPU comme dans les moteurs traditionnels. Les préparations de draw calls traditionnelles du côté du CPU sont entièrement contournées, et le processus d'élimination est directement confié aux compute shaders au sein du GPU. 10 Lors de la phase d'occlusion et d'élimination (Occlusion Culling), Nanite utilise une structure appelée HZB (Hierarchical Z-Buffer), où divers niveaux de profondeur (mipmaps) sont stockés de manière logarithmique dans l'espace écran. 9 Le HZB compare la boîte englobante (bounding box) de chaque grappe de 128 triangles avec les données de profondeur dans l'espace écran. 9 Si une grappe se trouve derrière un autre objet de la scène, elle est immédiatement rejetée du processus de rendu. Cette élimination est si précise que, comme elle est effectuée par grappe et non par objet, les grappes de feuilles dépassant du sommet d'une montagne continuent d'être traitées tandis que les grappes appartenant aux parties des arbres d'une immense forêt situées derrière la montagne sont éliminées. 8

Chemins de rastérisation : Dynamique de traitement logiciel et matériel

Pour convertir les triangles en pixels d'écran (rastérisation), Nanite n'utilise pas une unité de traitement uniforme, mais emploie deux chemins de rastérisation (raster paths) distincts déterminés dynamiquement en fonction de la taille du triangle à l'écran et des propriétés du matériau. 9 L'optimisation des performances repose sur l'établissement d'un équilibre parfait entre ces deux chemins.

Rastérisation logicielle (Software Raster Path)

La rastérisation logicielle est le chemin de traitement central de Nanite le plus efficace, le plus rapide et le plus innovant. 9 Ce chemin entre en jeu lorsque les triangles sont plus petits qu'un pixel à l'écran (sub-pixel) ou ont exactement la taille d'un pixel. 9 Dans ce scénario, Nanite contourne complètement les unités de dessin de triangles matérielles du GPU et exécute le processus via des « Compute shaders » (Shaders de calcul). L'utilisation d'opérations atomiques 64 bits (atomic interlocks) garantit l'écriture des pixels dans le tampon de visibilité à une vitesse extraordinaire. Lorsque le mode de visualisation Raster Bins est activé à partir de la console de développement avec la commande r.Nanite.Visualize.Advanced 1 ou r.nanite.showmeshdrawevents 1, les grappes passant par la rastérisation logicielle sont affichées en bleu. 9 Dans une scène bien optimisée, la grande majorité de la géométrie doit viser à être de couleur bleue. 9

Rastérisation matérielle (Hardware Raster Path)

La rastérisation matérielle est la méthode de dessin GPU classique qui entre en jeu lorsque les triangles sont plus grand qu'un pixel à l'écran ou lorsque des attributs de matériau spéciaux que la rastérisation logicielle basée sur le calcul de Nanite ne peut pas traiter sont utilisés. 9 Ce chemin est affiché en rouge dans les modes de visualisation. 9 Il est normal que le système passe à la rastérisation matérielle, en particulier lorsque la caméra s'approche d'un mur massif, car les triangles deviennent plus grands que les pixels. 9 Cependant, si des objets éloignés de la caméra ou des micropoligonaux apparaissent toujours en rouge, cela indique qu'un « Hardware Fallback » (Repli matériel) se produit, ce qui constitue un problème d'optimisation majeur. 9 La cause principale des chutes indésirables vers la rastérisation matérielle est l'utilisation de matériaux masqués (masked), transparents ou présentant des décalages de déformation complexes. 9

Raster Bins (Boîtes de rastérisation) et gestion des matériaux

Le cœur des performances de Nanite n'est pas tant la géométrie elle-même que la manière dont les matériaux appliqués sur la géométrie sont répartis dans des boîtes virtuelles appelées « Raster Bins ». 9 Nanite regroupe tous les matériaux standard, opaques et ne contenant aucun décalage de profondeur de pixel (Pixel Depth Offset - PDO) ou décalage de position mondiale (World Position Offset - WPO) dans une seule et même Raster Bin (Boîte de rastérisation) massive, et le système traite cette boîte à une vitesse fulgurante en une seule passe (pass). 9 Cependant, lorsque des objets utilisent des matériaux déplacés (displacement), masqués (masked/alpha test) ou contenant un WPO intensif utilisé pour un effet de vent, ces objets sont retirés du chemin de passage rapide de Nanite, ce qui entraîne la création d'une Raster Bin différente et indépendante pour chaque type de matériau. 9

Classe de performanceType de matériau et propriétéEffet de Nanite et état de traitementRecommandation stratégique pour le développeurMeilleur (Best)Opaque, sans WPO, PDO ou décalage de déplacement (Displacement).Mélangé dans une seule Raster Bin. La rastérisation logicielle fonctionne activement, le coût des appels de dessin (draw call) est proche de zéro.9Plus de 90 % des conceptions d'environnements, des bâtiments et des surfaces dures (hard surface) du projet doivent absolument être de ce type.9Bon (Good)Opaque, mais avec un WPO (World Position Offset) minimal.En raison de l'utilisation du WPO, les grappes statiques commencent à être calculées séparément sur le GPU. L'élimination (culling) devient difficile car les boîtes englobantes changent en raison du mouvement.La distance de mouvement du WPO doit impérativement être bridée (clamp) pour éviter la distorsion de la boîte englobante et un mauvais culling.3 La déformation doit être cuite (baked) si elle est statique.9Moyen (Okay)Masqué (Masked / bords transparents, Alpha Cutout).Tombe obligatoirement dans la rastérisation matérielle (Hardware Raster Path). Provoque un « Overdraw » (sur-dessin) intense en raison de l'évaluation continue des pixels vides.Utilisé pour la modélisation classique de feuillus ou de clôtures, mais doit être utilisé avec beaucoup de parcimonie car il mine les performances.8Pire (Worst)Matériaux à déformation complexe (WPO intense + PDO).Chaque variation crée une Raster Bin distincte. Augmente les changements d'état (state changes) et pousse instantanément les temps de trame au-delà des limites du budget.Doit absolument être désactivé immédiatement sur les objets lointains (LOD fallback) ou orienté vers des alternatives plus modernes telles que le Nanite Skinning introduit avec UE 5.7.9

La présence d'un trop grand nombre de Raster Bins se traduit par une augmentation des changements d'état (state changes) sur le GPU et une augmentation des variations d'appels de dessin (draw calls), ce qui ralentit considérablement le GPU.9 Dans un projet ciblant 60 FPS (16,66 ms par trame), il est impératif de maintenir le traitement VisBuffer en dessous de 4 ms et le traitement BasePass en dessous de 3 ms ; sinon, il ne restera plus de temps pour les autres systèmes tels que le post-traitement, Lumen et l'intelligence artificielle.7

Intégration Nanite : Comment l'utiliser dans les projets ?

L'intégration de Nanite est conçue pour s'insérer dans les flux de travail de développement de jeux Unreal Engine existants avec un minimum de frictions. Éliminant les processus obsolètes de création manuelle de LOD ou de cuisson de normal map, ce système optimise automatiquement les performances lorsqu'il est configuré correctement.1

Types de géométrie et composants pris en charge

Pour qu'une géométrie puisse bénéficier des capacités de Nanite, cette fonctionnalité doit être activée lors de la phase d'importation ou ultérieurement via l'Éditeur de maillage statique (Static Mesh Editor).3 Dans les versions actuelles d'Unreal Engine 5, les types de composants pris en charge par Nanite ont été considérablement élargis :

● Maillages statiques (Static Meshes) : n'importe quel Static Mesh inclus dans le projet peut être converti en cochant l'option "Enable Nanite Support" dans l'éditeur. Dans les scènes gigantesques comportant des milliers d'objets, l'ensemble de la bibliothèque peut être converti au format Nanite en une seule fois grâce à la sélection groupée (batch-enable) via le Content Browser.3 Ces maillages constituent le public cible principal du système Nanite.

● Maillages squelettiques (Skeletal Meshes) : alors que les premières versions d'UE5 ne prenaient en charge que les objets statiques, les versions UE 5.3 et ultérieures prennent en charge l'API Skeletal Mesh, ce qui permet d'utiliser des personnages, des créatures et des véhicules soumis à des déformations dynamiques (animés) avec Nanite.3 La plus grande nouveauté pour les maillages squelettiques est la production d'un seul appel de dessin (one draw call) pour l'ensemble du maillage. Les Skeletal Mesh Nanite fonctionnent en utilisant des LOD d'animation au lieu des LOD de géométrie classiques.3

● Maillages de spline (Spline Meshes) et Paysage (Landscape) : Nanite prend en charge de manière native les Spline Meshes qui se déforment le long de courbes (routes, canalisations, murs) et la topologie des vastes mondes ouverts Landscape (via Nanite Tessellation).3 Les détails de déplacement mineurs sur les sols peuvent être obtenus directement via les matériaux, sans créer de densité polygonale et sans nuire aux performances.3

● Maillages statiques instanciés (Instanced Static Meshes - ISM / HISM) : les objets possédant des millions de copies (par exemple, des pierres dans une forêt immense ou des briques de bâtiments) sont rendus avec une seule empreinte mémoire grâce au tampon de visibilité de Nanite. Il ne faut toutefois pas oublier que le nombre maximal d'instances Nanite pouvant se trouver dans une scène est limité matériellement à 16 millions.3

Génération et rôle du maillage de secours (Fallback Mesh)

Lorsque la case "Build Nanite" est cochée lors de la génération des données Nanite, le moteur produit automatiquement, en plus du maillage haute définition, une géométrie simplifiée dotée d'un nombre de polygones traditionnel, appelée "Fallback Mesh" (Maillage de secours).13

La raison d'être de ce maillage de secours est d'une importance vitale : le système de rastérisation axé sur le GPU de Nanite ne peut pas être utilisé directement pour les calculs de collision physique complexes, les cartes d'éclairage précalculées avec Lightmass (baked lighting) et, surtout, les réflexions par traçage de rayons matériel (hardware ray tracing / Lumen HWRT).13 Les systèmes logiques du côté CPU du moteur de jeu ont besoin de ces données de triangles traditionnelles. Le niveau de détail du maillage de secours peut être contrôlé en modifiant le paramètre "Fallback Relative Error" (Erreur relative de secours).3 Plus le taux d'erreur est réduit, plus le nombre de polygones du maillage de secours augmente, ce qui garantit un calcul plus précis des réflexions par traçage de rayons matériel (Lumen Hit Lighting), mais cela augmente également l'utilisation de la mémoire (VRAM) dans les mêmes proportions.14

Nanite Foliage : Systèmes de voxels et d'assemblage (Assembly) introduits avec UE 5.6/5.7

Dans les moteurs de jeu, les zones forestières et la végétation dense ont longtemps été considérées comme le point faible historique de Nanite en raison des nombreuses surfaces de feuilles transparentes (masked) qui se superposent.15 La modélisation traditionnelle de l'herbe ou du feuillage (alpha cards) entraînait le problème du "Overdraw", où les pixels sont évalués à plusieurs reprises les uns sur les autres et qui pèse sur le rastériseur matériel (HW Raster).8

Les versions d'Unreal Engine 5.6 et en particulier 5.7 ont résolu ce problème fondamentalement et par un changement architectural grâce au système "Nanite Foliage" 12 :

1. Nanite Voxels (Voxels) : les triangles de feuillage complexes et générateurs d'overdraw des arbres ou de la végétation s'éloignant de la caméra sont convertis en voxels au loin en configurant l'option "Voxelize" dans le menu "Shape Preservation".17 Ressemblant à des blocs de Minecraft, ces voxels sont traités comme des pixels volumétriques contrairement aux triangles, éliminant totalement le besoin de transparence (alpha) et empêchant ainsi le problème d'overdraw au niveau matériel.15 Des centaines de milliers d'arbres lointains sont traités avec un coût extrêmement faible sous forme de voxels volumétriques de la taille d'un pixel d'écran, tout en effectuant une transition fluide vers des micropolygones entièrement détaillés à mesure qu'ils se rapprochent.15

2. Nanite Assemblies (Assemblages) : lorsque des arbres gigantesques sont modélisés en haute résolution, ils atteignent des tailles incroyables sur le disque et en mémoire. Grâce à la fonctionnalité Nanite Assemblies, chaque branche, feuille et tronc d'un arbre n'est pas lu comme un maillage statique géant distinct, mais comme un tout hiérarchique (assembly) via l'importateur USD (Universal Scene Description).12 Grâce aux schémas NaniteAssemblyRootAPI préparés dans des programmes tels que Houdini Solaris, des milliers de feuilles sont en réalité appelées par la méthode d'instanciation (instancing) du même petit maillage de feuille.19 Cette structure réduit incroyablement l'empreinte mémoire.

3. Nanite Skinning : les animations de vent traditionnelles basées sur le WPO (World Position Offset) modifiaient la boîte englobante de chaque groupe à chaque image, nécessitant un recalcul continu (culling invalidation) sur le CPU/GPU.15 Avec le Nanite Skinning introduit dans UE 5.7, les arbres sont importés en tant que maillages squelettiques (skeletal mesh) ; les effets de vent physiques et procéduraux sont calculés via les os (bones) en utilisant le plugin "Dynamic Wind".12 De cette façon, Nanite offre des interactions de vent beaucoup plus organiques et cohérentes sans sacrifier les performances des bacs de rastérisation (Raster Bins). La nouvelle bibliothèque Quixel Megaplants et l'éditeur de végétation procédurale (Procedural Vegetation Editor - PVE) intègrent pleinement ces technologies pour permettre d'atteindre facilement des objectifs de 60 FPS.15

Processus d'optimisation : À quoi faut-il faire attention ?

Bien que Nanite soit conçu pour améliorer les performances, la promesse de "polygones illimités" n'a rien d'une baguette magique. C'est un système complexe qui, en cas de mauvaise utilisation et de non-respect des limites matérielles, peut compromettre gravement les temps de trame (frame).11

Transparence (Translucency), masquage et problème d'overdraw

Dans l'optimisation de jeux traditionnelle (UE4 et versions antérieures), il était courant de simuler un objet détaillé sur des surfaces à faible polygone en appliquant des masques transparents (alpha texture / masked material).8 Cependant, dans l'architecture Nanite, cette approche est totalement erronée et conduit à un désastre.8

Lors du calcul du tampon de visibilité, Nanite a besoin de passes matérielles supplémentaires pour ignorer les pixels transparents (vides). Lorsque des matériaux masqués sont disposés les uns derrière les autres (par exemple un grillage ou des feuilles d'arbre), le système est contraint de lire et de traiter la profondeur et la transparence du même pixel des dizaines de fois, ce que l'on appelle l'"Overdraw".10

Règle critique : dans le système Nanite, "la géométrie est très bon marché, mais la transparence est très coûteuse". Lors de la création d'objets ajourés tels que du feuillage, des clôtures ou des filets, au lieu d'utiliser une texture masquée (masked material), la forme doit être entièrement modélisée (fully modeled) si nécessaire avec des centaines de milliers de polygones supplémentaires, et le matériau doit impérativement être configuré sur "Opaque".8 Une feuille d'arbre entièrement modélisée sera rendue beaucoup plus rapidement qu'une surface plane masquée (plane).8

Intégration des cartes d'ombres virtuelles (Virtual Shadow Maps - VSM)

Les cartes d'ombres traditionnelles (Cascaded Shadow Maps - CSM) ne peuvent pas s'adapter au niveau de détail gigantesque au niveau des micropolygones offert par les objets Nanite. Conçues spécialement pour être utilisées avec Nanite, les cartes d'ombres virtuelles (Virtual Shadow Maps - VSM) offrent des ombres d'une netteté de rasoir en faisant correspondre dynamiquement la résolution des ombres avec les pixels de l'écran.23

De par leur nature, les VSM requièrent une forte exigence en mémoire VRAM. Si un objet qui projette des ombres est en mouvement constant (par exemple, des feuilles oscillant avec le WPO), le cache d'ombres VSM (shadow cache) est invalidé à chaque image et la carte d'ombres est calculée à partir de zéro, ce qui provoque une chute importante des FPS.22 Par conséquent, alors que les scènes statiques ou les bâtiments fonctionnent parfaitement avec le duo Nanite et VSM, des restrictions WPO doivent être imposées dans les zones forestières où le mouvement est intense, ou le passage à des cartes d'ombres classiques (Shadow Maps) doit être envisagé en fonction des tests de performance.25

Profilage (Profiling) et commandes de lecture des performances

Pour trouver la cause racine des problèmes d'optimisation et déterminer si le goulot d'étranglement provient du processeur (CPU) ou de la carte graphique (GPU), il est indispensable de lire régulièrement les commandes de profil intégrées proposées dans UE5 et ce dès le début du projet (principe de l'optimisation précoce / optimize early).26

Les commandes de profil et les outils de visualisation que les développeurs doivent utiliser régulièrement sont les suivants 28 :

Commande de profil / ModeDescription et objectif d'utilisationAction du développeurstat unitDétection de base des goulots d'étranglement. Affiche le temps total à l'écran avec des ventilations en millisecondes (ms) pour "Frame" (Temps global), "Game" (Boucle de jeu CPU), "Draw" (Préparation du rendu CPU) ou "GPU".28Si le temps GPU dépasse 16,66 ms, il faut s'orienter vers des restrictions graphiques ; si le temps Game est dépassé, vers l'optimisation de l'IA ou des tics Blueprint.

Commande / OutilFonction et descriptionAction d'optimisationstat gpu ou stat scenerenderingListe les charges de rendu spécifiques au sein du GPU. Détaillent le temps pris par Nanite BasePass, Lumen, les ombres (Shadow Depths) et les charges Post Process.Si Nanite VisBuffer dépasse 4 ms ou BasePass 3 ms, le contrôle des Raster Bins ou de l'Overdraw doit être effectué.r.nanite.showmeshdrawevents 1Examine de manière hiérarchique quel matériau et quel objet Nanite spécifique consomment du temps dans le profileur GPU (Ctrl+Shift+,).Utilisé pour détecter et isoler les matériaux WPO coûteux ou les objets transparents.NaniteStatsDessine une interface directement dans le coin de l'écran grâce à la technologie "ShaderPrint". Filtre en direct si les ombres virtuelles ou le champ de vision principal (Primary View) créent une charge de dessin sur Nanite.En entrant des paramètres (primary, VirtualShadowMaps) dans la console, la charge des passes actives est déterminée.View Mode > Nanite Visualization > OverdrawColore les zones denses où les pixels se superposent à l'écran selon un spectre allant du bleu (bon) à l'orange et au rouge (mauvais).Les zones où les matériaux transparents sont denses sont identifiées et une révision vers une modélisation complète (opaque) est entreprise.

Relation entre l'architecture I/O de la PlayStation 5 (PS5) et le streaming Nanite

Lors du développement d'un jeu pour la PlayStation 5, le seul facteur qui propulse le potentiel de Nanite au-delà des limites théoriques pour atteindre le sommet des performances du monde réel est le stockage SSD révolutionnaire de la console et son architecture de compression/décompression matérielle. Les grappes de 128 triangles de Nanite sont conçues selon une logique de chargement à la demande (on-demand streaming pages), et la hiérarchie I/O (entrée/sortie) de la PS5 est en parfaite harmonie avec cette conception.

Compression matérielle Kraken et intégration d'Oodle Texture

Sur les systèmes PC traditionnels et les consoles de génération précédente (PS4, Xbox One), les données compressées lues depuis le disque (à l'aide d'algorithmes à usage général tels que ZLIB) doivent d'abord être chargées dans la RAM, puis décompressées par le processeur central (CPU). Lorsque les tailles massives des grappes Nanite, composées de milliards de polygones, exigent un flux de nouvelles données de plusieurs gigaoctets par seconde (Go/s) à chaque mouvement de la caméra, cette méthode de décompression logicielle (software decompression) entraîne un blocage du processeur sur PC et sur les anciennes consoles, l'empêchant de traiter les mécaniques de jeu (intelligence artificielle, physique, etc.).

Lors de la conception du matériel de la PS5, Sony ne s'est pas en tenu aux normes et a intégré une puce décompresseur matériel (hardware decompressor block) personnalisée au niveau du silicium dans le complexe I/O afin de pouvoir décoder l'algorithme de compression Oodle Kraken développé par RAD Game Tools. Kraken peut réduire les données de manière sans perte (lossless) de 29 % supplémentaires par rapport au format ZLIB de la génération précédente, tout en étant 3 à 4 fois plus efficace en termes de vitesse de décompression.

La puce Kraken de la PS5, lorsqu'elle est utilisée avec le format sans perte "Oodle Texture" (ainsi que des optimisations de compression de texture telles que BC7Prep), amplifie la vitesse de lecture brute de 5.5 Go/s du SSD par un effet multiplicateur, offrant un transfert de données à des vitesses de bande passante incroyables atteignant une moyenne de 8 à 9 Go par seconde, et jusqu'à 17 à 22 Go par seconde en pointes (peak).

Dépassement du goulot d'étranglement du CPU et multiplicateur de bande passante

La signification de cette architecture I/O pour Nanite est très profonde. Le tableau suivant résume l'importance des économies de CPU permises par la technologie de compression de la PS5 par rapport aux concurrents et aux générations précédentes :

Métrique de matériel et d'algorithme de compressionPS4 / Génération précédenteXbox Series XPlayStation 5Algorithme de compression de baseZLIB (Axé sur le logiciel)BCPack (Variante matérielle de ZLIB)Oodle Kraken + Oodle Texture (Matériel personnalisé)Vitesse de sortie maximale (Peak Bandwidth)~100-200 Mo/s~6 Go/s (Effectif avec SFS)~22 Go/sVitesse de sortie moyenne (Average Bandwidth)< 100 Mo/s~4.8 Go/s8-9 Go/s (17 Go/s avec Oodle)Équivalent de performance d'économie du processeur (CPU)Charge entièrement le processeurÉquivalent d'environ 5 cœurs Zen 2Équivalent d'environ 9 cœurs Zen 2

Ce tableau montre clairement que le complexe I/O de la PS5 prend entièrement à sa charge l'effort que dépenseraient exactement 9 cœurs de processeur Zen 2 indépendants pour décompresser des données à partir d'un SSD sur un ordinateur traditionnel.

Lorsque Nanite demande des dizaines de milliers de nouvelles grappes (streaming pages) depuis le disque à chaque image (en 16 ms) selon le nouveau point de vue de la caméra, ces données lues depuis le SSD alimentent directement les pools de RAM et de GPU en contournant complètement le CPU grâce à la puce matérielle Kraken. Les développeurs de jeux peuvent exploiter pleinement la philosophie "Virtual Texturing for Geometry" (Texture virtuelle pour la géométrie) de Nanite sans craindre que les données "n'arrivent pas à temps" (pop-in). Conscient de ce potentiel massif, les ingénieurs d'Epic Games ont réécrit de zéro, spécifiquement pour la PS5, les sous-systèmes de chargement du noyau (core I/O subsystems) d'Unreal Engine 5 pour cette structure I/O unique de la PS5.

Gestion de la VRAM et optimisation du pool de streaming

La PlayStation 5 dispose d'une mémoire GDDR6 unifiée (unified) ultra-rapide d'une capacité de 16 Go. Cependant, contrairement aux architectures PC, les limites de mémoire sur les consoles sont rigides et fixes (fixed memory) ; les dépassements de mémoire virtuelle ne sont pas tolérés et entraînent un crash direct du système (OOM - Out of Memory).

Les pools de mémoire (streaming pool) utilisés par Nanite grandissent de manière géométrique en fonction de la résolution de l'écran. Nanite utilise un tampon de visibilité (visibility buffer) proportionnel à la taille de l'écran pour stocker les identifiants des triangles. Lorsque la résolution passe de 1080p à 4K (le nombre de pixels étant multiplié par quatre), le besoin en VRAM du tampon de visibilité est également multiplié par 4.

Pour assurer l'optimisation dans les projets PS5 et gérer la VRAM, la taille du "Nanite Streaming Pool" doit être limitée par le développeur. Alors que la taille du pool par défaut oscille autour de 512 Mo dans les projets vides, dans un projet AAA lourd en Nanite, le paramètre suivant doit être configuré dans la ligne de commande ou dans les fichiers .ini (par exemple dans DefaultEngine.ini) :

r.Nanite.Streaming.StreamingPoolSize = 2048

(Environ 2000-3000 Mo selon la lourdeur de la scène et les autres systèmes). Si ce budget de pool est maintenu trop restreint, les grappes hautement détaillées des objets lointains ne pourront pas être chargées à temps et Nanite basculera sur les modèles de secours (fallback models) ; s'il est maintenu trop large, il ne restera plus de RAM pour les caches de surface de Lumen (Surface Cache), les textures haute résolution et le système d'exploitation. Avec UE 5.7, les développeurs verront un système d'alerte s'activer dans les situations de StreamingPoolSize dépassant les limites de la console (généralement un dépassement de 2-4 Go).

Exigences de développement et configurations de console de la PlayStation 5

Bien que le processus de développement pour la plateforme PS5 avec Unreal Engine 5 soit devenu extrêmement raffiné grâce aux efforts conjoints d'Epic Games et de Sony, le kit de développement logiciel (SDK) spécifique et les configurations système doivent impérativement être respectés pour que le projet puisse être compilé et fonctionner à une vitesse optimale.

Versions du SDK et indicateurs (flags) du compilateur

Voici les exigences en matière de bibliothèques matérielles et logicielles à prendre en compte lors de la compilation (build) sur le matériel PS5 avec les versions actuelles 5.6 et 5.7 d'Unreal Engine :

• Versions de SDK et de système prises en charge : L'exigence de base pour l'environnement de développement PS5 est définie comme "Prospero SDK 11.00.00.40" (ou SDK 12 pour les systèmes de stockage avancés) et "System Software 11.00.00.43". Les incompatibilités de versions (lors de l'utilisation de plugins tiers tels que IntlNetwork SDK ou Interhaptics) dans la configuration du projet sont une cause de plantage.

• Configuration du compilateur : Pendant les processus de compilation, clang-cl est utilisé en plus de la propre chaîne d'outils (toolchain) de Sony. Pour éviter les comportements indéfinis (undefined behavior) et les erreurs NaN (Not a Number) sur Clang 19, les codes sources sont désormais obligatoirement compilés avec l'indicateur -fhonor-nans. De plus, le paramètre -ffp-contract=off, qui créait des problèmes inter-plateformes par le passé, a été supprimé du compilateur PS5 car il entre en collision avec -ffast-math.

• Migration de la bibliothèque standard (Stdlib) : Avec UE 5.7, la prise en charge de la bibliothèque standard C++20 (stdlib v2) a été ajoutée pour la PS5. Il est fortement recommandé aux développeurs d'effectuer l'attribution StandardLibVersion = 'v2' via les fichiers de configuration UEBuildPS5.cs ou BuildConfiguration.xml pour une compatibilité future et un gain de performance.

• Paramètres d'optimisation du système : Un nouveau système de cache LRU (Least Recently Used) a été introduit dans l'architecture AgcRHI pour empêcher l'accumulation d'états d'échantillonneur (sampler) sur le GPU. Cette limite est configurée par défaut à r.Agc.MaxSamplerStates 4096.

Profils d'extensibilité (Scalability) pour l'objectif de 60 FPS

UE5 est configuré par défaut sur les consoles PS5 et Xbox Series X pour cibler 30 FPS (33.3 ms par image) au niveau de qualité "Epic". Viser 60 FPS (16.6 ms par image) dans les jeux modernes sous l'effet du ray tracing et d'une charge polygonale massive nécessite de faire des sacrifices conscients sur la résolution de rendu et la qualité de Nanite et Lumen.

Les studios souhaitant lancer un jeu sur PS5 avec une expérience fluide à 60 FPS doivent abaisser la qualité de l'illumination globale (GI) Lumen et des systèmes de réflexion au profil "High" dans les paramètres DeviceProfiles.ini au niveau du moteur pour s'adapter au budget des 60 FPS. Dans ce profil, le jeu est rendu en interne (internal resolution) autour de 1080p ou 1440p avant d'être mis à l'échelle (upscale) par Temporal Super Resolution (TSR).

Le bloc de configuration suivant doit être ajouté directement dans le fichier [ProjectName]\Platforms\PS5\Config\PS5DeviceProfiles.ini situé dans le répertoire du jeu :

; Set Lumen GI and reflection quality to High, targeting 60 fps console budget
+CVars=sg.GlobalIlluminationQuality=2
+CVars=sg.ReflectionQuality=2

Cette configuration ramène le poids de calcul de Lumen aux limites de la console, laissant aux millions de polygones traités par Nanite une marge de respiration de 16.66 ms par image. De plus, il est important de maintenir actives les capacités de détection de géométrie fine (Thin Geometry detection) de TSR afin d'accroître les performances de Nanite.

Améliorations spécifiques à la PS5 pour la synchronisation de Lumen et Nanite

Le système Nanite est à lui seul uniquement responsable du dessin géométrique statique ; cependant, ce qui détermine la qualité visuelle du jeu, c'est Lumen, le système d'illumination globale (Global Illumination) qui rebondit sur les surfaces Nanite et génère des ombres photoréalistes. Lorsque les deux systèmes se combinent, le matériel de la PS5 est poussé dans ses derniers retranchements.

Lumen possède deux modes de fonctionnement : le Ray Tracing Logiciel (SWRT) utilisant des champs de distance (Distance Fields), et le Ray Tracing Matériel (HWRT) calculant directement les triangles. Nanite alimente la géométrie complexe qu'il possède dans le mécanisme HWRT par l'intermédiaire des maillages de secours (Fallback Meshes) mentionnés précédemment. Alors que dans les versions de moteurs de génération précédente, le SWRT était nécessairement recommandé pour 60 FPS, dans les versions 5.6 et 5.7 d'Unreal Engine, des améliorations fondamentales du HWRT ont été réalisées pour soulager le matériel des consoles (en particulier les cœurs RT de la PS5 basés sur l'architecture AMD RDNA2) :

1. Optimisation ShortRangeAO : Les calculs d'occlusion ambiante (Ambient Occlusion) à courte portée sont désormais exécutés à demi-résolution (half resolution) à l'aide d'un nouveau suppresseur de bruit (denoiser). Ce traitement permet à cette transition d'être exactement deux fois plus rapide sur les consoles. 49

2. Mode Far Field Occlusion Only : Dans les vastes mondes ouverts, les calculs de rebond provenant d'objets Nanite très lointains chargés par le système World Partition peuvent saturer le système. En utilisant la nouvelle commande r.LumenScene.FarField.OcclusionOnly 1, les performances de champ lointain de Lumen sont accélérées de 50 % sur PS5. 49

3. Downsampled Screen Probe Gather : Lors de la passe Screen Probe Gather qui projette l'éclairage ambiant sur l'écran, la réduction du taux d'échantillonnage d'intégration entre les pixels (r.Lumen.ScreenProbeGather.IntegrateDownsampleFactor) fait gagner 0.3 à 0.5 ms sur un scénario de rendu en 1080p sur PS5. 20 Bien qu'un léger adoucissement soit visible dans les détails, ce compromis est tout à fait idéal pour le budget de 60 Hz.

4. Shader Execution Reordering (SER) : Dans les scènes complexes utilisant HitLighting et la translucidité par ray tracing (ray-traced translucency) et comportant de nombreux matériaux différents, la commande r.Lumen.HardwareRayTracing.ShaderExecutionReordering, qui active le réordonnancement des commandes au niveau matériel, apporte une accélération sur les unités RHI prises en charge. 49

Si le développeur se heurte aux limites de rendu de la PS5 malgré les optimisations élevées de Nanite dans sa scène, il doit mesurer le coût du HWRT avec le profil "stat gpu" et tester, si nécessaire dès les premières phases du projet (optimize early), un scénario de retour aux Shadow Maps classiques à la place des Virtual Shadow Maps (VSM) sur les lumières directionnelles afin de réduire le coût des calculs d'ombres. 25

Conclusion stratégique et recommandations pour les développeurs

Conformément aux analyses approfondies menées, l'architecture Nanite d'Unreal Engine 5 crée une véritable révolution dans l'industrie des graphismes informatiques en mariant les capacités modernes des compute shaders pour GPU, l'intégration du ray tracing matériel et les algorithmes de compression de données de nouvelle génération. Cette technologie, qui fait des nombres de polygones et des goulots d'étranglement des draw calls des obstacles du passé, apporte avec elle de nouveaux flux de travail (assemblages, voxelisation) et des disciplines strictes de budget mémoire (Streaming Pools).

Voici les principales conclusions stratégiques que les artistes techniques (Technical Artists) et les ingénieurs moteurs (Engine Programmers) développant des jeux sur la plateforme PlayStation 5 doivent garder à l'esprit :

1. Utiliser l'avantage I/O correctement et aux limites : Le décompresseur matériel Kraken unique de la PS5 fournit une bande passante I/O incroyable via le SSD. Il est plus conforme au flux naturel du système que les développeurs s'éloignent des anciennes stratégies LOD manuelles qui restreignent le streaming Nanite et s'orientent directement vers l'utilisation du maillage source d'origine (source mesh) de qualité cinématographique.

2. Éviter les coûts de transparence et de surdessin (Overdraw) : Les animations basées sur le WPO (World Position Offset) et l'utilisation d'Alpha Mask/Cutout, qui constituent le talon d'Achille de Nanite, sont des tueurs de performances, en particulier pour la végétation. Les fonctionnalités Nanite Voxels, Nanite Assemblies et Nanite Skinning introduites avec UE 5.6 et 5.7 doivent être adoptées comme la méthode clé pour remplacer la modélisation traditionnelle de l'herbe dans les objectifs de mondes ouverts à 60 FPS sur PS5. Plutôt que l'optimisation des modèles, une orientation vers des géométries "Opaque" hautement polygonales mais lisses est impérative.

3. Effectuer une budgétisation précise de la VRAM : La structure mémoire fixe de la PS5 peut être rapidement consommée par les identifiants de visibilité Nanite (Visibility Buffer) et les caches de surface de Lumen. Les limites de StreamingPoolSize doivent être établies méticuleusement et, au lieu d'une mise à l'échelle en résolution native 4K, des objectifs de résolution interne de 1080p à 1440p accompagnés de Temporal Super Resolution (TSR) doivent être utilisés pour synthétiser une haute qualité visuelle avec une cadence d'images stable.

4. Analyse de profilage régulière et précoce (Optimize Early) : Les outils de profilage stat gpu, stat unit et NaniteStats doivent être suivis activement sans attendre la fin du processus de développement. Les configurations de matériaux créant des Raster Bins problématiques doivent être détectées et fusionnées afin de réduire au minimum le changement d'état (state change) entre le CPU et le GPU.

Nanite n'est pas une baguette magique augmentant les performances ; c'est au contraire un écosystème très puissant qui, lorsque ses capacités sont correctement exploitées, ne bride pas la vision artistique, mais qui, lorsque ses règles ne sont pas respectées (par exemple en raison d'une utilisation excessive de matériaux masqués), se heurte durement aux barrières matérielles. Lorsque l'architecture I/O dédiée du matériel de la PS5 et les innovations de rendu d'Unreal Engine 5 fonctionnent de manière synchronisée, les frontières visuelles et volumétriques des médias interactifs s'élargissent d'une manière sans précédent.

*Information : Les visuels ont été générés par Google Gemini.