Nomi e versioni

Convenzioni di nomi e controllo delle versioni per i file di stampa 3D

Di Petros, che sviluppa Meshory · Aggiornato il 10 ago 2026 · 9 min di lettura

Prima o poi ogni libreria di stampa 3D produce un file con un nome tipo dragon_v2_supported_final_FINAL.stl. È una battuta che tutti riconoscono, ma è anche un vero fallimento: il nome è l'unico posto in cui vivono le informazioni sulla versione, quindi cresce fino a diventare inutile. Questa guida spiega una convenzione di nomi che resta leggibile, come tenere traccia delle versioni senza un sistema di controllo versione e come rinominare una libreria che hai già senza trasformare ogni ridenominazione in un duplicato.

Nella stampa 3D i nomi dei file fanno troppo lavoro. Una sola stringa deve dire che modello è, quale variante, se ha i supporti, per quale stampante è stato preparato nello slicer e quanto è recente. Nient'altro nel flusso di lavoro registra queste informazioni, quindi finisce tutto nel nome, e il nome crolla sotto il peso.

Come crollano i nomi

Lo schema è sempre lo stesso. Un file nasce come dragon.stl. Esporti una versione con supporti, quindi ora c'è dragon_supported.stl. Il creator pubblica una correzione, che diventa dragon_v2.stl. La scali per una stampante più piccola e ottieni dragon_v2_small.stl. A un certo punto un file viene segnato come final, poi qualcosa cambia, e nasce final_FINAL.

Sono andate storte tre cose precise, e ognuna richiede una soluzione diversa:

• Si perde l'ordine. Niente in v2, final e FINAL ti dice quale è arrivato per ultimo. Lo dice solo la data di modifica del file, che però va persa quando copi i file da un disco all'altro.
• Varianti e versioni si mescolano. I suffissi «supported» e «small» sono varianti che convivono; v2 è una versione che sostituisce v1. Se metti entrambe le cose nella stessa stringa, non riesci a capire quali file sono alternative e quali sono obsoleti.
• Nulla conserva il contesto. Perché esiste v2, cosa non andava in v1 e quale hai stampato davvero con successo: tutto questo vive nella tua memoria, e solo per poco.

Una convenzione di nomi che regge nel tempo

Una buona convenzione è breve, si ordina correttamente e non va mai modificata a posteriori. Ci arrivi con quattro regole:

1. 1Inizia con il nome del modello, così come l'ha scritto il creator. È il tuo collegamento alla pagina del negozio e a eventuali istruzioni, e rende il file trovabile con il nome che usano anche gli altri.
2. 2Usa date ISO, non numeri di versione, quando ti serve un ordine: dragon_2026-03-14.stl si ordina correttamente in qualsiasi file manager al mondo e non richiede una legenda per essere interpretato. I numeri di versione funzionano solo se non perdi mai il conto, e prima o poi tutti lo perdono.
3. 3Metti le varianti in una posizione fissa e con un vocabolario fisso. Scegli supported o unsupported, scegli una sola parola per la scala e usale sempre nello stesso ordine. dragon_supported_75pct è leggibile; dragon_75_sup_fix no.
4. 4Non scrivere mai finale, nuovo, ultimo o corretto. Ognuna di queste parole è vera solo nel momento in cui la scrivi, e nel giro di una settimana diventa una bugia.

Applicata con coerenza, questa convenzione produce nomi come wyrm_supported_2026-03-14.stl. Si ordina cronologicamente, dice di che variante si tratta e avrà ancora senso fra due anni, che è l'unica vera prova.

Gestire le versioni senza un sistema di controllo versione

Per un modello stampato, quello che vuoi davvero ricordare non è la sequenza delle modifiche. È quale file è stato stampato con successo, su quale macchina, con quali impostazioni, e cosa è andato storto con quelli che hanno fallito. Questa è una nota, non una cronologia di commit.

È qui che il nome del file dovrebbe smettere di crescere e un livello separato dovrebbe prendere il suo posto. Tieni la versione riuscita con un nome stabile e registra il contesto in un posto dove si può cercare: cosa è fallito, per quale stampante era, per quale materiale è stato preparato nello slicer. Meshory conserva per ogni modello note e filamento assegnato accanto al modello stesso, e tag come stampato, fallito o servono-supporti trasformano lo stato in qualcosa con cui filtrare l'intera libreria, invece che in qualcosa codificato nel nome di un file.

Meglio essere chiari sul limite: i tag registrano che una versione è stata stampata, non le impostazioni con cui è stata stampata. Gli strumenti pensati per questo compito vanno oltre Meshory. GyroidVault tiene v1, v2 e final sotto un'unica voce di modello con un registro di stampa, e PrintStash collega ogni file prodotto dallo slicer al modello di origine, con le impostazioni dello slicer estratte dal file. Se ricostruire una stampa riuscita sei mesi dopo è l'unico motivo per cui stai leggendo, parti da lì.

La suddivisione generale, con le cartelle per la posizione, i tag per le proprietà e le raccolte per lo scopo, è descritta nel sistema a tre livelli. Lo stato della versione appartiene senza dubbio al livello dei tag.

Conviene usare Git per i file STL?

Per i tuoi progetti parametrici, a volte. Per una libreria di modelli scaricati, no. Git salva una copia completa di ogni versione di ogni file binario, quindi un repository con qualche centinaio di STL cresce senza limiti e ogni clone si porta dietro l'intera cronologia. Inoltre Git non sa mostrarti cosa è cambiato tra due versioni di una mesh, che è proprio la cosa in cui un sistema di controllo versione dovrebbe essere bravo.

C'è un caso limitato in cui funziona: i file sorgente dei progetti che crei tu, soprattutto in formati testuali come OpenSCAD, dove i diff hanno senso e i file sono piccoli. Se vuoi, tieni il sorgente in Git e tratta gli STL esportati come artefatti di build che vivono nella tua normale libreria.

Rinominare una libreria che hai già

È quando applichi una nuova convenzione a migliaia di file esistenti che i progetti di rinomina vanno storti, perché l'approccio più ovvio crea proprio il problema che doveva risolvere. Copi un file con il nuovo nome e cancelli l'originale più tardi, e per un po' li hai entrambi. Salti una cancellazione e hai un duplicato permanente che nessuna ricerca per nome collegherà mai al suo gemello.

1. 1Prima elimina i duplicati. Rinominare una libreria che contiene ancora copie significa rinominare più volte lo stesso modello, e nasconde le copie dietro nomi nuovi. Fai prima un controllo su contenuto e geometria con uno strumento di ricerca dei duplicati.
2. 2Rinomina sul posto, non copiare mai per poi cancellare. Una vera ridenominazione è atomica. Una copia è un secondo file che esiste finché non ti ricordi di rimuovere il primo.
3. 3Rinomina con uno strumento che conserva i tuoi metadati. Se tag, note e miniature sono legati al percorso, rinominare butta via tutto e devi ricostruire da zero.
4. 4Non toccare i file dei creator se non hai un motivo. I loro nomi sono il tuo collegamento alla fonte, e una convenzione personale raramente giustifica il fatto di perderlo.

Meshory rinomina il file o la cartella reale sul disco e aggiorna la voce della libreria nello stesso passaggio, quindi tag, note, raccolte e miniature restano tutti al loro posto, anche quando rinomini una cartella con tutto il suo contenuto. Controlla i nomi rispetto alle regole di ogni piattaforma con cui la tua libreria ha a che fare, così un nome che darebbe problemi su Windows o su una condivisione NAS viene rifiutato mentre scrivi, invece di scoprirlo dopo. Inoltre si rifiuta di sovrascrivere un file esistente, invece di sostituirlo senza avvisare. I dettagli sono in rinominare file e cartelle.

Cosa fare invece di rinominare

Prima di rinominare in massa, chiediti: cosa stai cercando di risolvere davvero? Di solito la risposta è che non trovi le cose e non capisci cosa sia un file. Rinominare è una soluzione indiretta a entrambi i problemi, e costosa.

Una ricerca su nomi, percorsi, tag e descrizioni risolve il problema di trovare le cose senza toccare un solo file. Le miniature generate risolvono l'identificazione meglio di qualsiasi nome file, perché vedi il modello e non una sua descrizione. Insieme fanno sparire gran parte della spinta a rinominare, e la convenzione di nomi diventa qualcosa che applichi ai nuovi file da qui in avanti, non un progetto da portare avanti su diecimila file vecchi. Il sistema completo in cui tutto questo si inserisce è la guida completa per organizzare una libreria STL.