Nombres y versiones

Convenciones de nombres y control de versiones para archivos de impresión 3D

Por Petros, que desarrolla Meshory · Actualizado el 10 ago 2026 · 9 min de lectura

Toda biblioteca de impresión 3D acaba produciendo un archivo con un nombre como dragon_v2_supported_final_FINAL.stl. Es un chiste que todos reconocen, y también un fallo real: el nombre es el único sitio donde vive la información de versión, así que crece hasta volverse inútil. Esta guía explica una convención de nombres que sigue siendo legible, cómo seguir las versiones sin un sistema de control de versiones y cómo renombrar la biblioteca que ya tienes sin que cada cambio de nombre se convierta en un duplicado.

En la impresión 3D, los nombres de archivo cargan con demasiado trabajo. Una sola cadena tiene que decir qué modelo es, qué variante es, si lleva soportes, para qué impresora se laminó y lo reciente que es. Nada más en el flujo de trabajo registra nada de eso, así que todo acaba en el nombre, y el nombre se hunde bajo ese peso.

Cómo se desmoronan los nombres

El patrón siempre es el mismo. Un archivo empieza como dragon.stl. Exportas una versión con soportes, así que ahora existe dragon_supported.stl. El creador publica una corrección, que se convierte en dragon_v2.stl. Lo escalas para una impresora más pequeña y obtienes dragon_v2_small.stl. En algún momento un archivo se marca como final, luego algo cambia y nace final_FINAL.

Han fallado tres cosas concretas, y cada una necesita una solución distinta:

• Se pierde el orden. Nada en v2, final y FINAL te dice cuál fue el último. Solo lo indica la fecha de modificación del archivo, y esa se pierde al copiar archivos entre unidades.
• Se mezclan variantes y versiones. Los sufijos “supported” y “small” son variantes que conviven; v2 es una versión que sustituye a v1. Si pones ambas cosas en la misma cadena, no puedes saber qué archivos son alternativas y cuáles están obsoletos.
• Nada guarda el contexto. Por qué existe v2, qué fallaba en v1 y cuál imprimiste de verdad con éxito solo viven en tu memoria, y por poco tiempo.

Una convención de nombres que aguanta

Una buena convención es corta, se ordena bien y nunca hay que corregirla a posteriori. Cuatro reglas te llevan hasta ahí:

1. 1Empieza por el nombre del modelo, tal como lo dejó el creador. Es tu vínculo con la página de la tienda y con cualquier instrucción, y permite encontrar el archivo por el nombre que usa el resto de la gente.
2. 2Usa fechas ISO, no números de versión, cuando necesites un orden: dragon_2026-03-14.stl se ordena bien en cualquier gestor de archivos del mundo y no necesita ninguna clave para interpretarse. Los números de versión solo funcionan si nunca pierdes la cuenta, y tarde o temprano todo el mundo la pierde.
3. 3Pon las variantes en una posición fija y con un vocabulario fijo. Elige supported o unsupported, elige una palabra para la escala y úsalas siempre en el mismo orden. dragon_supported_75pct se entiende; dragon_75_sup_fix, no.
4. 4Nunca escribas final, nuevo, último o corregido. Cada una de estas palabras solo es cierta en el momento en que la escribes, y en una semana se convierte en mentira.

Aplicada con constancia, esta convención produce nombres como wyrm_supported_2026-03-14.stl. Se ordenan cronológicamente, dicen qué variante son y seguirán teniendo sentido dentro de dos años, que es la única prueba real.

Versiones sin un sistema de control de versiones

En un modelo impreso, lo que de verdad quieres recordar no es la secuencia de cambios. Es qué archivo se imprimió bien, en qué máquina, con qué ajustes y qué falló en los que no salieron. Eso es una nota, no un historial de commits.

Aquí es donde el nombre de archivo debería dejar de crecer y una capa aparte debería tomar el relevo. Guarda la versión que funcionó con un nombre estable y anota el contexto en un lugar donde se pueda buscar: qué falló, para qué impresora era, para qué material se laminó. Meshory guarda notas y la asignación de filamento de cada modelo junto al propio modelo, y etiquetas como impreso, fallido o necesita-soportes convierten el estado en algo por lo que puedes filtrar toda la biblioteca, en vez de algo codificado en un nombre de archivo.

Conviene ser claros sobre el límite: las etiquetas registran que una versión se imprimió, no los ajustes con los que se imprimió. Las herramientas pensadas para esa tarea llegan más lejos que Meshory. GyroidVault guarda v1, v2 y final bajo una misma entrada de modelo con un registro de impresiones, y PrintStash vincula cada archivo laminado a su modelo de origen con los ajustes del laminador extraídos de él. Si reconstruir una impresión que salió bien seis meses después es el motivo por el que estás leyendo esto, empieza por ahí.

El reparto general, con las carpetas para la ubicación, las etiquetas para las propiedades y las colecciones para la intención, se explica en el sistema de tres capas. El estado de la versión pertenece claramente a la capa de etiquetas.

¿Deberías usar Git para archivos STL?

Para tus propios diseños paramétricos, a veces. Para una biblioteca de modelos descargados, no. Git guarda una copia completa de cada versión de cada archivo binario, así que un repositorio con unos cientos de STL crece sin límite y cada clon arrastra todo el historial. Git tampoco puede mostrarte qué cambió entre dos versiones de una malla, que es justo lo que se supone que un sistema de control de versiones hace bien.

Hay un caso concreto en el que funciona: los archivos fuente de diseños que creas tú mismo, sobre todo en formatos de texto como OpenSCAD, donde las diferencias entre versiones tienen sentido y los archivos son pequeños. Guarda el código fuente en Git si quieres y trata los STL exportados como artefactos de compilación que viven en tu biblioteca normal.

Renombrar la biblioteca que ya tienes

Aplicar una convención nueva a miles de archivos existentes es donde fallan los proyectos de renombrado, porque el método obvio crea justo el problema que pretendía resolver. Si copias un archivo con su nuevo nombre y borras el original más tarde, durante un tiempo tienes los dos. Si se te olvida un borrado, tienes un duplicado permanente que ninguna búsqueda por nombre relacionará nunca con su gemelo.

1. 1Elimina duplicados primero. Renombrar una biblioteca que aún contiene copias significa renombrar el mismo modelo varias veces, y esconde las copias tras nombres nuevos. Haz antes una pasada por contenido y geometría con un buscador de duplicados.
2. 2Renombra en el sitio, nunca copies y luego borres. Un renombrado de verdad es atómico. Una copia es un segundo archivo que existe hasta que te acuerdas de eliminar el primero.
3. 3Renombra con una herramienta que conserve tus metadatos. Si las etiquetas, las notas y las miniaturas dependen de la ruta, renombrar lo tira todo y tienes que reconstruirlo desde cero.
4. 4No toques los archivos de los creadores salvo que tengas un motivo. Sus nombres son tu vínculo con el origen, y una convención personal rara vez justifica perderlo.

Meshory renombra el archivo o la carpeta real en el disco y actualiza la entrada de la biblioteca en el mismo paso, así que etiquetas, notas, colecciones y miniaturas se conservan, también cuando renombras una carpeta y todo lo que contiene. Valida los nombres según las reglas de todas las plataformas que toca tu biblioteca, de modo que un nombre que fallaría en Windows o en una carpeta compartida de un NAS se rechaza mientras escribes, en lugar de descubrirlo más tarde. Además, se niega a sobrescribir un archivo existente en vez de reemplazarlo sin avisar. Los detalles están en renombrar archivos y carpetas.

Qué hacer en lugar de renombrar

Antes de renombrar en masa, vale la pena preguntarse: ¿qué intentas arreglar en realidad? Normalmente la respuesta es que no encuentras las cosas y no sabes qué es cada archivo. Renombrar es una solución indirecta para ambas cosas, y además cara.

Buscar en nombres, rutas, etiquetas y descripciones resuelve el problema de encontrar las cosas sin tocar ni un archivo. Las miniaturas generadas identifican mejor que cualquier nombre de archivo, porque ves el modelo y no una descripción de él. Entre las dos, desaparece casi toda la presión por renombrar, y la convención de nombres pasa a ser algo que aplicas a los archivos nuevos de aquí en adelante, no un proyecto que ejecutas sobre diez mil archivos antiguos. El sistema completo en el que encaja todo esto está en la guía completa para organizar una biblioteca STL.