Importações de assets reproduzíveis: preserve identidade, configurações e versões das ferramentas

Defina o que deve ser reproduzido

Um pipeline de assets transforma arquivos criados pela equipe em recursos de runtime. Para ser reproduzível, é preciso conhecer tanto a entrada quanto a transformação. Dois desenvolvedores podem ter bytes de imagem idênticos e, ainda assim, obter texturas de runtime diferentes por causa de configurações de importação distintas. Decida se o projeto exige bytes de saída idênticos, propriedades de recurso equivalentes ou um resultado visual acordado; são critérios de aceitação diferentes.

Preserve a identidade das referências

O Unity guarda um identificador único e as configurações de importação no arquivo .meta que acompanha cada asset. Ao mover um asset fora do Editor, é necessário levar esse arquivo junto; perder os metadados pode quebrar referências. [1] Trate a movimentação de um asset como uma operação que deve preservar a identidade e revise as mudanças nos metadados junto com as mudanças nos arquivos de origem. O nome do arquivo não substitui o identificador usado pelas referências serializadas.

Separe a configuração do cache

O Godot grava a configuração de importação de cada asset em arquivos .import, ao lado dos arquivos de origem, e recomenda fazer commit dessa configuração. Os recursos importados gerados ficam em .godot/imported/ e podem ser regenerados. [2] A orientação de controle de versão para o Godot 4.1 e posteriores exclui os dados de cache de .godot/. Versões mais antigas têm exclusões diferentes, então use a orientação que corresponde à versão do projeto. [3]

Mantenha as configurações de projeto necessárias, os scripts de importação e as versões das dependências junto da fonte de verdade. Registre as substituições específicas de plataforma de destino com o mesmo cuidado que as configurações padrão. Evite tratar o cache funcional de um desenvolvedor como a única cópia restante de uma entrada necessária.

Faça uma verificação de importação limpa

Imagine uma textura de origem de uma parede de pedra usada tanto para inspeção de perto quanto para cenário distante. Uma máquina a importa com mipmaps e um formato de compressão selecionado; outra desativa os mipmaps. O checksum da imagem de origem continua igual, mas o comportamento de amostragem em runtime é diferente.

Para uma execução de verificação proposta, comece com um checkout limpo, obtenha o conteúdo real dos arquivos grandes, quando aplicável, e use as versões fixadas do engine e do importador. Regenere os dados derivados e depois inspecione dimensões, quantidade de mips, formato e referências de material para esse fixture. Abra uma cena pequena que use a parede em várias distâncias. Compare as propriedades de aceitação combinadas e registre as diferenças. Este é um exemplo de fluxo de trabalho, não a afirmação de que uma importação foi executada.

Torne as mudanças explicáveis

Ao atualizar ferramentas, reconstrua primeiro texturas, malhas e áudios representativos, antes de reconstruir tudo. Mantenha no registro de build os hashes das origens, as versões das ferramentas e as mudanças nas configurações de importação. Se os bytes de saída mudarem enquanto as propriedades pretendidas do recurso permanecem estáveis, investigue antes de decidir se a diferença é aceitável.

Teste renomear e mover o fixture, além de editá-lo. Uma textura reproduzível que perde todas as referências de material continua sendo um pipeline quebrado. Revise a política de cache, a preservação da identidade e as verificações de saída como responsabilidades separadas.

Fontes

[1] Asset metadata — Unity Technologies.

[2] Godot import process — Godot Engine contributors.

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