Convertir GLB a PLY

GLB es glTF empaquetado en un solo archivo binario, y glTF describe una escena completa: mallas, materiales con sus mapas, texturas incrustadas, cámaras, luces, esqueletos, animaciones y un grafo de nodos que coloca cada pieza en su sitio. Es el formato con el que hoy se intercambian modelos entre programas y con el que los visores web muestran objetos en tres dimensiones.

Lo que esta conversión traslada es la geometría: dónde están los triángulos. Nada más. La forma intermedia por la que pasa todo tiene exactamente tres campos —un nombre opcional, las posiciones de los vértices y los índices de las caras— y no hay ningún sitio donde meter un color, una coordenada de textura, una normal o un fotograma de animación.

Una cabecera que declara el número de vértices y de caras, tres propiedades por vértice —x, y, z en coma flotante— y una lista de índices por cara. Se puede abrir con un editor de texto y leer entero. No hay más elementos declarados y no hay más datos guardados.

Conviene contrastarlo con lo que un PLY puede llevar en general, porque son cosas distintas y confundirlas es el origen de casi todas las decepciones con los conversores: el formato admite colores por vértice, normales, coordenadas de textura y propiedades definidas por el usuario. El PLY que escribimos aquí no las lleva, y decir «PLY admite colores» sería verdad sobre el formato y mentira sobre este archivo.

Un PLY describe una superficie, no una colección. Así que si el GLB traía una silla formada por asiento, respaldo y cuatro patas como mallas separadas, el PLY contiene una sola malla con todos sus vértices y sus caras concatenados, con los índices desplazados para que sigan apuntando donde deben.

Los nombres desaparecen en ese paso. La geometría es idéntica y la organización no sobrevive, que es exactamente lo que ocurre también al escribir un STL. Si necesitas mantener las piezas separadas, el destino correcto es otro: OBJ y glTF sí tienen dónde guardar varias mallas con sus nombres.

Un glTF coloca una misma malla varias veces con matrices distintas: las cuatro ruedas de un coche son una rueda y cuatro posiciones. Si se leyera la lista de mallas en lugar del grafo de la escena, las cuatro copias saldrían amontonadas en el origen y el modelo estaría roto.

Por eso se recorre el grafo desde la escena, se multiplican las matrices de cada nivel y el resultado se aplica a cada vértice antes de escribirlo. Se acepten como matriz o como traslación, rotación y escala, el efecto llega al archivo. PLY, STL y OBJ no tienen ningún concepto de instancia, así que hornearlas es la única forma de conservar la forma del conjunto.

Es la pérdida que más se nota en la práctica, porque un PLY con color por vértice es justo lo que produce un escáner tridimensional o una reconstrucción fotogramétrica, y quien trabaja con esos archivos asocia el formato al color. Aquí no: si el GLB llevaba color en los vértices o una textura aplicada, el PLY sale gris.

La limitación es coherente en todas las direcciones a propósito. Un conversor que llevara materiales entre los dos formatos ricos y los perdiera en los otros cuatro sería impredecible desde fuera, y cualquier camino que pase por un STL los pierde de todos modos. Es mejor una regla que se pueda enunciar en una frase que un comportamiento distinto por pareja.

Muchos GLB de descarga vienen con la geometría comprimida con Draco, que reduce el archivo de forma notable y necesita un descodificador que aquí no se distribuye. Cuando el archivo declara esa extensión, la conversión se detiene con un mensaje que te pide reexportarlo sin Draco.

Detenerse es la respuesta correcta. La alternativa sería leer lo que se pueda y entregar un modelo incompleto o vacío que parece un fallo del formato de destino y no lo es. Casi cualquier programa que exporte GLB tiene una casilla de compresión que se puede desmarcar.

Una primitiva de glTF puede describirse como triángulos, tiras de triángulos, abanicos, líneas o puntos. Aquí se leen únicamente los triángulos; las demás se saltan. Las líneas y los puntos no son superficies, y las tiras y los abanicos necesitarían una conversión previa.

Un GLB exportado por un programa de modelado normal está hecho de triángulos y no notarás nada. Si el tuyo era una visualización de datos hecha de líneas o una nube de puntos, la conversión terminará diciendo que no ha encontrado geometría triangular, que es una frase mucho más útil que un archivo con cero caras.

PLY se escribe aquí siempre en texto, nunca en binario. Cada coordenada pasa de ocupar cuatro bytes a ocupar los caracteres que haga falta para escribirla, y a eso se suma que el GLB de partida ya venía en binario compacto. Multiplicar el tamaño por varias veces es lo normal.

A cambio, el archivo es legible, inspeccionable y no depende del orden de los bytes de ninguna máquina. Para un modelo de unos cientos de miles de triángulos es un intercambio razonable; para uno de varios millones, conviene saber de antemano que el archivo va a ser grande.

Un GLB guarda por separado la lista de posiciones y la lista de índices que dice qué tres vértices forman cada triángulo, de modo que un vértice compartido por seis caras se escribe una sola vez. Esa lista se traslada al PLY con los índices desplazados por la fusión de mallas, pero sin reconstruirse: el número de vértices del PLY es el que tenía el GLB.

Si una primitiva venía sin lista de índices —lo que es legal y significa que los vértices se leen de tres en tres—, se genera la secuencia correspondiente. Lo que no se hace en este camino es fusionar vértices duplicados: si el modelo llegó con las caras separadas, sale con las caras separadas, y un programa de mallas puede pedirte que las sueldes antes de trabajar.

Si algún día conviertes un PLY hacia otro formato aquí, hay un caso que se rechaza expresamente: un PLY que contiene puntos y ninguna cara, es decir, una nube de puntos, que es justo lo que produce un escáner antes de reconstruir la superficie.

La negativa es deliberada y está explicada en el mensaje: convertir puntos en una superficie es reconstrucción, no conversión, y necesita un programa de modelado que decida cómo unirlos. Devolver una malla vacía habría sido más cómodo y menos honesto. En la dirección que nos ocupa el problema no se plantea, porque el PLY que escribimos siempre lleva caras.

PLY es el formato de trabajo de MeshLab y de CloudCompare, que son las herramientas con las que se limpian, alinean y miden mallas en fotogrametría, en documentación de patrimonio y en investigación. Llegar a PLY desde un GLB suele significar exactamente eso: sacar un modelo de la cadena de visualización y meterlo en la cadena de medición.

Si el destino es una impresora tridimensional, el camino habitual es STL en lugar de PLY, y este sitio también lo hace desde GLB. La diferencia es de costumbre del programa receptor más que de contenido: los dos guardan una única superficie de triángulos y ninguno de los dos lleva materiales.

La conversión es JavaScript corriente dentro de tu navegador: se lee el binario, se recorre el grafo, se escribe el texto. El modelo no se transmite a ninguna parte, lo que importa más de lo que parece cuando el archivo es el prototipo de un producto que todavía no se ha presentado o el escaneo de una pieza que no es tuya.

El tope por archivo son 100 MB y puedes soltar hasta cien de una vez, que vuelven juntos en un ZIP. Con modelos grandes el límite real acaba siendo la memoria de tu equipo mientras se construye el texto del PLY, así que en ese rango conviene ir por tandas cortas.