Imports d'assets reproductibles : préserver l'identité, les réglages et les versions d'outils

Définir ce qui doit être reproductible

Un pipeline d'assets transforme des fichiers sources en ressources utilisées à l'exécution. Pour qu'il soit reproductible, il faut connaître à la fois l'entrée et la transformation. Deux développeurs peuvent disposer d'images identiques octet pour octet et obtenir pourtant des textures d'exécution différentes, à cause de réglages d'import différents. Il faut décider si le projet exige des octets de sortie identiques, des propriétés de ressource équivalentes ou un résultat visuel convenu : ce sont des critères d'acceptation distincts.

Préserver l'identité des références

Les métadonnées d'asset d'Unity stockent un identifiant unique et les réglages d'import dans le fichier .meta associé. Déplacer un asset en dehors de l'Editor impose de conserver ce fichier avec lui ; perdre les métadonnées peut casser des références. [1] Traitez un déplacement d'asset comme une opération qui doit préserver l'identité, et relisez les modifications de métadonnées en même temps que celles des sources. Un nom de fichier ne remplace pas l'identifiant qu'utilisent les références sérialisées.

Séparer la configuration du cache

Godot écrit la configuration d'import de chaque asset dans des fichiers .import placés à côté des fichiers sources, et recommande de commiter cette configuration. Les imports générés se trouvent sous .godot/imported/ et peuvent être régénérés. [2] Ses recommandations de gestion de versions pour Godot 4.1 et versions ultérieures excluent les données de cache de .godot/. Les versions plus anciennes ont d'autres exclusions : appliquez donc les recommandations correspondant à la version du projet. [3]

Conservez avec la source de référence les paramètres de projet nécessaires, les scripts d'import et les versions des dépendances. Documentez les surcharges propres à une plateforme cible avec autant de soin que les réglages par défaut. Ne considérez pas le cache de travail d'un développeur comme la seule copie restante d'une entrée indispensable.

Appliquer une vérification d'import depuis zéro

Prenons une texture source de mur en pierre, utilisée à la fois pour l'inspection de près et pour le décor lointain. Une machine l'importe avec des mipmaps et un format de compression donné ; une autre désactive les mipmaps. La somme de contrôle de l'image source est identique, mais le comportement d'échantillonnage à l'exécution diffère.

Pour une vérification proposée, partez d'un checkout propre, récupérez le contenu réel des fichiers volumineux le cas échéant, et utilisez les versions figées du moteur et de l'importeur. Régénérez les données dérivées, puis examinez pour cet exemple les dimensions, le nombre de niveaux de mipmap, le format et les références de matériaux. Ouvrez une petite scène qui utilise le mur à plusieurs distances. Comparez les propriétés d'acceptation convenues et consignez les écarts. Il s'agit d'un exemple de workflow, et non de l'affirmation qu'un import a été exécuté.

Rendre les changements explicables

Lors d'une mise à niveau des outils, reconstruisez d'abord un échantillon représentatif de textures, de maillages et de sons avant de tout reconstruire. Conservez dans l'historique de build les hachages des sources, les versions des outils et les modifications des réglages d'import. Si les octets de sortie changent alors que les propriétés visées de la ressource restent stables, cherchez la cause avant de décider si l'écart est acceptable.

Testez aussi le renommage et le déplacement de l'exemple, pas seulement sa modification. Une texture reproductible qui perd toutes ses références de matériaux reste le signe d'un pipeline défaillant. Examinez la politique de cache, la préservation de l'identité et les contrôles de sortie comme des responsabilités distinctes.

Sources

[1] Asset metadata — Unity Technologies.

[2] Godot import process — Godot Engine contributors.

[3] Godot version control systems — Godot Engine contributors.