Aller au contenu

Ce qu'une resource coûte vraiment à un joueur

Une resource de 40 Mo peut coûter plus de mémoire à un joueur qu'une de 300 Mo. La taille sur disque est compressée ; la carte graphique garde la forme décompressée. Voici le chiffre qui compte vraiment, là où ça déraille, et ce qu'un optimiseur peut modifier sans risque.

Le chiffre qui compte n’est pas la taille du fichier

Un .ytd est compressé sur le disque. Ce que garde la carte graphique d'un joueur, c'est la texture décompressée, et ce chiffre dépend de trois choses : les dimensions, le format, et la présence de mips.

Une texture non compressée coûte environ huit fois ce que coûtent les mêmes pixels en BC1. Ce seul fait est le plus gros gain dans la plupart des uploads, et il ne change rien à l'apparence de la texture à l'écran. Les mips ajoutent environ un tiers en plus, et ils valent chaque octet : une texture sans mips est lue en pleine résolution depuis l'autre bout de la map.

C'est pour ça que l'analyse indique la mémoire, pas les mégaoctets. Deux resources de même taille de téléchargement peuvent coûter plusieurs fois plus l'une que l'autre à un joueur.

Ce qu’il modifie, et dans quel ordre

Chaque texture de l'upload est lue à partir du fichier lui-même et passe par les mêmes quatre questions. L'ordre est voulu.

Le plancher d'abord. Tout ce qui fait 256 pixels ou moins sur son grand côté est laissé tel quel, quel que soit son format : recompresser une petite texture l'abîme visiblement et ne fait presque rien gagner. Puis la compression : une texture non compressée passe en BC1, ou en BC3 si elle utilise vraiment l'alpha. Puis le plafond : tout ce qui dépasse le plafond que vous fixez y est ramené, arrondi à une puissance de deux. Puis rien d'autre : si une texture est déjà dans le budget, elle est signalée et laissée telle quelle.

1Plancherpetite ? on n'y touche pas2Formatsinon, on compresse3Plafondtrop grande ? on réduit4Rapportavant/après, par fichier
Plafonds proposés : 4096, 2048, 1024, 512, 256. Planchers : 512, 256, 128, désactivé.

Textures inutilisées et en double

L'analyse lit chaque modèle du package et collecte les textures que nomment ses shaders, toutes, pas seulement le diffuse. Une texture utilisée seulement comme normal map ou specular map est bien utilisée, et la supprimer aplatirait le modèle en jeu.

Tout ce qu'aucun shader ne nomme est signalé comme inutilisé, et vous pouvez le faire supprimer. Cette vérification ne s'exécute que si le package contient réellement un modèle : si vous avez importé des fichiers .ytd seuls, rien ne peut être déclaré inutilisé, car le shader qui lit la texture peut se trouver dans un fichier qu'on ne vous a jamais donné. Les textures identiques stockées sous des noms différents sont signalées à part : les doublons sont fréquents dans les packs assemblés à partir de plusieurs sources.

La seule modification désactivée par défaut

Une texture dont les côtés ne sont pas des puissances de deux ne peut pas porter une chaîne de mips complète. Le jeu lit le niveau le plus haut à toutes les distances : elle scintille de loin et coûte la mémoire pleine en permanence. La rendre carrée corrige les deux.

Elle reste pourtant désactivée par défaut, car la corriger signifie redimensionner une texture que vous n'avez pas demandé à réduire, exactement la façon dont un optimiseur ruine un decal. Elle est signalée à chaque analyse et appliquée seulement si vous la cochez.

Même raison pour laquelle les modèles ne sont jamais touchés. L'optimiseur réécrit les textures ; générer les niveaux de détail qu'un modèle n'avait pas est une étape séparée et optionnelle, qui passe par la file d'attente des jobs car elle prend quelques minutes sur une voiture.

Essayez gratuitement

Créez un compte gratuit, rejoignez le Discord pour vos crédits et créez votre premier asset en quelques minutes.