Importaciones de assets reproducibles: conservar identidad, configuración y versiones de herramientas

Definir qué debe reproducirse

Un pipeline de assets transforma los archivos creados por los autores en recursos de ejecución. Para que sea reproducible hay que conocer tanto la entrada como la transformación. Dos desarrolladores pueden tener exactamente los mismos bytes de imagen y, aun así, obtener texturas distintas en tiempo de ejecución por usar ajustes de importación diferentes. Hay que decidir si el proyecto exige bytes de salida idénticos, propiedades de recurso equivalentes o un resultado visual acordado; son criterios de aceptación distintos.

Conservar la identidad de las referencias

Los metadatos de assets de Unity guardan un identificador único y los ajustes de importación en el archivo .meta que acompaña al asset. Mover un asset fuera del Editor exige llevar ese archivo con él; si se pierden los metadatos, las referencias pueden romperse. [1] Conviene tratar el movimiento de un asset como una operación que debe preservar la identidad y revisar los cambios en los metadatos junto con los cambios en los archivos fuente. El nombre de archivo no sustituye al identificador que usan las referencias serializadas.

Separar la configuración de la cache

Godot escribe la configuración de importación de cada asset junto a los archivos fuente, en archivos .import, y recomienda hacer commit de esa configuración. Los recursos importados generados se almacenan en .godot/imported/ y pueden regenerarse. [2] Su guía de control de versiones para Godot 4.1 y posteriores excluye los datos de cache de .godot/. Las versiones anteriores tienen exclusiones distintas, así que hay que seguir la guía que corresponda a la versión del proyecto. [3]

Hay que mantener junto a la fuente de verdad los ajustes de proyecto necesarios, los scripts de importación y las versiones de las dependencias. Los overrides por plataforma de destino deben registrarse con el mismo cuidado que los ajustes por defecto. Y no conviene tratar la cache de trabajo de un desarrollador como la única copia que se conserva de una entrada necesaria.

Un ejemplo de comprobación con importación limpia

Supongamos una textura fuente de un muro de piedra que se usa tanto para inspección de cerca como para el paisaje lejano. Una máquina la importa con mipmaps y un formato de compresión concreto; otra desactiva los mipmaps. El checksum de la imagen fuente sigue coincidiendo, pero el comportamiento del muestreo en tiempo de ejecución es distinto.

Para una ejecución de verificación propuesta, se parte de un checkout limpio, se obtiene el contenido real de los archivos grandes cuando corresponda y se usan las versiones fijadas del motor y del importador. Se regeneran los datos derivados y después se inspeccionan dimensiones, número de mips, formato y referencias de material de este fixture. Se abre una escena pequeña que use el muro a varias distancias. Se comparan las propiedades de aceptación acordadas y se registran las diferencias. Esto es un ejemplo de flujo de trabajo, no la afirmación de que se haya ejecutado una importación.

Hacer que los cambios sean explicables

Al actualizar herramientas, conviene reconstruir texturas, mallas y audio representativos antes de reconstruirlo todo. Los hashes de las fuentes, las versiones de las herramientas y los cambios en los ajustes de importación deben quedar en el registro de compilación. Si cambian los bytes de salida mientras las propiedades previstas del recurso siguen estables, hay que investigar antes de decidir si la diferencia es aceptable.

Hay que probar también el cambio de nombre y el movimiento del fixture, además de su edición. Una textura reproducible que pierde todas sus referencias de material sigue indicando un pipeline roto. La política de cache, la preservación de la identidad y las comprobaciones de la salida deben revisarse como responsabilidades separadas.

Fuentes

[1] Asset metadata — Unity Technologies.

[2] Godot import process — Godot Engine contributors.

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