Nomes e versões

Convenções de nomes e controle de versão para arquivos de impressão 3D

Por Petros, que desenvolve o Meshory · Atualizado em 10 de ago. de 2026 · 9 min de leitura

Toda biblioteca de impressão 3D acaba produzindo um arquivo com um nome como dragon_v2_supported_final_FINAL.stl. É uma piada que todo mundo reconhece, e também é uma falha real: o nome é o único lugar onde a informação de versão fica, então ele cresce até se tornar inútil. Este guia apresenta uma convenção de nomes que continua legível, como acompanhar versões sem um sistema de controle de versão e como renomear a biblioteca que você já tem sem transformar cada renomeação em uma duplicata.

Na impressão 3D, os nomes de arquivo fazem trabalho demais. Um único texto precisa dizer que modelo é, qual variante é, se tem suportes, para qual impressora foi fatiado e quão recente é. Nada mais no fluxo de trabalho registra nada disso, então tudo acaba no nome, e o nome desaba sob o peso.

Como os nomes desmoronam

O padrão é sempre o mesmo. Um arquivo começa como dragon.stl. Você exporta uma versão com suportes, e agora existe dragon_supported.stl. O criador publica uma correção, que vira dragon_v2.stl. Você reduz a escala para uma impressora menor e obtém dragon_v2_small.stl. Em algum momento, um arquivo é marcado como final, depois algo muda, e nasce o final_FINAL.

Três coisas específicas deram errado, e cada uma pede uma correção diferente:

• A ordem se perde. Nada em v2, final e FINAL diz qual veio por último. Só a data de modificação do arquivo diz, e ela é destruída quando você copia arquivos entre unidades.
• Variantes e versões se misturam. Supported e small são variantes que coexistem; v2 é uma versão que substitui a v1. Colocar as duas coisas no mesmo nome significa que você não consegue distinguir quais arquivos são alternativas e quais estão obsoletos.
• Nada guarda o contexto. Por que a v2 existe, o que havia de errado com a v1 e qual delas você realmente imprimiu com sucesso: tudo isso fica na sua memória, e só por pouco tempo.

Uma convenção de nomes que resiste ao tempo

Uma boa convenção é curta, fica na ordem certa e nunca precisa ser editada depois. Quatro regras levam você até lá:

1. 1Comece pelo nome do modelo, sem mudar o que o criador escolheu. Ele é o seu vínculo com a página da loja e com quaisquer instruções, e permite encontrar o arquivo pelo nome que outras pessoas usam para ele.
2. 2Use datas ISO, não números de versão, quando precisar de ordem: dragon_2026-03-14.stl fica na ordem certa em qualquer gerenciador de arquivos do planeta e não precisa de legenda para ser interpretado. Números de versão só funcionam se você nunca perder a conta, e todo mundo acaba perdendo a conta.
3. 3Coloque as variantes em uma posição fixa, com um vocabulário fixo. Escolha supported ou unsupported, escolha uma palavra para a escala e use-as sempre na mesma ordem. dragon_supported_75pct é legível; dragon_75_sup_fix não é.
4. 4Nunca escreva final, novo, último ou corrigido. Cada uma dessas palavras só é verdadeira no momento em que você a digita, e cada uma vira mentira em menos de uma semana.

Aplicada com consistência, essa convenção produz nomes como wyrm_supported_2026-03-14.stl. O nome fica em ordem cronológica, diz qual é a variante e ainda vai fazer sentido daqui a dois anos, que é o único teste que importa.

Versionamento sem um sistema de controle de versão

Para um modelo impresso, o que você realmente quer lembrar não é a sequência de edições. É qual arquivo imprimiu com sucesso, em qual máquina, com quais configurações, e o que deu errado com os que não deram certo. Isso é uma nota, não um histórico de commits.

É aqui que o nome do arquivo deve parar de crescer e uma camada separada deve assumir. Mantenha a versão bem-sucedida com um nome estável e registre o contexto em algum lugar pesquisável: o que falhou, para qual impressora era, para qual material foi fatiado. O Meshory guarda notas e a atribuição de filamento de cada modelo junto com ele, e tags como impresso, falhou ou precisa-de-suportes transformam o status em algo pelo qual você pode filtrar a biblioteca inteira, em vez de algo codificado em um nome de arquivo.

Vale ser direto sobre o limite aqui: as tags registram que uma versão foi impressa, não as configurações usadas na impressão. Ferramentas criadas para essa tarefa vão além do Meshory. O GyroidVault mantém v1, v2 e final em uma única entrada de modelo com um registro de impressões, e o PrintStash associa cada arquivo fatiado ao modelo de origem, com as configurações do fatiador extraídas dele. Se reconstruir uma impressão bem-sucedida seis meses depois é o único motivo de você estar lendo isto, comece por lá.

A divisão geral, com as pastas guardando a localização, as tags guardando as propriedades e as coleções guardando a intenção, está descrita no sistema de três camadas. O status da versão pertence claramente à camada de tags.

Vale a pena usar o Git para arquivos STL?

Para os seus próprios projetos paramétricos, às vezes. Para uma biblioteca de modelos baixados, não. O Git armazena uma cópia completa de cada versão de cada arquivo binário, então um repositório com algumas centenas de STLs cresce sem limite e cada clone carrega o histórico inteiro. O Git também não consegue mostrar o que mudou entre duas versões de uma malha, que é justamente a única coisa em que um sistema de controle de versão deveria ser bom.

Existe um caso específico em que funciona: arquivos-fonte de projetos que você mesmo cria, principalmente em formatos baseados em texto como o OpenSCAD, em que os diffs fazem sentido e os arquivos são pequenos. Mantenha o código-fonte no Git se quiser e trate os STLs exportados como artefatos de build que ficam na sua biblioteca normal.

Como renomear a biblioteca que você já tem

Aplicar uma nova convenção a milhares de arquivos existentes é onde os projetos de renomeação dão errado, porque a abordagem óbvia cria exatamente o problema que deveria resolver. Copie um arquivo com o novo nome, apague o original depois, e durante um tempo você terá os dois. Esqueça uma exclusão e você terá uma duplicata permanente que nenhuma busca por nome de arquivo jamais vai ligar à sua gêmea.

1. 1Elimine as duplicatas primeiro. Renomear uma biblioteca que ainda tem cópias significa renomear o mesmo modelo várias vezes, e isso esconde as cópias atrás de nomes novos. Faça antes uma varredura por conteúdo e geometria com um localizador de duplicatas.
2. 2Renomeie no lugar, nunca copie e depois apague. Uma renomeação de verdade é atômica. Uma cópia é um segundo arquivo que existe até você lembrar de remover o primeiro.
3. 3Renomeie com uma ferramenta que preserve seus metadados. Se tags, notas e miniaturas estão ligadas ao caminho, renomear joga tudo isso fora e você recomeça do zero.
4. 4Deixe os arquivos dos criadores como estão, a menos que tenha um motivo. Os nomes deles são o seu vínculo com a origem, e uma convenção pessoal raramente justifica perder isso.

O Meshory renomeia o arquivo ou a pasta real no disco e atualiza a entrada da biblioteca na mesma etapa, então tags, notas, coleções e miniaturas são mantidas, inclusive quando você renomeia uma pasta e tudo o que há dentro dela. Ele valida os nomes segundo as regras de cada plataforma que a sua biblioteca usa, então um nome que quebraria no Windows ou em um compartilhamento de NAS é recusado enquanto você digita, em vez de ser descoberto depois. Ele também se recusa a sobrescrever um arquivo existente, em vez de substituí-lo sem avisar. Os detalhes estão em renomear arquivos e pastas.

O que fazer em vez de renomear

Vale perguntar antes de uma renomeação em massa: o que você está realmente tentando resolver? Normalmente a resposta é que você não encontra as coisas e não sabe dizer o que um arquivo é. Renomear é uma solução indireta para os dois problemas, e cara.

A busca por nomes, caminhos, tags e descrições resolve o problema de encontrar as coisas sem tocar em um único arquivo. Miniaturas renderizadas resolvem a identificação melhor do que qualquer nome de arquivo, porque você vê o modelo, e não uma descrição dele. Juntas, elas eliminam a maior parte da pressão para renomear, e a convenção de nomes vira algo que você aplica aos arquivos novos daqui para frente, e não um projeto que você executa em dez mil arquivos antigos. O sistema completo do qual isso faz parte está no guia completo para organizar uma biblioteca de STL.