Convertir GLTF a PLY

PLY salió de Stanford en 1994 justo para esto: una malla con un conjunto arbitrario de propiedades por vértice y por cara, declaradas en una cabecera que un programa puede leer sin saber nada de antemano. Ese diseño es la razón de que se convirtiera en la moneda corriente del escaneado, la fotogrametría y el trabajo académico de geometría, y de que CloudCompare, MeshLab, Open3D y trimesh lo traten como entrada de primera clase.

glTF se diseñó para el extremo opuesto de la cadena: entregar un modelo terminado a un motor de representación a través de una red. Sus virtudes son justo lo que una herramienta de medición ignora —definiciones de material, empaquetado de texturas, animación, mecanismos de extensión—. Varias de esas herramientas no tienen importador de glTF, y las que lo tienen lo tratan como algo secundario. Convertir suele salir más barato que pelearse con eso.

Es deliberadamente mínima: la palabra ply, después format ascii 1.0, un comentario que nombra a quien lo escribió, una declaración element vertex con su recuento, tres líneas property float para x, y y z, una declaración element face con su recuento, una línea property list uchar int vertex_indices y end_header.

Ése es el dialecto de PLY con más soporte que existe. Un recuento de caras en uchar con índices en int es lo que asume casi cualquier lector cuando toma atajos, y posiciones en float en lugar de double dejan el archivo a la mitad de tamaño con una precisión que ninguna malla de aquí necesita. Si vas a escribir un analizador contra esta salida, esas siete declaraciones son el contrato completo.

Cada coordenada se escribe como texto decimal, un vértice por línea y un triángulo por línea. Un vértice que ocupaba doce bytes en el búfer del glTF pasa a ocupar entre veinte y sesenta caracteres, así que cuenta con que el PLY sea varias veces el tamaño de la geometría de la que salió. Un modelo de dos millones de triángulos es un archivo de texto grande.

La compensación es que no hay nada ambiguo en él. El PLY binario viene en variantes de orden de bytes distinto y con disposiciones de propiedades que el lector tiene que reconstruir desde la cabecera, y una suposición equivocada ahí produce mallas que se cargan como ruido. El ASCII no puede fallar de esa manera, y para un archivo que va a entrar una vez en una herramienta de análisis, el tamaño rara vez importa más que la certeza.

Un archivo PLY contiene un elemento de vértices y un elemento de caras. No hay grupo, ni objeto, ni pieza. Así que el conversor funde en una sola lista todas las mallas que leyó de la escena del glTF, desplazando los índices de cada una según el número de vértices ya escritos para que los triángulos sigan apuntando a donde deben.

La geometría no cambia y la estructura desaparece. Un glTF montado a partir de doce piezas con nombre se convierte en una superficie con doce cascarones inconexos, y los nombres se van con la estructura. Si esas divisiones son lo que necesitas más adelante, el destino que las conserva es OBJ, y convertir a OBJ no te quita nada más de lo que PLY te habría dado.

El motivo más citado para usar PLY es que admite rojo, verde y azul por vértice, que es como un escaneo fotogramétrico lleva su aspecto sin necesidad de textura. El formato lo admite y los lectores lo esperan.

Aquí no se escribe. El color de un glTF vive en materiales y texturas indexadas por coordenadas UV, y nada de eso se lee; y aunque el archivo declarase un atributo de color por vértice, ese atributo tampoco se lee. La salida es una superficie sin color, que es lo correcto para medir y lo equivocado si lo que querías era una exportación que conservara la apariencia. Conviene saberlo antes de convertir el levantamiento de un capitel o de un relieve, porque en ese material el color no es decoración: a menudo es el dato.

La escena se recorre desde su escena por defecto, cada matriz de nodo se multiplica por la de su padre y la matriz resultante se aplica a los vértices. Los nodos escritos con traslación, rotación y escala por separado se componen antes en una matriz, siguiendo el convenio de cuaterniones que define glTF.

Hacerlo antes de la fusión es lo que la vuelve segura. Si las transformaciones se dejaran sin aplicar, aplanar varias mallas en una sola lista amontonaría todas las piezas en el origen y produciría una forma sin ninguna relación con el modelo. Hornear primero significa que las cifras que midas en CloudCompare son las que describía la escena del glTF, cosa que importa mucho cuando el modelo venía georreferenciado o con una escala real establecida en el trabajo de campo.

Un búfer de índices, tal cual. glTF guarda los triángulos como índices dentro de una lista de posiciones compartida, y la conversión conserva esa estructura elemento por elemento en vez de reconstruirla: en este camino no se aplica ninguna soldadura de vértices, porque no hay nada que reparar. Un STL que llega al mismo destino hay que soldarlo antes, porque por diseño guarda tres vértices sin compartir por cada triángulo.

Esa diferencia decide si el análisis que vas a ejecutar significa algo. Las comprobaciones de variedad, la estimación de normales, la curvatura, la distancia geodésica, el suavizado laplaciano y la decimación asumen conectividad. La única advertencia que conviene llevarse a MeshLab es que los exportadores parten vértices en las costuras de UV y de normales, y esos duplicados sobreviven aquí como entradas separadas en coordenadas idénticas, así que una pasada de fusión de vértices próximos antes de una comprobación topológica es un hábito sensato.

Merece enumerarlo, porque en un modelo de patrimonio o de producto es mucho. Materiales, imágenes de textura, coordenadas UV, normales por vértice o por cara, colores por vértice, cámaras, luces, animaciones, esqueletos y objetivos de deformación, y el propio grafo de escena: nada de eso llega al PLY.

La razón no es que se descarten uno a uno, sino que la representación intermedia por la que pasa todo aquí guarda dónde están los triángulos y sus nombres, y no tiene ningún sitio donde poner un color, una UV, una normal o un fotograma clave. Lo que se convierte es geometría. Si en tu caso lo importante es el aspecto, el glTF ya es el archivo correcto y esta conversión no te va a acercar a nada.

Un .gltf que guarda su geometría en un .bin aparte no se puede leer, porque un conversor de un solo archivo nunca ve el segundo; el mensaje lo dice y sugiere el .glb, que lo lleva todo junto. Un archivo que usa KHR_draco_mesh_compression se detiene con un mensaje que nombra a Draco, cuyo descodificador no viaja con esta página.

Y las primitivas que no son listas de triángulos se saltan. El modo 4 de glTF son triángulos; las tiras, los abanicos, las líneas y los puntos no son superficies que este conversor pueda convertir en caras, y un archivo que solo contenga eso informa de que no se encontró geometría triangular en vez de producir un PLY vacío que falla en silencio dos pasos más adelante, dentro de tu análisis.

Si vas a mirar el modelo en lugar de medirlo, PLY es un mal destino: sin materiales, sin texturas, sin estructura y con un archivo bastante mayor. Quédate con el glTF, o convierte a OBJ si el visor es antiguo. Para una publicación en línea o para un visor web, el glTF ya está en el formato que ese destino quiere.

PLY se gana su sitio cuando el paso siguiente es un algoritmo geométrico: decimación, remallado, cierre de agujeros, alineación contra otro escaneo, una medición de volumen o de superficie, una distancia de Hausdorff entre dos versiones de la misma pieza para documentar un deterioro. Para ese trabajo, la planitud y la falta de color son irrelevantes, y tener la malla en el formato alrededor del cual se escribió la herramienta vale más que todo lo que la conversión deja por el camino.

Todo esto ocurre en tu navegador: se lee el glTF, se recorre la escena, se hornean las matrices, se funden las mallas y se escribe el texto del PLY sin que el archivo salga de la máquina. El tope de la capa gratuita son 100 MB por archivo, y el límite práctico que encontrarás antes en un modelo muy denso es la memoria de la propia pestaña, porque un PLY ASCII se construye entero antes de descargarse.

Para el material de un levantamiento eso no es una comodidad. Un escaneo de un bien patrimonial, el modelo de una pieza antes de restaurar o la geometría de un producto sin lanzar suelen venir con condiciones sobre dónde pueden almacenarse, y subirlos a un conversor web es exactamente la transferencia que esas condiciones existen para evitar. Se puede comprobar en el panel de red mientras convierte, que es más rápido que redactar un correo pidiendo permiso.