¿Qué es un archivo PLY?

PLY es un formato binario, que solo significa algo para un programa que lo conoce. Guarda formas y coordenadas en lugar de píxeles, así que se mantiene nítido a cualquier tamaño: un logotipo llevado al tamaño de una valla publicitaria no pierde nada. Se usa para el escaneo y mover datos entre programas.

La extensión es .ply y el nombre completo, Polygon File Format. Ambos importan menos que lo que el archivo puede contener, y de eso trata el resto de esta página.

Stanford University lo publicó en 1994.

A un formato que lleva tanto tiempo siendo legible se le puede confiar algo que quieras recuperar dentro de diez años.

Está publicada entera, así que cualquiera puede implementarla leyendo el documento en vez de a base de inspeccionar archivos. Por eso aparece en tantos programas, y por eso los archivos escritos hace veinte años siguen abriéndose hoy. Publicada no quiere decir libre de regalías: cuando un formato envuelve un códec, la licencia de las patentes es un asunto aparte que la norma no resuelve.

PLY guarda su contenido exactamente. Volver a guardarlo no cambia nada, así que puedes abrirlo, editarlo y guardarlo tantas veces como quieras sin acumular daño; eso es lo que lo convierte en un formato de trabajo y no de entrega.

MeshLab, Blender y CloudCompare lo leen, y también la mayoría de programas del mismo tipo.

Cuando un archivo no se abre, el formato rara vez es el problema: lo más habitual es que el programa sea anterior al formato. Convertir a algo más antiguo es la salida fiable, y para eso está el resto de este sitio.

Ningún navegador lo lee.

Ese es el motivo más frecuente para convertirlo: no que el formato sea malo, sino que el sitio donde quieres mostrar el archivo no sabe leerlo.

PLY está pensado para abrirse y cambiarse. Guarda el archivo en este formato mientras el trabajo siga en marcha y exporta desde él cada vez que haga falta una copia terminada.

PLY se escribió en Stanford a mediados de los noventa para datos de escáneres de rango, y eso sigue siendo lo que contiene casi siempre. Los programas de fotogrametría, los escáneres de mano y de luz estructurada, las herramientas de lidar y los propios modelos de Stanford lo hablan, porque se diseñó justo para lo incómodo que producen esos aparatos: millones de puntos medidos, cada uno con las propiedades que el instrumento registró.

Lo que le ha dado tanta vida es que las propiedades se declaran en lugar de estar fijadas. La cabecera enumera qué lleva cada vértice — posición, color, normal, confianza, intensidad, lo que ese aparato mida — y cada lector coge lo que entiende. Por eso un formato de 1994 puede transportar los datos de un instrumento fabricado el año pasado.

OBJ pinta una superficie proyectando sobre ella una imagen de textura. PLY hace normalmente algo más simple: cada vértice lleva su propio color, medido en ese punto.

Para un escaneo eso es exactamente lo correcto, porque el aparato midió el color muestra a muestra y de todos modos no hay una superficie desplegada sobre la que colocar una imagen. También significa que la resolución del color es la de la geometría: una malla basta tiene color basto, y solo se gana detalle añadiendo puntos. Es el intercambio frente a las texturas, donde un modelo de pocos polígonos puede llevar una imagen muy detallada.

Esto genera confusión de verdad. Un PLY puede ser una lista de puntos sin ninguna conexión entre ellos — una nube — o una malla en condiciones con caras que los unen. Los dos son válidos, los dos llevan la misma extensión, y un programa que espera uno hará algo poco útil con el otro.

Una nube abierta en un programa que quiere mallas aparece como un polvillo tenue de puntos o directamente como nada. No está corrupta: sencillamente no hay caras que dibujar. Convertir una nube en superficie es reconstrucción — Poisson o pivotado de bolas en MeshLab o CloudCompare — y es un paso de procesado con parámetros que hay que elegir, no un cambio de formato.

Igual que en STL, la cabecera declara cuál de las dos codificaciones viene después. La versión ASCII se lee con un editor de texto y ocupa alrededor de cuatro veces más; la binaria es lo que escribe cualquier escáner real.

Incluso en binario estos archivos son grandes, porque las cifras lo son. Un escaneo por fotogrametría hecho con el móvil produce sin esfuerzo entre dos y cinco millones de puntos, y un barrido de lidar de una habitación llega a decenas de millones. A unos quince bytes por punto con color, un levantamiento de cien millones de puntos ocupa gigabyte y medio antes de haber reconstruido nada. Eso es normal en este formato y no un síntoma de mala exportación.

La salida en bruto nunca está terminada. Hay fondo — la mesa, el suelo, la habitación — que hay que recortar. Hay valores atípicos, puntos sueltos flotando donde el aparato se equivocó con un reflejo o con un borde. Y hay agujeros allí donde el instrumento no llegó a ver: debajo del objeto y detrás de cada saliente.

Después viene la decimación, porque una malla de cinco millones de puntos es inmanejable en cualquier paso posterior, luego el relleno de agujeros y solo entonces hay una malla que valga la pena texturizar o imprimir. MeshLab y CloudCompare son las herramientas gratuitas para todo eso. El escáner entrega mediciones; convertir mediciones en modelo es otro trabajo, y el más largo de los dos.

Pasar de PLY a STL es el último paso habitual, y descarta el color — STL no tiene — conservando la forma. Suele ser aceptable, porque una impresora de un solo material tampoco habría podido usar ese color.

El fallo que hay que esperar es la estanqueidad. Los escaneos están llenos de agujeros por naturaleza: nadie midió por debajo del objeto y falta detalle allí donde no había línea de visión. Un laminador necesita un sólido sin ambigüedades, así que los agujeros hay que taparlos y la malla hay que revisarla antes de escribir el STL. Saltarse eso produce un archivo que el laminador rechaza o, peor, uno que acepta e interpreta a su manera.

Si el modelo va a un motor de videojuego o a un visor web, glTF: lleva texturas, materiales y una escena, y está pensado para entregar en lugar de para capturar. Si va a un programa de modelado para seguir trabajándolo, OBJ se acepta en más sitios. Si va a una impresora, STL.

PLY se gana su sitio en el extremo de captura, donde tener propiedades por vértice y una cabecera ampliable es justo lo que hace falta. Guárdalo como registro de lo que realmente se midió y genera desde él los formatos de entrega: el camino inverso, reconstruir mediciones a partir de una malla decimada, no existe.

Solo geometría. Lo que cruza son los triángulos y dónde están; no cruzan materiales, ni texturas, ni coordenadas UV, ni normales, ni colores de vértice, ni cámaras, ni luces, ni animación, ni la jerarquía de la escena. Un modelo colocado varias veces en una escena vuelve con cada copia horneada en su propia posición, porque las transformaciones de nodo se aplican a los vértices. Todo se ejecuta en el navegador, con un tope de 100 MB por archivo.

Tres detalles concretos, porque son los que sorprenden. Cuando el destino es PLY, la escritura es siempre en ASCII. Tanto en PLY como en STL, todas las mallas del modelo se funden en una sola y se pierden los nombres. Y una nube de puntos se rechaza en lugar de convertirse: transformar puntos en superficie es reconstrucción, con parámetros que alguien tiene que decidir, y hacerlo en silencio sería inventarse una respuesta.