Introduction : Le défi de l'optimisation géométrique dans les jeux modernes
Les décors des jeux vidéo modernes en monde ouvert — qu'il s'agisse des forêts denses de The Witcher 3, des dédales urbains verticaux de Cyberpunk 2077 ou des panoramas infinis de Horizon Zero Dawn — comportent couramment plusieurs dizaines de millions de polygones, des centaines de sources de lumière et des gigaoctets de textures haute résolution pour chaque image affichée. Si le processeur graphique (GPU) devait transformer, rastériser et ombrer chaque triangle présent dans l'univers virtuel pour chaque rafraîchissement d'écran, le matériel le plus puissant s'effondrerait sous la charge, plafonnant à des fréquences d'images à un chiffre.
Le rendu 3D en temps réel est avant tout l'art de l'élimination. Les moteurs de jeu n'atteignent des fréquences de rafraîchissement élevées qu'en éliminant impitoyablement toute la géométrie que le joueur ne peut pas voir.
Cette sélection visuelle s'opère au moyen d'une architecture à trois niveaux : le Frustum Culling (découpage par volume de vision), l'Occlusion Culling (élimination par masquage) et la gestion des Niveaux de détail (LOD). Lorsque ces technologies s'articulent harmonieusement, elles épargnent des volumes colossaux d'appels de rendu (Draw Calls) au processeur et de bande passante au GPU. En revanche, si elles sont calibrées de manière trop agressive ou désynchronisées par des mouvements brusques de caméra, elles engendrent l'un des artefacts visuels les plus frustrants du jeu sur PC : l'apparition soudaine d'objets (Pop-in de géométrie).
Frustum Culling : L'élimination de la géométrie hors du champ de vision
Le Frustum Culling représente le premier test de visibilité, et le moins exigeant en ressources de calcul, exécuté par un moteur au sein du pipeline graphique.
[Position de la caméra / Œil du joueur]
/ \
/ \
Plan de coupe /=====\
proche / ▲ \
/ │ \ <--- Dans le frustum (RENDU ACTIF)
/ [Visible] \
/ Objet \
Plan de coupe /=============\
lointain / \
[Exclu: gauche] [Exclu: fond] [Exclu: droite]
La géométrie du tronc de vision de la caméra
En infographie 3D, le champ de vision d'une caméra n'est pas un parallélépipède infini, mais une pyramide dont le sommet est tranché, appelée géométriquement un tronc de pyramide (Frustum). Le frustum est défini de façon rigoureuse par six plans mathématiques :
- Plan de coupe proche (Near Plane) : Élimine la géométrie trop proche de la caméra afin d'éviter que les polygones ne traversent la lentille virtuelle.
- Plan de coupe lointain (Far Plane) : Fixe la distance d'affichage maximale ; tout élément situé au-delà est ignoré.
- Plans latéraux, supérieur et inférieur : Établis par le champ de vision (FOV) de la caméra et le format d'image de l'écran.
Volumes englobants et tests d'intersection
Tester les coordonnées de millions de sommets individuels (vertices) face à six plans sur le CPU paralyserait le système. Pour parer à cela, les moteurs entourent chaque maillage 3D d'un volume englobant (Bounding Volume) très simplifié :
- Boîte englobante alignée sur les axes (AABB) : Un pavé droit aligné avec les axes du monde virtuel.
- Sphère englobante (Bounding Sphere) : Une sphère définie uniquement par un centre et un rayon.
Avant de transmettre un appel de rendu vers DirectX, Vulkan ou le pilote graphique, le moteur effectue un simple calcul de produit scalaire entre la sphère englobante et les six plans. Si le volume se trouve entièrement en dehors d'au moins un des plans, l'intégralité du maillage est écartée sur-le-champ, et le GPU ne reçoit aucun sommet pour cet objet.
Occlusion Culling : Supprimer la surconsommation de pixels invisibles (Overdraw)
Bien que le frustum culling élimine tout ce qui se trouve derrière le joueur ou hors du champ de vision, il ne résout pas le problème de la sursaturation de rendu (Overdraw) : des objets qui résident bien à l'intérieur du champ de vision, mais sont intégralement dissimulés derrière des obstacles au premier plan, comme des remparts, des collines ou des portes closes.
Calculer intégralement une ville médiévale et ses échoppes situées derrière un rempart en granit massif représenterait un gaspillage flagrant de puissance de calcul. Les moteurs de jeu font appel à l'Occlusion Culling pour supprimer ces maillages masqués.
[Point de vue] ───► [Massif rempart de pierre de taille] ───X (VUE BLOQUÉE)
│
(Test d'Occlusion Culling)
│
┌─────────┴─────────┐
▼ ▼
[Marché dissimulé] [Forge dissimulée]
(DRAW CALL SUPPRIMÉ) (CHARGE GPU : ZÉRO)
Trois grandes approches d'Occlusion Culling
- Ensembles potentiellement visibles (PVS) et systèmes de cellules et portails :
- Très répandus dans les jeux de tir en couloirs et les environnements fermés (classiques des moteurs id Tech et Source).
- Le niveau est découpé en pièces (cellules) reliées par des ouvertures (portails). Si un portail n'est pas dans le champ de vision, toute la pièce reliée et ses objets ne sont pas calculés.
- Requêtes d'occlusion matérielle (Hardware Occlusion Queries) :
- Le moteur soumet au GPU les boîtes englobantes des objets distants et interroge : « Est-ce qu'un seul pixel de cette boîte a passé le test de profondeur (Z-buffer) ? ».
- Si la réponse est zéro pixel, le maillage complexe est ignoré pour les images suivantes.
- Le piège de la latence : Récupérer la réponse du GPU via le bus induit un décalage de synchronisation de 1 à 2 images entre CPU et GPU. Lors d'un demi-tour rapide, ce délai fait clignoter les objets ou les fait apparaître en retard.
- Tampon Z hiérarchique (HZB) et culling par Compute Shader :
- Standard des moteurs modernes comme Unreal Engine 5 et Unity HDRP. Le tampon de profondeur de l'image précédente est réduit en une pyramide de textures de profondeur (HZB).
- Les Compute Shaders du GPU comparent en parallèle des dizaines de milliers de boîtes englobantes à cette pyramide au sein même de la VRAM, sans bloquer la communication avec le CPU.
Niveaux de détail (LOD) et mécanique d'apparition soudaine (Pop-in)
Même lorsqu'un objet se trouve dans le champ de vision et n'est pas masqué, afficher une statue de 100 000 polygones qui n'occupe que 8 pixels à l'horizon est contre-productif. Pour résoudre ce problème, on utilise les Niveaux de détail (LOD).
LODs discrets contre géométrie virtualisée
- LODs discrets (LOD 0 à LOD 4) : Les artistes 3D créent plusieurs versions d'un même élément. Le LOD 0 correspond au modèle haute définition de près (ex. 50 000 polygones) ; le LOD 1 divise la complexité par deux à 20 mètres ; le LOD 4 réduit l'objet à une simple silhouette de 200 polygones à 200 mètres.
- Fondu croisé tramé (Dithered Crossfading) : Pour masquer le saut visuel brutal lors de la bascule d'un modèle à l'autre, le moteur applique une transition pointillée semi-transparente sur 10 à 20 images, créant un fondu fluide pour l'œil.
- Géométrie virtualisée (comme Nanite sous Unreal Engine 5) : Supprime la fabrication manuelle de LODs. Les maillages sont découpés en petits groupements (clusters) qui s'adaptent dynamiquement à la densité de pixels de l'écran, éliminant totalement le pop-in géométrique traditionnel.
Pourquoi le Pop-in survient : Les limites physiques du streaming
L'apparition soudaine de bâtiments, de feuillages ou de textures nettes (« pop-in ») est rarement une erreur de programmation, mais le résultat d'un goulet d'étranglement matériel dans le flux de chargement continu (Asset Streaming) :
- Latence d'E/S du stockage : Les disques durs mécaniques ou SSD SATA saturés ne parviennent pas à charger des centaines de mégaoctets de maillages en quelques millisecondes vers la RAM système.
- Bande passante du bus PCIe et VRAM : Lors des rotations brusques de caméra, le transfert des tampons de sommets et des textures vers la mémoire vidéo arrive à saturation.
- Délai d'invalidation de masquage : En sortant vivement d'un angle mort, la caméra se déplace plus vite que le système HZB ne met à jour l'état de visibilité, décalant l'apparition des éléments de quelques dizaines de millisecondes.
Matrice de diagnostic : Défauts visuels de culling et de transitions LOD
Reconnaître précisément l'origine des anomalies permet d'appliquer les bons réglages dans le moteur :
| Symptôme visuel | Sous-système en cause | Mécanisme technique sous-jacent | Correction recommandée |
|---|---|---|---|
| Objets disparaissant sur les bords de l'écran | Frustum Culling | Calcul de boîte englobante trop serré ou FOV décalé | Augmenter la marge de sécurité du champ de vision dans les configs |
| Clignotement des bâtiments en tournant un angle | Occlusion Culling | Latence de synchronisation des requêtes matérielles | Activer l'occlusion par Tampon Z Hiérarchique (HZB) |
| Modèles changeant de forme de façon abrupte | Biais de LOD discret | Distances de bascule trop courtes pour économiser des ressources | Augmenter la « Distance d'affichage » ou « Détail des maillages » |
| Ombres au sol apparaissant d'un coup à 10 mètres | Cascaded Shadow Maps (CSM) | Distance de coupure des cascades d'ombres trop faible | Augmenter la distance des ombres ou le nombre de cascades |
| Textures floues qui tardent à devenir nettes | Streaming de Mipmaps | Saturation de la VRAM ou disque trop lent pour charger les Mips | Installer le jeu sur SSD NVMe ; baisser la qualité des textures |
L'optimisation du rendu en temps réel repose sur un compromis subtil entre puissance de calcul, débits mémoires et vitesse de stockage. En s'appuyant sur les dossiers techniques de 365Finds, joueurs et développeurs de mods peuvent ajuster les paramètres de rendu pour éradiquer le pop-in géométrique sans compromettre la régularité de la fréquence d'images ni la stabilité matérielle.