Convertir STL a PLY

Todas las demás conversiones entre formatos tridimensionales de este sitio renuncian a algo con peso: un glTF deja atrás sus materiales, un OBJ su archivo de materiales asociado, un 3MF su color y sus datos de impresión. De STL a PLY lo único que se queda por el camino son las normales de cara almacenadas, y esas las recalcula desde el orden de los vértices cualquier lector que las necesite.

Todo lo demás cruza porque no había nada más. Un STL es una lista de triángulos sin color, sin unidades, sin nombres, sin piezas y sin atributos. Un PLY escrito con x, y, z y una lista de caras contiene exactamente eso. Los dos formatos están de acuerdo en qué es un modelo, y esa coincidencia es rara en esta categoría.

CloudCompare, MeshLab, Open3D y trimesh aceptan PLY como entrada de primera clase, porque Stanford lo diseñó en 1994 precisamente para este tipo de trabajo: una cabecera que se describe a sí misma y enumera las propiedades por vértice y por cara que a una herramienta de investigación se le ocurra necesitar. El escaneo y la fotogrametría se estandarizaron sobre él por el mismo motivo, y por eso es el formato en el que llegan las capturas de una pieza real.

Esas mismas herramientas también leen STL, y ahí es donde empieza el problema en lugar de terminar. Un STL se abre, se muestra y parece correcto siendo topológicamente inservible. Convertir no va de conseguir que el archivo abra: va de conseguir una malla cuya conectividad puedan usar los algoritmos.

Un STL guarda tres vértices independientes por cada triángulo. Un cubo son treinta y seis registros de vértice para ocho posiciones reales. Carga eso en una herramienta de malla, pregunta si la superficie es cerrada y te responderá que absolutamente todas las aristas son de borde, porque no hay dos triángulos que compartan un vértice, aunque la forma no tenga ni un solo agujero.

La conversión recorre esos registros, agrupa los que ocupan la misma posición y los sustituye por un único vértice compartido al que apuntan todos sus triángulos. A partir de ahí funcionan de verdad la comprobación de estanqueidad, la estimación de normales, la curvatura, la simplificación, el suavizado y el relleno de agujeros. Sin ese paso, cada uno de esos algoritmos devuelve un resultado que parece razonable y describe un objeto que no es el tuyo.

La agrupación no compara los números en crudo: los redondea a seis decimales y usa ese texto como clave. Hace falta hacerlo así porque dos triángulos que se tocan en una arista discrepan rutinariamente en el último bit de un número en coma flotante, y una comparación exacta dejaría sin soldar precisamente los sitios donde la soldadura importa.

Seis decimales cae en el hueco cómodo entre las dos cosas que hay que evitar. Está muy por debajo de cualquier tolerancia que le importe a una pieza física —si las unidades son milímetros, hablamos de nanómetros— y muy por encima del ruido numérico del que hay que deshacerse. La consecuencia es que la superficie que sale es la misma que entró; lo que cambia es cómo está registrada.

Es la cabecera conservadora, y conviene conocerla porque muchos disgustos con PLY vienen de cabeceras ambiciosas. Primero la palabra ply; después format ascii 1.0; un comentario que nombra a quien escribió el archivo; una declaración de elemento vértice con tres líneas de propiedad para x, y, z; una declaración de elemento cara con una única línea de lista de índices; y el fin de cabecera. Luego una línea por vértice y una línea por triángulo, con un 3 delante de cada terna.

No se declara nada más: ni normales, ni color, ni confianza, ni calidad, ni propiedades a medida. Es deliberado, porque una cabecera que promete una propiedad que el archivo no puede rellenar es peor que una cabecera corta, y porque cualquier programa que lea PLY lee este dialecto. Si tu cadena de trabajo espera propiedades concretas, añadirlas en MeshLab después de importar es más seguro que dejar que el conversor las adivine.

Cada registro de cincuenta bytes de un STL binario empieza por doce bytes de normal de cara. Esos doce bytes se saltan sin leerlos. La información que contienen queda completamente determinada por el orden en el que se listan los tres vértices, de modo que recalcularla es exacto y no aproximado.

No es un atajo por comodidad. Las normales guardadas en un STL contradicen el orden de los vértices con la frecuencia suficiente como para que varios laminadores y varias herramientas de malla las descarten por norma, sencillamente porque demasiados exportadores se equivocan con el signo o con la normalización. Recalcular desde el orden da una respuesta consistente, y una malla cuyo orden es inconsistente es un defecto que quieres ver, no uno que quieras tapar con un valor almacenado.

La prueba habitual —comprobar si el archivo empieza por la palabra solid— es sencillamente incorrecta, porque un escritor binario puede poner lo que quiera en sus primeros ochenta bytes de cabecera y varios ponen justamente esa palabra. Un archivo así se leería como texto, no encontraría ningún vértice y se rechazaría por ilegible siendo perfectamente válido.

La comprobación que se hace aquí es aritmética: un STL binario mide exactamente ochenta y cuatro bytes más cincuenta por cada triángulo declarado en su cabecera, y ninguna otra cosa cuadra con esa cuenta por casualidad. Como efecto colateral, esa fórmula te permite predecir el tamaño de cualquier STL binario antes de abrirlo: dos millones de triángulos son cien megabytes, cifra que además roza el techo por archivo de esta página.

Ni STL ni PLY tienen manera de decir «esto es la tapa y esto es el cuerpo». Si el modelo original tenía piezas nombradas, esa información se perdió cuando alguien lo exportó a STL, mucho antes de llegar a esta página, y el PLY refleja fielmente esa pérdida en lugar de fingir una estructura.

Conviene saberlo porque cambia dónde hay que buscar el problema. Si necesitas las piezas separadas para medirlas una por una, la solución no es otra conversión: es volver al archivo del que salió el STL y exportar cada pieza aparte, o segmentar la malla en la herramienta de medición, que para eso tiene funciones de selección por componente conectado. Al menos, tras la soldadura de vértices esa segmentación por componentes funciona; sobre el STL crudo no habría funcionado.

Cada coordenada se escribe como número decimal, un vértice por línea, y cada triángulo como un 3 seguido de tres índices. Un vértice que ocupaba doce bytes en binario pasa a ocupar entre veinte y sesenta caracteres. En contra de eso juega a favor la soldadura, que ya ha eliminado del orden de cinco sextos de los registros de vértice que traía el STL.

Los dos efectos se compensan en parte y el resultado depende del modelo. Lo que sí es predecible es que un ASCII se puede abrir con un editor y comprobar a ojo, cosa que en un trabajo de medición se agradece más de lo que parece. Si el archivo resultante se vuelve incómodo de manejar, guardarlo de nuevo desde MeshLab como PLY binario es un paso y lo resuelve.

El motivo más frecuente de esta conversión es comparar: una pieza se fabricó o se reprodujo a partir de un STL, después se escaneó, y alguien necesita la diferencia. En restauración y en documentación de patrimonio la pregunta es la misma con los papeles cambiados —cuánto se aparta la réplica del original digitalizado—, y el procedimiento no varía. El cálculo de distancia de nube a malla quiere la referencia como malla con caras, que es lo que produce esta conversión, y el escaneo como puntos, que es lo que produjo el escáner.

Dos advertencias prácticas. Los dos conjuntos hay que alinearlos primero, normalmente con una selección gruesa de parejas de puntos seguida de un ajuste fino automático. Y tienen que compartir escala, cosa que ninguno de los dos formatos declara: si el escaneo está en milímetros y el STL se exportó en pulgadas, la alineación convergerá en algo verosímil y equivocado. Comprueba una cota conocida en los dos archivos antes de fiarte de ningún mapa de color.

PLY es el formato en el que llegan los escaneos precisamente porque admite color por vértice, y eso es lo que hace que una malla fotogramétrica se parezca al objeto del que salió. Nada de eso aparece aquí, sencillamente porque el STL no tenía color que entregar.

La excepción no oficial merece nombrarse: un puñado de programas codifican un color de quince bits en los dos bytes de atributo que hay al final de cada registro de triángulo, en dos convenciones incompatibles entre sí. Esos bytes no se leen. No hay forma de saber cuál de las dos convenciones usó un archivo, y adivinar pondría colores equivocados sobre una malla que alguien está a punto de medir. Las unidades corren la misma suerte por otro camino: los números se copian tal cual, y como ningún formato declara unidad, un STL que significaba milímetros produce un PLY que significa milímetros y tu herramienta informará en lo que ella suponga.

Si el destino es un laminador o un servicio de impresión, no conviertas: quieren STL o 3MF, y el soporte de PLY en ese mundo es desigual. Si el destino es un visor dentro de una página web, el objetivo correcto es glTF y PLY es el equivocado.

Convierte cuando el siguiente paso sea un algoritmo: un cálculo de distancias, una simplificación, un remallado, un relleno de agujeros, un volumen, una superficie, una alineación contra datos escaneados. Todo el valor del paso está en la soldadura y en el formato que la herramienta espera, y el trabajo entero se hace dentro de tu navegador: nada sube a ningún servidor, no hay cuenta y no hay cola. Eso importa cuando la geometría de referencia es una pieza sin publicar, un molde ajeno o la digitalización de un bien que no puede circular.