Ne commencez pas par appliquer le budget de triangles d’un autre. Commencez par un test reproductible. Sinon, un serveur moins chargé ou un autre angle peut sembler être une optimisation réussie.
Il s’agit d’une méthode technique pour votre carte, pas d’affirmations de benchmark sur CodeWalker ou FiveM.
Figez la référence initiale
Notez version des assets, machine cliente, graphismes, résolution, édition cible et ressources serveur. Choisissez des points fixes : approche depuis la rue, entrée, pièce principale et vue intérieure la plus détaillée.
Parcourez la même route plusieurs fois. Notez les temps d’image si l’outil les fournit et les conditions de chaque passage. Incluez une première approche à froid et une visite répétée ; ne les comparez pas sans préciser la différence.
Un changement n’est utile que si le test mesure la même chose avant et après. Conservez le paquet original pour le retester directement.
Distinguez les facteurs de coût
Examinez géométrie, variété des matériaux, dimensions des textures, complexité des collisions et contenu visible par les ouvertures. Ce sont des facteurs distincts. Réduire l’un ne prouve pas qu’un autre n’est plus limitant.
Faites une petite intervention, comme simplifier un objet décoratif, puis répétez le parcours. Si la différence reste dans la variation de référence, notez-le plutôt que d’inventer un gain.
Pour une scène dense, une version de diagnostic épurée peut aider. Retirez une catégorie de décoration facultative dans un build séparé, sans toucher aux pièces ni au placement. C’est une expérience, pas l’optimisation finale.
Utilisez les niveaux de détail délibérément
Le README de CodeWalker explique les niveaux de détail hiérarchiques de GTA et leur relation avec la distance de caméra. Certains contenus détaillés nécessitent aussi le bon contexte de carte chargé dans le visualiseur.
Un modèle peu détaillé doit conserver silhouette et grands traits nécessaires à sa distance d’observation. Inspectez la transition depuis plusieurs approches. Un maillage réduit n’est pas un bon résultat s’il provoque un changement brusque gênant à l’entrée.
Ne corrigez pas tout problème de visibilité en augmentant la distance d’affichage. Vérifiez d’abord placement, limites et hiérarchie. Une distance plus grande peut cacher une erreur structurelle tout en exposant trop de contenu.
Examinez les textures avec l’asset en vue
Listez dimensions des textures, contenus répétés et usages réels. Une grande texture sur un objet minuscule à l’écran mérite examen, tout comme un dictionnaire de textures dupliqué par erreur.
Faites un remplacement contrôlé : changez la résolution d’un asset, inspectez-le à la distance prévue la plus proche et comparez les mesures du parcours. Préservez la qualité nécessaire à l’usage au lieu d’optimiser un chiffre isolé.
Ne confondez pas taille du ZIP sur disque et mémoire à l’exécution. Compression, formats de textures et chargement des assets affectent différentes parties du système. Rapportez la mesure réelle sans substituer une métrique à une autre.
Revérifiez le graphe intérieur
Une correction montrant tout l’intérieur depuis chaque point voisin peut coûter différemment d’une configuration de pièces bien délimitée. Revérifiez les tests de pièces et de portails après les changements structurels.
Ne supprimez pas des limites utiles pour cacher un bogue de portail. Séparez correction et optimisation comme critères : la carte doit d’abord montrer le contenu prévu, puis le faire dans les conditions de performance visées.
Publiez des observations, pas des affirmations universelles
Une note utile précise matériel, réglages, parcours, versions comparées et résultat. « Optimisé » sans ces détails informe peu un autre exploitant.
Terminez par la liste de contrôle de publication. Reconnexion, collisions et ressources voisines restent importantes après une bonne comparaison des temps. Une optimisation qui casse une ouverture n’est pas livrable.
Utilisez une fiche de performances reproductible
Téléchargez le CSV vierge de test de performances. Il contient des champs, pas des benchmarks inventés. Notez édition, versions jeu/serveur, révision, CPU/GPU, RAM, résolution, graphismes, météo/heure et parcours nommé. Gardez ces conditions fixes entre référence et candidat.
Utilisez une ligne par répétition et distinguez chargement à froid et parcours déjà chargé. Mesurez les temps d’image par la même méthode pour les deux candidats ; utilisez le calcul documenté de la médiane et du 95e percentile. Un temps inférieur est meilleur, mais un écart plus petit que la variation entre passages ne prouve pas une amélioration convaincante.
Vérifiez la correction visuelle et physique avec les temps. Une pièce absente peut s’afficher plus vite précisément parce qu’elle manque. Rejetez un gain apparent cassant visibilité, textures, collisions ou distance nécessaire. Notez la taille des ressources sans la présenter seule comme une mesure de performance GPU.
Comparez un changement à la fois
Gardez le paquet de référence intact, changez un asset ou une relation et répétez le parcours. Restaurez la référence pour vérifier que l’effet suit le candidat plutôt qu’une autre session ou caméra. Rapportez matériel et conditions sans promettre un gain universel de FPS.
Utilisez le parcours des portails pour détecter les régressions de visibilité et la liste de contrôle de publication pour conserver les preuves. Un aperçu de représentations dans le navigateur n’est pas un benchmark du rendu de GTA V.