Optimiser les Fichiers pour FiveM

Compression des textures, mipmaps, LOD, taille des fichiers et vérifications des crashs pour les Fichiers streamés.

Guides 2 mai 2026 9 min de lecture

Syntax Platform team

L'optimisation des Fichiers dans FiveM a un objectif simple : réduire le coût de chargement, d'affichage et de conservation en mémoire de chaque fichier streamé pour le client. Des fichiers plus petits aident, mais le meilleur résultat est celui qui réduit la pression à l'exécution sans casser le Fichier.

La bonne solution dépend du fichier. Un véhicule sans LOD nécessite du travail sur le modèle. Un dictionnaire de textures rempli de textures alpha surdimensionnées nécessite un redimensionnement et une meilleure compression. Un prop avec une collision défectueuse nécessite de vérifier le modèle avant de s'occuper de la taille des textures.

Commencer par le fichier le plus coûteux

La plupart des Fichiers streamés pèsent sur l'un de ces trois éléments : la mémoire des textures, la géométrie ou les mauvaises références. Utiliser le type de fichier pour savoir où regarder en premier.

Fichier	Principale source de charge	Outil Zoovdev	À vérifier
`.ytd`	Mémoire des textures, taille sur disque, mipmaps, formats alpha	Optimiser les textures	Dimensions des textures, compression DDS, entrées inutilisées, mipmaps
`.yft`	Géométrie du véhicule, fragments, comportement de la distance d'affichage	Optimiser les véhicules	Résultat des LOD, noms des modèles, aucun upload de `_hi.yft`
`.ydr`	Géométrie du prop, matériaux, textures intégrées	Optimiser les props	Nombre de matériaux, liens de textures, configuration des collisions, état de l'exportation
`.ydd`	Taille des drawable de Vêtements et utilisation des textures	Optimiser les Vêtements	Taille des textures, nombre de drawable, échelle des éléments, tests dans le menu des Vêtements en jeu
`.ybn`	Coût des collisions et limites défectueuses	Outils de création	Limites simples, matériaux corrects, placement, tests de crash
`fxmanifest.lua`	Chargement des ressources et références des données	Agent de code	Entrées `files`, lignes `data_file`, chemins du dossier stream, références meta

YTD et DDS ne désignent pas la même chose

Un .ytd est un dictionnaire de textures RAGE. Il stocke des textures nommées utilisées par les fichiers .ydr, .yft et .ydd. Un .dds est un format de fichier de texture souvent utilisé comme format source, d'exportation ou intermédiaire pour ces entrées de texture.

Quand quelqu'un parle de compresser un YTD, il s'agit généralement de redimensionner et de recompresser les textures qu'il contient. La compression DDS est une compression par blocs de textures GPU. Elle diffère de la compression d'archive de type zip, car la carte graphique peut échantillonner directement les blocs compressés.

Format	Utilisation adaptée	Compromis
`BC1 / DXT1`	Textures diffuses ou de couleur sans alpha lisse	Compact, 8 octets par bloc de 4x4, mais médiocre sur les dégradés et alpha limité
`BC3 / DXT5`	Textures diffuses, livrées, décalcomanies ou de type UI nécessitant un alpha	Bonne prise en charge, 16 octets par bloc de 4 x 4, deux fois la taille de BC1
`BC5`	Normal maps ou données de masque à deux canaux	Plus propre pour les données à deux canaux, mauvais choix pour les textures en couleur complète
`BC7`	Textures couleur ou alpha de haute qualité, livrées vues de près, détails peints	Plus propre que les anciens formats dans de nombreux cas, mais plus lent à encoder, plus volumineux que BC1, et les en-têtes DDS récents peuvent poser problème avec les anciens outils
Non compressé	Débogage ou cas particuliers où le format l'exige	Utilisation de mémoire très élevée. À éviter pour le contenu streamé normal.

Mipmaps

Les mipmaps sont des copies plus petites d'une même texture. Une texture de 1024 x 1024 obtient des niveaux de 512 x 512, 256 x 256, puis de plus en plus petits. Le moteur de rendu utilise les niveaux inférieurs lorsque l'objet est éloigné.

De bonnes mipmaps réduisent le scintillement, les contours instables et l'échantillonnage bruyant des textures à distance. Elles ajoutent des données de texture, mais pour les props du monde, les véhicules, les vêtements et les Fichiers de carte, c'est généralement le bon compromis. Générer les mipmaps après le redimensionnement et la compression finale afin que la chaîne corresponde à la texture exportée.

Conserver les mipmaps pour les véhicules, les props, les vêtements, les panneaux et les surfaces de carte visibles à distance.
Faire attention en supprimant les mipmaps des textures avec des bords alpha. Le Fichier peut sembler net dans un Aperçu et scintiller fortement en jeu.
N'ignorer les mipmaps que pour une raison précise, comme un chemin de texture qui n'est jamais échantillonné à distance.

Tailles de texture en puissances de 2

Utiliser des tailles de texture en puissances de deux, souvent notées PO2, POT ou power of 2 : 64, 128, 256, 512, 1024, 2048 et 4096. Pour les Fichiers RAGE et GTA, c'est une règle de sécurité, pas seulement une bonne habitude d'export.

Les textures non-PO2 peuvent faire plus que gaspiller de la mémoire. Dans les chemins RAGE, elles peuvent casser l'échantillonnage ou échouer d'une manière qui semble sans rapport avec leur taille. Un résultat fréquent est le texture bleed : le matériau commence à récupérer des pixels depuis des entrées de texture voisines dans le dictionnaire, ce qui donne l'impression qu'un prop, véhicule ou vêtement référence la mauvaise texture.

Tailles de texture recommandées

Il n'existe pas de limite de taille unique utile pour tous les serveurs. La vraie limite dépend du nombre de ressources streamées en même temps, de la proximité des joueurs avec le Fichier, du format de texture et du matériel client. Un avertissement fréquent dans la communauté concerne un seul dictionnaire de textures atteignant environ 16 MB de mémoire physique de texture. Considérer cela comme une raison d'inspecter le Fichier, pas comme une règle absolue.

Fichier	Bon point de départ	Notes
Petits props, éléments de décor, décalcomanies	256 à 512	Utiliser 1024 uniquement si le joueur lit ou examine la surface de près.
Panneaux lisibles, affiches, props de marque	512 à 1024	Utiliser 2048 pour de grands visuels lisibles vus de près. Recadrer les espaces vides avant d'augmenter la taille.
Livrées de véhicules et textures diffuses	1024 à 2048	Utiliser 4096 pour les véhicules d'exposition vus de près ou les livrées très détaillées, puis tester le coût mémoire.
Normal maps, roughness, specular et masques de véhicules	512 à 1024	Ces textures peuvent souvent être plus petites que la diffuse. Utiliser le bon format de données, comme BC5 pour les normal maps.
Vêtements	512 à 1024	Réserver 2048 aux grands vêtements avec des détails visibles. Les petits accessoires en ont rarement besoin.
MLO et textures de carte	512 à 1024 par matériau réutilisé	Répartir les dictionnaires de manière logique et réduire les surfaces répétées en 2K ou 4K avant de modifier la géométrie.

Taille de texture	BC1 / DXT1 avec mipmaps	BC3 / DXT5 ou BC7 avec mipmaps
1024 x 1024	Environ 0,7 Mio	Environ 1,3 Mio
2048 x 2048	Environ 2,7 Mio	Environ 5,3 Mio
4096 x 4096	Environ 10,7 Mio	Environ 21,3 Mio

Mémoire de texture approximative avec des chaînes de mipmaps complètes. La taille réelle du YTD peut varier, car les dictionnaires incluent des noms, des en-têtes et plusieurs entrées de texture.

Optimisation des véhicules et `_hi.yft`

Pour les véhicules, l'optimisation principale côté modèle consiste à générer des LOD pour les fichiers .yft. Ne pas inclure les versions _hi.yft dans l'optimiseur de véhicules Zoovdev. L'optimiseur ignore ce type et génère les données LOD à partir des fichiers de modèles de véhicules normaux.

Un fichier .yft optimisé plus volumineux peut être un bon résultat. Le fichier peut contenir plus de données, car il inclut désormais des modèles moins détaillés pour l'affichage à distance. L'avantage est que les clients peuvent afficher une géométrie moins coûteuse lorsque le véhicule est éloigné. Les économies de texture pour les véhicules proviennent généralement des fichiers .ytd associés.

Importer les fichiers de véhicules .yft normaux, pas les fichiers _hi.yft.
Optimiser les fichiers .ytd séparément.
Tester l'apparition du véhicule, s'en éloigner en conduisant, y revenir et redémarrer la ressource.
Conserver des noms de modèles, de dictionnaires de textures et des références meta de véhicules cohérents.

Props, vêtements et collisions

Les props en .ydr et les vêtements en .ydd bénéficient généralement d'une géométrie correcte, de moins de matériaux inutiles et de dictionnaires de textures plus petits. Si les textures sont intégrées dans le drawable, vérifier la sortie du modèle et des textures après l'exportation.

La collision en .ybn doit être plus simple que le mesh visuel. De mauvaises limites peuvent causer des problèmes de physique, des interactions défectueuses ou des crashs qui semblent sans rapport avec le modèle. Tester la collision en jeu après l'exportation, surtout pour les MLO, les grands props et les éléments de carte déplacés.

Vérifications de la ressource et du manifeste

FiveM stream automatiquement les Fichiers placés dans le dossier stream/ d'une ressource. Ne pas lister les fichiers .ytd, .yft, .ydr ou .ydd streamés dans files simplement parce qu'ils se trouvent dans stream/. Utiliser le manifeste pour référencer les fichiers de données et meta qui nécessitent un chargement explicite.

lua

files {
    'data/**/*.meta'
}

data_file 'VEHICLE_METADATA_FILE' 'data/vehicles.meta'

De mauvaises lignes data_file peuvent faire paraître un fichier sain défectueux. Si les fichiers streamés sont dans le bon dossier stream/ mais que la ressource se comporte toujours mal, vérifier les références meta, les noms de fichiers et les déclarations de fichiers de données avant d'accuser la compression.

Symptômes de crash et comment les cerner

Les crashs liés aux Fichiers se manifestent souvent par des symptômes plutôt que par un nom de fichier clair. Des messages de pointeur invalide, des erreurs mémoire neither virtual nor physical, des blocages de requêtes DirectX ou du GPU, failed to call inflate() for streaming file, ou un crash qui survient uniquement lorsqu'une personne fait apparaître un véhicule, s'approche d'une zone, ouvre un menu de vêtements ou démarre une ressource peuvent apparaître.

Reproduire le crash sur un serveur local ou de préproduction, avec le moins de ressources actives possible.
Désactiver les Fichiers streamés récents, puis les réactiver par moitiés jusqu'à ce que le crash réapparaisse.
Pour les véhicules, faire apparaître un modèle à la fois. Tester l'apparition, un court trajet, le streaming à distance et le redémarrage de la ressource.
Pour vérifier les textures, remplacer temporairement le .ytd par un dictionnaire fiable ou supprimer les textures facultatives afin de distinguer les problèmes de texture des problèmes de modèle.
Vérifier fxmanifest.lua, files, data_file, les chemins des dossiers stream et les références meta.
Observer quand le crash survient. À la connexion, cela indique une carte globale, des vêtements ou des ressources toujours chargées. À l'approche, cela indique une carte, un prop ou un MLO. À l'apparition, cela indique un véhicule. À l'ouverture d'un menu, cela indique du contenu ped ou des vêtements.

Un bon workflow Zoovdev

Passer les dictionnaires de textures dans Optimiser les textures et vérifier les dimensions, la compression, les mipmaps et l'utilisation de l'alpha.
Passer les fichiers de véhicules .yft dans Optimiser les véhicules sans importer de fichiers _hi.yft.
Utiliser Optimiser les props pour les modèles de props et Optimiser les vêtements pour les drawables de vêtements.
Utiliser Code Agent pour examiner les manifestes de ressources, les références de fichiers de données et les noms de Fichiers lorsqu'une ressource se comporte toujours mal.
Tester la ressource optimisée en jeu avant de la réintégrer dans un gros pack de production.