Etiquetar y organizar modelos automáticamente

El etiquetado y la organización automáticos llegan hasta los hechos que un archivo ya lleva encima, y ahí se paran: no saben para qué sirve el modelo. Una biblioteca lee los ajustes del slicer en cada archivo de G-code, crea los perfiles de impresora y de filamento que esos ajustes nombran, convierte un árbol de carpetas indexado en un árbol de colecciones y reconoce un archivo cuyos bytes ya tiene. Lo que no va a deducir es el significado: que un soporte necesita apoyos, o que un modelo era un regalo.

La línea que separa las dos mitades es si el dato ya existe en algún sitio: dentro del G-code que escribió tu slicer, en los nombres de las carpetas donde están los archivos, o en los propios bytes. Donde existe, una biblioteca puede leerlo y rellenar el campo. Donde no, alguien tiene que decidirlo, y ningún parser va a decidir en su lugar. Saber a qué lado cae cada cosa te ahorra los dos errores caros: etiquetar a mano campos que el parser ya rellenó, y esperar una categorización automática que nunca va a llegar.

Qué se rellena al ingresar el archivo

Los slicers escriben sus ajustes dentro del archivo. PrintStash los analiza al subirlo, así que un archivo de G-code o BGCODE llega con el nombre del slicer, el perfil de impresora y la boquilla, la altura de capa, el número de perímetros, el relleno, los soportes, el material, las temperaturas del hotend y de la cama, el tiempo estimado de impresión y el filamento estimado, según cuáles de esos haya registrado el slicer. La salida de OrcaSlicer, PrusaSlicer, Bambu Studio y Cura se analiza en todos los casos, pero no con la misma profundidad: Cura guarda la mayoría de sus ajustes en un bloque codificado que el parser no lee, así que un archivo de Cura llega con un puñado de campos donde uno de Orca llega con casi todos.

Dos efectos secundarios de ese análisis se pasan por alto con facilidad. Se crea un perfil de filamento a partir del material que nombra el archivo, y un perfil de impresora a partir del preset de la máquina, así que Ender-3 V3 SE 0.4 nozzle se convierte en un perfil con el modelo y el diámetro de boquilla rellenos la primera vez que un archivo lo menciona. Cuando el slicer escribió tanto un coste total de filamento como un peso de filamento, el coste por kilogramo se deduce de ambos y se guarda en el perfil de filamento. Ninguna de las dos cosas la pediste, y las dos significan que los desplegables ya están poblados cuando vas a buscarlos.

El otro paso automático es la identidad. Cada archivo se hashea al entrar, y unos bytes idénticos resuelven a la entrada que ya los tiene en lugar de arrancar una segunda. Eso es lo que hace que volver a descargar el mismo STL con otro nombre aterrice en el sitio correcto, y es la base de la detección de duplicados más adelante. Encontrar archivos STL duplicados entra en qué hacer con los resultados.

Qué estructura sale de donde ya están los archivos

La mayoría de las bibliotecas ya llevan organización en los nombres de sus carpetas, e importarlas es la estructura más barata que vas a conseguir.

Un volumen compartido apunta a una carpeta local o de un NAS y la indexa en su sitio. En modo espejo el árbol de directorios se convierte en el árbol de colecciones, así que props/helmets/mando.stl aterriza bajo props, luego helmets, con el archivo justo donde estaba. El modo de colección única lo deja todo en una sola colección, que es la opción correcta cuando el árbol existente es estructura accidental de descargas y no una decisión que alguien tomara. La guía de volúmenes compartidos cubre la programación de escaneos y qué pasa cuando el montaje desaparece.

Las subidas de ZIP se comportan igual. El archivo comprimido se convierte en una colección con su nombre, anidada bajo el padre que elijas, y las carpetas de dentro se convierten en subcolecciones. Para los packs de varias piezas que salen de las webs de modelos, con eso suele haber estructura suficiente.

Qué etiquetas siguen teniendo que escribirse a mano

Nada deduce etiquetas, ni de los nombres de archivo, ni de la geometría, ni de la descripción de la web desde la que descargaste el modelo. Las etiquetas vienen de quien subió el archivo, o de una edición masiva posterior. Una importación desde una web de modelos tampoco se trae la descripción de la ficha, y los archivos indexados desde una carpeta de un NAS llegan sin ninguna etiqueta.

Esto es menos hueco de lo que suena, porque las etiquetas útiles son precisamente las que ningún parser podría producir. needs-supports, calibration, gift, print-in-place, resin-only: cada una es un juicio sobre qué vas a hacer con el modelo. El material, la altura de capa, la boquilla y la impresora ya son campos estructurados, así que volver a etiquetarlos te deja dos fuentes de verdad que se contradicen en cuanto vuelvas a laminar. Mantén la lista lo bastante corta para acordarte de la ortografía, porque print-in-place y print_in_place son dos filtros y una sola intención. Colecciones y etiquetas tiene más sobre cómo diseñar ese vocabulario.

Poner a trabajar los campos analizados

Los filtros son donde la mitad automática rinde. Una biblioteca filtrada por tipo de artefacto, material, slicer, modelo de impresora, estado de revisión, resultado de impresión, ubicación de almacenamiento o fecha de subida responde a casi todas las preguntas para las que la gente recurre a las etiquetas. Guarda las combinaciones que repites como vistas, para que “piezas de PETG que salieron limpias en la máquina de 0.6” sea un clic y no una consulta que reconstruyes cada vez.

Para una biblioteca anterior a todo esto, la adaptación es mecánica. Deja que termine el primer escaneo para que cada archivo esté hasheado y analizado. Filtra por algo que el parser conozca, como un material o un slicer, y edita en masa los resultados, hasta 500 modelos a la vez, para asignar la colección o añadir una etiqueta a todo el grupo. Repite hasta que los filtros dejen de encontrar grupos coherentes, y ahí párate. Pasado ese punto estás inventando categorías en lugar de registrarlas, y la siguiente persona tampoco puede predecirlas.

Un archivo grande que ya existe tiene sus propios modos de fallo, casi todos alrededor del primer escaneo. Organizar miles de archivos STL es la versión larga de esa migración.

Qué esperar al cabo de una semana

El resultado realista es una biblioteca donde la búsqueda estructurada funciona y la lista de etiquetas no llega a veinte entradas. Los modelos llegan con sus ajustes puestos, las colecciones coinciden con un árbol que alguien ya había pensado, y el trabajo manual son unos segundos de etiquetado cuando algo necesita de verdad una etiqueta.

El resultado poco realista, que vale la pena nombrar porque hay quien lo planifica, es una biblioteca que se ordena por significado: que sabe que esto es una pieza de una Voron y aquello un juguete. Nada de esto hace eso, y las herramientas que lo prometen están adivinando a partir de los nombres de archivo.

Preguntas que surgen

¿Puede una biblioteca de modelos 3D etiquetarse y organizarse sola?

En parte, y la línea entre las dos mitades es nítida. La mitad de organizar y los hechos físicos llegan solos, porque el slicer escribió sus ajustes dentro del archivo y el árbol de carpetas ya codifica una jerarquía, y una biblioteca puede leer las dos cosas al entrar. Las etiquetas que describen para qué sirve un modelo no llegan en absoluto, ya que ese juicio existe solo en tu cabeza hasta que lo escribes. Si llevas una biblioteca así, acabas con un juego completo de campos estructurados por los que filtrar, más una lista de etiquetas de una docena de entradas escritas una vez.

¿Hay algo que etiquete modelos con IA, o a partir de la geometría o de la página de descarga?

No. PrintStash lee lo que el slicer incrustó en el archivo y no mira ni la malla ni la ficha desde la que descargaste el modelo, así que no aparece ninguna etiqueta que diga que un archivo es una mejora para la impresora y otro un accesorio de disfraz. Lo más parecido al reconocimiento automático es el hash de contenido, que establece que dos archivos son idénticos byte a byte en lugar de averiguar qué representa cada uno, y encontrar modelos 3D duplicados cubre dónde se detiene eso. Cuando otra herramienta sí presume de etiquetado semántico, la entrada casi siempre es el nombre del archivo o el texto raspado de una página de modelos, así que las etiquetas heredan todo el ruido que esos traigan.

¿Puede una biblioteca etiquetar modelos automáticamente a partir de sus nombres de archivo?

PrintStash no lo hace, y los nombres de archivo son una señal débil sobre la que construir: bracket_v2_FINAL.stl no dice nada fiable sobre material, propósito o estado, y las convenciones varían por persona y por descarga. Lo que sí se lee automáticamente son los metadatos que los slicers incrustan en el G-code, que son estructurados y escritos por una máquina en lugar de deducidos. Si tus nombres de archivo codifican de verdad un esquema, la vía práctica es filtrar y editar en masa por grupos, en lugar de esperar un parser que encaje con tu convención.

Si los metadatos del slicer se analizan, ¿siguen haciendo falta etiquetas?

Sí, pero muchas menos. Los campos analizados cubren los hechos físicos: material, boquilla, altura de capa, temperaturas, impresora, tiempo y filamento estimados. Las etiquetas son para los juicios que nunca aparecen en un archivo, como si una pieza necesita soportes, si es un regalo o si forma parte de una rutina de calibración. Una etiqueta que duplica un campo analizado es peor que no tener etiqueta, porque se queda obsoleta la primera vez que vuelvas a laminar con otros ajustes y nada la actualiza.

¿Qué pasa con mi estructura de carpetas actual?

Tú eliges. Un volumen compartido en modo espejo convierte las subcarpetas en colecciones anidadas y deja cada archivo en su ruta actual, así que tu slicer sigue abriendo las mismas ubicaciones de siempre. El modo de colección única ignora el árbol y lo pone todo en un mismo sitio, lo que le va bien a carpetas que crecieron a base de descargas y no de intención. Subir un ZIP se comporta como el modo espejo para el contenido de ese archivo comprimido. Nada mueve ni renombra tus archivos de origen.

¿Puedo organizar una biblioteca que ya tiene miles de archivos?

Sí, y el orden importa. Indexa primero sin mover nada, deja que el escaneo inicial hashee y analice todo, y solo entonces decide la estructura, porque el índice suele mostrar que la biblioteca no tiene la forma que recuerdas. A partir de ahí, filtra por un campo analizado y edita en masa hasta 500 modelos por pasada. Prueba con una subcarpeta representativa antes de añadir la raíz completa: el primer escaneo es el caro, y las mallas densas son donde aparecen los límites de memoria.

¿Hace falta una impresora conectada para nada de esto?

No. El análisis de metadatos, la detección de perfiles, las colecciones, las etiquetas, los filtros y las vistas guardadas funcionan sin ninguna impresora configurada. Una impresora conectada añade historial de trabajos, y cuánto de ese historial es medido y no estimado depende del proveedor: el filamento medido viene solo de Moonraker, la duración medida viene además de OctoPrint, PrusaLink y Elegoo Centauri, y Bambu LAN en modo local no reporta ninguno de los dos. Lo que falte cae de vuelta a la estimación del slicer, así que esto mejora las cifras de coste, no la organización.

Fuentes

• La guía de usuario de PrintStash para el ciclo de ingesta y metadatos, los volúmenes compartidos para el modo espejo frente al de colección única y el comportamiento del escaneo, y las capacidades para los límites actuales de filtros, vistas guardadas y edición masiva.
• La cobertura de slicers y los campos analizados siguen lo que OrcaSlicer, PrusaSlicer, Bambu Studio y Cura escriben en su salida, así que los campos disponibles varían con el slicer y el perfil.

Si la biblioteca es sobre todo G-code y no mallas, seguir las revisiones de G-code cubre la parte de versiones del mismo problema, y las subidas automáticas desde OrcaSlicer elimina el paso de meter los archivos en la biblioteca.