Versionado de archivos 3D: dónde está el límite

El control de versiones de los archivos de impresión 3D se reparte de forma desigual, y conviene saberlo antes de diseñar un flujo de trabajo alrededor. El G-code laminado tiene herramientas de verdad: una etiqueta, un resultado, notas y exactamente una revisión marcada como la que hay que reimprimir. Las mallas de origen tienen mucho menos. En PrintStash reciben un historial ordenado y un número de versión, y nada de la contabilidad, porque los endpoints de revisiones rechazan cualquier cosa que no sea G-code.

Eso es una limitación, no un defecto de diseño esperando a que alguien lo discuta, y saber en qué lado de la línea estás te ahorra esperar una función que no existe.

Qué contiene en realidad un modelo

Un modelo es un activo lógico, no un archivo: la escuadra, no bracket.stl. Es dueño de todos los archivos que hay debajo, lo que incluye la malla de origen, cada exportación laminada, la miniatura y los metadatos leídos. Los modelos se deduplican por el SHA-256 de su malla de origen, así que volver a subir el mismo STL resuelve al modelo que ya lo contiene en vez de empezar un segundo.

Cada archivo de debajo lleva un número de versión dentro de ese modelo, así que el historial de un modelo es la lista ordenada de sus archivos. Eso vale para cualquier formato.

Qué recibe solo el G-code

La contabilidad. Un archivo de G-code puede llevar una etiqueta, notas de texto libre y un resultado entre needs_test, known_good, failed y archived. Uno de ellos tiene la marca de recomendado, y la regla se impone en vez de sugerirse: un modelo con G-code siempre tiene exactamente una revisión recomendada, nunca cero y nunca dos. El primer G-code que subes a un modelo se la queda automáticamente, y marcar otro la quita de todos los demás.

Intenta fijar cualquiera de esas cosas en un STL, un OBJ, un archivo STEP o un 3MF y la API responde revision_not_supported. Tampoco hay un camino escondido a través de la interfaz, porque la interfaz llama a los mismos endpoints.

Así que la forma práctica es esta: puedes guardar cinco versiones de una malla bajo un mismo modelo y verlas en orden, y no puedes registrar cuál de las cinco es la buena. Con la salida laminada, sí puedes.

Qué hacer en el lado de la malla

Guarda el origen editable, no solo la exportación. Un archivo STEP o un proyecto de CAD es aquello de lo que parte una edición futura, y un STL es un producto final con pérdidas que nadie disfruta modificando. PrintStash guarda STEP y STP con normalidad y los previsualiza en el navegador tanto en amd64 como en ARM desde la v0.12.0, algo que cubre guardar los archivos STEP junto a la malla imprimible.

Pon el razonamiento en un sitio duradero. Las colecciones llevan documentos y un README, que es el hogar adecuado para las notas de construcción que abarcan los modelos de un proyecto, porque una malla suelta no tiene dónde guardar un párrafo.

Y acepta el límite de identidad en vez de buscarle la vuelta. El hash de contenido te dice que dos archivos son idénticos byte a byte; no te puede decir que una malla reparada, reescalada o reexportada es una versión posterior de otra anterior. Son bytes distintos y por tanto un archivo distinto, y ninguna herramienta decide que son el mismo modelo sin adivinar. Encontrar archivos STL duplicados profundiza en dónde está ese límite.

Dónde encaja Git de verdad

Si tu origen es texto, usa Git, porque la objeción a Git para archivos de impresión 3D es enteramente sobre bloques binarios. OpenSCAD, CadQuery y build123d producen modelos a partir de código, y un repositorio de eso te da diffs, ramas y blame de verdad, nada de lo cual admite una malla. El STL exportado pasa a ser un resultado de compilación en vez de algo que conservar.

Ese planteamiento se extiende también al lado laminado. Fijar la versión del slicer para que un commit regenere el mismo G-code convierte la exportación en un artefacto de compilación que puedes tirar, algo que versionar el G-code como una compilación reproducible desarrolla del todo, incluido dónde tiene que seguir viviendo el registro de lo que se imprimió de verdad.

Para una malla modelada en una interfaz gráfica, Git te aporta muy poco. Cada guardado es un bloque opaco, el diff no significa nada y el repositorio crece el tamaño completo del archivo cada vez. Un número de versión bajo el registro de un modelo te da el orden sin ese coste.

Preguntas que surgen

¿Puedo guardar varias versiones de un STL en PrintStash?

Sí, y quedan agrupadas y ordenadas. Cada archivo bajo un modelo tiene un número de versión, así que el historial del modelo es la lista ordenada de sus archivos, y subir una malla revisada añade a esa lista en vez de reemplazar lo que había. Lo que no puedes hacer es anotarlas. Las etiquetas, las notas, los estados de resultado y la marca de recomendada son solo para G-code, y la API devuelve revision_not_supported para cualquier otro tipo de archivo. En la práctica eso significa que puedes ver que existen cinco versiones y en qué orden, y que registrar cuál es la actual queda de tu lado.

¿OpenSCAD o el CAD por código cambian la respuesta?

Del todo, porque el problema de versionado se traslada a un tipo de archivo para el que Git se construyó. Un archivo .scad es texto, así que los commits producen diffs legibles, las ramas funcionan con normalidad y el repositorio se queda pequeño por muchas revisiones que guarde. La malla pasa a ser un resultado de compilación que regeneras, no un activo que archivas, lo que esquiva toda la cuestión de cómo versionar un binario. La biblioteca guarda entonces lo que el repositorio no puede: la salida laminada, sus ajustes leídos y el registro de qué laminado imprimió bien.

¿Qué debo guardar cuando remezclo el modelo de otra persona?

La descarga original, tu origen editado y el enlace a de dónde vino con su licencia. Es habitual quedarse solo con el STL editado, que funciona hasta que quieres cambiar algo y descubres que la edición fue destructiva, o hasta que alguien pregunta qué licencia hereda el derivado. La licencia en particular no se puede reconstruir cuando la página de origen cambia o desaparece, y es la pieza que determina si puedes compartir o vender el resultado.

¿Cómo sé si un modelo de origen se ha actualizado?

Nada en la biblioteca te lo va a decir, y merece la pena tenerlo claro en vez de confiar en que sí. Una biblioteca guarda tu copia del archivo, deduplicada por hash de contenido, así que no tiene ninguna relación con la página de la que descargaste ni forma de darse cuenta de que el diseñador publicó una corrección. Comprobarlo es manual y le toca al sitio del modelo, donde seguir al diseñador o al modelo te da el aviso. Si guardas la URL de origen al importar, esa comprobación es un clic, que es casi todo el argumento para guardarla.

Fuentes

• Los conceptos básicos de PrintStash para el vocabulario de modelo, artefacto y revisión, los cuatro estados de resultado y el invariante de la revisión recomendada.
• La restricción a G-code se leyó en los endpoints de revisiones de backend/app/api/v1/models.py en el repositorio del producto, que rechazan un tipo de archivo que no sea G-code con revision_not_supported.
• Las limitaciones conocidas para el presupuesto de teselación de STEP y las variantes de imagen.

Para las reglas de resultado por su cuenta, un modelo, muchos G-codes. Para las cuatro formas en las que la gente sigue las iteraciones laminadas, incluidas las convenciones de nombres y las estadísticas del controlador, seguir las iteraciones de G-code.