FiveM oversized assets : réduire les .ytd sans perte de qualité

Vous lancez votre serveur FiveM et la console se remplit d’avertissements comme celui-ci : « Asset … uses 76.0 MiB of physical memory. Oversized assets can and WILL lead to streaming issues (such as models not loading/rendering). » La plupart des owners l’ignorent, puisque le serveur tourne. Puis les joueurs signalent des routes qui virent à la bouillie floue, des bâtiments qui ne se chargent jamais, des voitures qui apparaissent en boîtes grises. C’est l’avertissement qui se réalise. Ce guide explique ce que le message signifie, à partir de quelle taille c’est trop, et comment réduire les texture dictionaries .ytd trop lourds sans abîmer vos maps et vos voitures.

Ce que signifie l’avertissement

Voici à quoi ressemble le message dans la console du serveur. Vos noms de resources seront différents :

Asset example_resource/example_props_txd.ytd uses 76.0 MiB of physical memory. Oversized assets can and WILL lead to streaming issues (such as models not loading/rendering).
Asset example_vehicle/example_vehicle+hi.ytd uses 24.0 MiB of physical memory.

Lisez-le de gauche à droite :

• example_resource est la resource qui streame le fichier, soit le dossier dans votre répertoire resources.
• example_props_txd.ytd est le fichier lui-même. Un .ytd est un texture dictionary : un lot d’images que le jeu plaque sur les modèles. Les fichiers +hi.ytd contiennent les textures haute définition d’un véhicule.
• 76.0 MiB of physical memory est la mémoire graphique (VRAM) que le fichier occupe une fois chargé. Ce n’est pas sa taille sur le disque, et c’est en général plus.

Le serveur affiche la ligne au démarrage d’une resource, vous êtes donc prévenu avant qu’un joueur ne voie quoi que ce soit. Le fichier est quand même streamé. FiveM vous signale seulement que chaque joueur qui s’en approche doit maintenant charger 76 MiB d’un bloc.

Pourquoi les oversized assets cassent le streaming

GTA V a été conçu pour streamer le monde par petits morceaux au fil de vos déplacements. Il garde un pool de mémoire limité pour ce qui vous entoure et ne cesse d’y échanger des éléments. Un seul texture dictionary de 76 MiB en occupe à lui seul une grosse part. Quand plusieurs se trouvent dans la même zone, le jeu manque de place et se met à lâcher des choses dont il a encore besoin. Les joueurs le voient ainsi :

• Perte de textures, aussi appelée city bug : routes, murs et sol passent en basse résolution ou deviennent flous, et le restent.
• Modèles qui ne se chargent pas ou ne s’affichent pas : bâtiments, props ou intérieurs qui n’apparaissent jamais, ou avec quelques secondes de retard.
• Voitures sans textures ou avec seulement leur modèle basse définition, surtout dans un garage ou un car meet bondé.
• Saccades et longs écrans de chargement, car les gros fichiers mettent plus de temps à être téléchargés, lus et envoyés à la carte graphique.

Les joueurs avec beaucoup de VRAM le remarquent plus tard que ceux qui ont une carte de 4 Go : le même serveur peut paraître correct à l’owner et cassé à la moitié des joueurs.

Physical memory et virtual memory

Chaque fichier streamé de GTA V est coupé en deux parties. La mémoire virtual contient la structure : noms, formats, liste des textures. La mémoire physical contient les données brutes des pixels qui partent vers la carte graphique. Pour un .ytd, presque tout le poids est en physical, et c’est ce chiffre que FiveM signale.

À partir de quelle taille est-ce trop ?

La cible habituelle, celle sur laquelle travaillent la plupart des développeurs FiveM, est de 16 MiB de physical memory par asset. En dessous, FiveM se tait. Au-delà, vous avez l’avertissement, et plus vous dépassez, plus les problèmes ci-dessus deviennent probables. 16 MiB n’est pas un mur, mais prenez-le comme budget pour chaque .ytd.

La taille d’une texture en mémoire ne dépend que de trois choses : sa résolution, son format et ses niveaux de mip. Le tableau montre une texture avec sa chaîne de mips complète :

size        DXT1       DXT5       A8R8G8B8 (uncompressed)
4096x4096   10.7 MiB   21.3 MiB   85.3 MiB
2048x2048    2.7 MiB    5.3 MiB   21.3 MiB
1024x1024    0.7 MiB    1.3 MiB    5.3 MiB
 512x512     0.2 MiB    0.3 MiB    1.3 MiB

Une seule texture 4096×4096 en DXT5 coûte donc déjà 21,3 MiB, plus que tout le budget. Un pack de map avec trois textures de ce genre, deux ou trois normal maps et quelques textures de finition tombe pile sur les 76 MiB de l’exemple. Une texture 4K non compressée est pire encore, à 85,3 MiB à elle seule. La plupart des oversized assets sont simplement des textures 4K dont personne n’avait besoin en 4K.

Trouver tous les assets trop lourds de votre serveur

La console n’affiche l’avertissement qu’au démarrage du serveur, noyé dans le reste, et il est facile d’en rater un. Il y a deux meilleures options.

1. Cherchez MiB of physical memory dans le log de la console. Chaque résultat nomme la resource et le fichier. Une recherche de Oversized assets rate les fichiers entre 16 et 48 MiB, dont la ligne s’arrête après la taille.
2. Laissez Asset Doctor s’en charger. Il lit chaque resource de votre serveur via la resource FiveDock et liste chaque texture dictionary de plus de 16 MiB, avec sa mémoire graphique à côté de sa taille sur disque.

example_resource  stream/example_props_txd.ytd
  this texture dictionary allocates 76.0 MiB of graphics memory (61.2 MiB on disk),
  more than the 16.0 MiB a pack should stay under

Asset Doctor signale aussi les modèles que deux packs streament en même temps et les resources qui ne démarrent jamais : un seul scan couvre donc les raisons habituelles pour lesquelles une map ou une voiture s’affiche mal. Si deux packs fournissent le même fichier de map, le guide des conflits de maps explique ce que cela casse.

Réduire les textures .ytd sans perdre en qualité

Chaque texture d’un .ytd est stockée plusieurs fois : en taille réelle, puis à moitié, au quart, au huitième, et ainsi de suite jusqu’à quelques pixels. Ces copies sont les niveaux de mip. Le jeu choisit celui qui correspond à la taille de la surface à l’écran. Un mur à 20 mètres reçoit un petit mip, et le niveau complet ne sert que quand vous collez le nez dessus.

Cela donne un moyen de réduire une texture sans toucher à ses pixels : retirer les plus grands niveaux de mip. Une texture 4096×4096 privée de ses deux premiers niveaux devient une texture 1024×1024 dont les pixels sont exactement ceux que le jeu affichait déjà à n’importe quelle distance normale. Rien n’est redimensionné, recompressé ni réencodé, donc aucun nouveau flou ni artefact de blocs n’apparaît. Chaque niveau retiré divise la mémoire par environ quatre.

Pensez à la taille réelle de l’écran. Sur un moniteur 1920×1080, même un mur qui remplit toute la vue n’affiche jamais plus de 2000 pixels environ en largeur : une texture 4K sur un lampadaire ou une portière, c’est de la mémoire dépensée pour un détail qu’aucun joueur ne voit.

La méthode manuelle, et son piège

Sans outil, la correction ressemble à ceci :

1. Ouvrez le .ytd dans OpenIV ou CodeWalker et exportez toutes les textures.
2. Redimensionnez les grosses dans un éditeur d’images.
3. Réenregistrez-les en DDS, en choisissant le bon format DXT et en générant de nouveaux mip maps.
4. Réimportez-les, enregistrez le .ytd et redémarrez.

Ça marche, mais l’enregistrement en DXT compresse l’image une seconde fois, et chaque passe ajoute des artefacts, surtout sur les normal maps et le texte. Sur un serveur avec quelques centaines de voitures et une douzaine de maps, c’est aussi des jours de travail.

Les réduire avec le Stream Optimizer

Le Stream Optimizer de l’application de bureau FiveDock applique l’astuce des niveaux de mip à tous les .ytd d’un dossier d’un coup. Il ramène les textures trop lourdes au plus grand niveau de mip qui tient dans votre limite et laisse le reste des données de pixels octet pour octet tel quel.

1. Ouvrez Optimiseur de stream dans l’application de bureau et choisissez une resource, ou tout votre dossier resources.
2. Choisissez un préréglage (voir plus bas) et un dossier pour les originaux.
3. Cliquez sur Analyser. Vous voyez chaque fichier qui serait modifié, chaque texture avec sa taille avant et après, et la mémoire de jeu économisée.
4. Cliquez sur Optimiser et redémarrez le serveur.

La même chose en ligne de commande, pour le fichier de l’avertissement ci-dessus :

> fivedock optimize C:\server\resources\example_resource
1 .ytd file under C:\server\resources\example_resource, textures over 1024px
  stream\example_props_txd.ytd  76.0 MiB -> 12.0 MiB
      example_wall_d  4096x4096 -> 1024x1024  DXT5
      example_wall_n  4096x4096 -> 1024x1024  DXT5
      example_floor_d  4096x4096 -> 1024x1024  DXT1
      example_floor_n  4096x4096 -> 1024x1024  DXT1
      example_trim_d  2048x2048 -> 1024x1024  DXT5
      kept example_sign_emis  2048x2048  emissive
Would free 64.0 MiB of game memory. Nothing was written; add --apply --backup <dir>.

Une analyse n’écrit rien. Ajoutez --apply --backup <dir> pour écrire les fichiers plus petits et garder les originaux dans ce dossier. Dans cet exemple, le fichier passe de 76,0 MiB à 12,0 MiB, sous le budget de 16 MiB, et l’avertissement a disparu au prochain démarrage.

Quel préréglage choisir

• Sûr ne redimensionne rien. Il corrige seulement les textures script_rt compressées, dont FiveM se plaint aussi.
• Léger garde les textures jusqu’à 2048 px. Idéal pour les assets vedettes que les joueurs regardent de près, comme un showroom ou une enseigne de menu.
• Équilibré garde les textures jusqu’à 1024 px. C’est le réglage par défaut, et le bon choix pour la plupart des maps, props et voitures.
• Performance garde les textures jusqu’à 512 px. Pour les props d’arrière-plan et les serveurs dont les joueurs ont des cartes graphiques plus anciennes.

Commencez par Équilibré, passez devant ce qui a changé, et montez en Léger pour les quelques assets où vous voyez une différence.

Ce qu’il ne touche jamais

• Les render targets (script_rt_* et scr_*) gardent leur taille, car des scripts dessinent dessus à une résolution exacte. Les compressées sont converties en textures non compressées de même taille, comme FiveM l’exige.
• Les textures émissives : les noms contenant emis, glow, neon ou finissant par _em gardent leur taille, car les motifs lumineux et les enseignes néon montrent chaque pixel perdu.
• Les textures déjà sous la limite et tout ce qui est dans un format inconnu restent exactement comme elles sont.

Baisser les lodDistances des voitures addon

Pour les véhicules, les textures ne font que la moitié du problème. Chaque voiture de vehicles.meta a une liste lodDistances : les distances, en mètres, auxquelles elle passe de son modèle haute définition à des modèles plus simples, la dernière valeur étant la distance maximale d’affichage. Beaucoup de voitures addon arrivent avec des valeurs bien supérieures à celles du jeu de base, si bien que chaque voiture d’une rue animée reste en détail complet, +hi.ytd compris, depuis des centaines de mètres.

<Item>
  <modelName>example_car</modelName>
  <lodDistances content="float_array">
    40.000000
    80.000000
    200.000000
    400.000000
    1000.000000
    1000.000000
  </lodDistances>
</Item>

Cochez Optimiser la distance LOD dans le Stream Optimizer, ou passez --lod en ligne de commande. Chaque valeur est abaissée à 15, 30, 70, 140, 250 et 250 mètres au plus, proche du jeu de base. Une valeur déjà plus basse n’est jamais relevée, et seuls les nombres du fichier changent.

> fivedock optimize C:\server\resources\example_vehicle --lod --no-textures
1 .meta file with lodDistances
  data\vehicles.meta  example_car  40 / 80 / 200 / 400 / 1000 / 1000 -> 15 / 30 / 70 / 140 / 250 / 250
Nothing was written; add --apply --backup <dir>.

Questions fréquentes

Un oversized asset peut-il faire planter mon serveur ?

Non. Le serveur ne fait qu’envoyer le fichier. Le coût est payé par le jeu de chaque joueur, sous forme de perte de textures, de modèles manquants et de crashs côté client, plus souvent sur les cartes avec peu de VRAM.

16 MiB, est-ce une limite stricte ?

Non, un fichier de 20 MiB se streame en général bien tout seul. Les ennuis viennent de nombreux fichiers trop lourds au même endroit. 16 MiB par .ytd est le budget qui vous met à l’abri sur n’importe quelle map, avec n’importe quel nombre de joueurs autour.

À partir de quelle taille FiveM prévient-il des oversized assets ?

FXServer vérifie chaque fichier streamé au démarrage de sa resource et affiche Asset <resource>/<file> uses <size> MiB of physical memory. pour tout fichier de plus de 16 MiB, en bleu au-dessus de 16 MiB, en jaune au-dessus de 32 MiB et en rouge au-dessus de 64 MiB. La phrase « Oversized assets can and WILL lead to streaming issues (such as models not loading/rendering). » n’est ajoutée qu’au-delà de 48 MiB. La même vérification porte sur la virtual memory d’un fichier, et la ligne se termine alors par of virtual memory.. Les seuils se trouvent dans le ResourceStreamComponent.cpp de FXServer.

Et si l’avertissement nomme un fichier .yft ou .ydr ?

Les textures sont alors intégrées au fichier du modèle. Le Stream Optimizer ne lit que les .ytd : déplacez d’abord les textures dans un .ytd séparé avec OpenIV ou CodeWalker, ou demandez une version plus légère à l’auteur.

Les joueurs doivent-ils faire quelque chose ?

Non. Après votre redémarrage, les fichiers modifiés ont un nouveau hash, et chaque joueur télécharge la version plus petite à sa prochaine connexion.

Dans quelle offre

Le Stream Optimizer est dans toutes les offres, dans l’application de bureau et le CLI. Tout tourne sur votre machine, et vos fichiers ne la quittent jamais. Asset Doctor fait partie de l’offre Metro et surveille votre serveur en production pour repérer les nouveaux oversized assets, afin que le prochain pack de voitures en 4K soit attrapé avant que vos joueurs ne le trouvent. Comparer les offres ou voir toutes les fonctionnalités.