Convertir GLB a OBJ

Un GLB es una escena completa: un árbol de nodos, materiales con sus texturas, cámaras, luces, animaciones. Un OBJ es una lista de puntos y los triángulos que hay entre ellos, más un puntero a un fichero de materiales aparte. Al cruzar de uno a otro no se pierde calidad: se pierde categoría.

Conviene entenderlo así antes de convertir, porque la pregunta correcta no es «¿saldrá bien?» sino «¿qué de todo esto necesito en el destino?». Si la respuesta incluye materiales o texturas, esta conversión no es la herramienta y hay que buscar un programa que importe glTF directamente.

El fichero que sale contiene una línea de comentario con el nombre del escritor, una línea «o» por malla, una línea «v» por vértice con sus tres coordenadas en texto decimal y una línea «f» por triángulo con tres índices. No hay líneas «vt» de coordenadas de textura, ni «vn» de normales, ni grupos de suavizado, ni «usemtl», ni «mtllib».

El detalle que hace tropezar a quien escribe su propio lector es la numeración: los índices de OBJ empiezan en uno, no en cero, y cuentan a lo largo de todo el fichero en lugar de reiniciarse en cada grupo. El conversor lleva ese desplazamiento acumulado mientras recorre las mallas. Equivocarse ahí produce un OBJ que abre y enseña los triángulos cambiados, que es peor que uno que falla.

Un OBJ nunca guardó materiales por sí mismo. Guarda una línea «mtllib» con el nombre de un fichero .mtl acompañante, y es ese fichero el que lleva los colores, el brillo y las rutas de las texturas. Aquí no se escribe esa línea ni se produce ese fichero, así que la malla llega sin ninguna asignación y el importador aplica su gris por defecto.

Es la consecuencia de leer solo geometría. Los parámetros metálico-rugosidad del GLB, su color base, su mapa de normales y sus coordenadas UV no se extraen en ningún momento, de modo que no hay nada que escribir en un .mtl que no fuese inventado. E inventarlo sería peor: un .mtl con valores plausibles le dice a quien lo reciba que el material venía del original cuando no venía.

Cada malla del glTF se escribe como la línea «o» de su grupo, así que un modelo montado con componentes nombrados —carcasa, soporte, tapa— entra en Blender o en Maya como tres objetos con esos nombres y no como un bloque fundido. Una malla sin nombre en el origen recibe uno generado para que la estructura siga siendo legible.

En una conversión que solo conserva geometría, los nombres son prácticamente la única información con significado que sobrevive, y son lo que permite a alguien en el otro extremo reasignar materiales a las piezas correctas. Si tu GLB tiene mallas sin nombre y vas a necesitar la distinción, nómbralas antes de exportar y no después de importar.

glTF divide una malla en primitivas, y la razón habitual de esa división es que a distintas partes de la superficie les corresponden materiales distintos. Cada primitiva se escribe aquí como su propio grupo «o», y si la malla del origen tenía nombre, todas las primitivas que salieron de ella lo heredan.

El resultado, cuando la malla estaba nombrada, es un OBJ donde varios grupos consecutivos se llaman igual. No es un error: es la huella de una separación por material en un fichero que ya no tiene materiales, y esos grupos son exactamente las regiones a las que había que asignar algo distinto. Si la malla de origen no tenía nombre, cada primitiva recibe en su lugar uno generado y distinto, así que la repetición de nombre no es universal: depende de si el exportador nombró la malla.

Un glTF puede colocar una misma malla muchas veces referenciándola desde varios nodos con matrices distintas. OBJ no tiene equivalente. El conversor resuelve la diferencia recorriendo la escena, componiendo cada matriz con la de su padre y horneando la transformación resultante en las coordenadas de los vértices antes de escribirlos.

Así que un GLB con un tornillo instanciado sesenta veces produce un OBJ con sesenta grupos y sesenta copias completas de esa geometría. El modelo queda correcto —es la única manera de que lo quede— y el fichero crece en esa zona en la misma proporción. Si el programa de destino sabe instanciar, reconstruir la instanciación allí después de importar suele merecer la pena.

No se aplica ningún escalado. Los valores que hubiera en el GLB se escriben en el OBJ tal cual. Eso es el comportamiento correcto y es a la vez una trampa, porque los dos formatos entienden cosas distintas por un número.

glTF define su unidad lineal como el metro, así que una silla modelada a tamaño real tiene coordenadas alrededor de 0,9. OBJ no declara ninguna unidad y cada importador aplica su propia suposición: metros en unos, centímetros o pulgadas en herramientas de CAD más veteranas. Comprueba una vez la caja envolvente contra una medida que conozcas, en lugar de descubrir el factor más tarde en una pieza impresa.

Porque no se escriben normales de vértice. El OBJ contiene solo líneas «v» y «f», así que cada programa calcula normales planas por cara al importar, y una superficie curva teselada en triángulos se ve como el caparazón poligonal que realmente es.

Se arregla en un paso: sombreado suave en Blender, o un ángulo de auto-suavizado en torno a los treinta grados. Conviene hacerlo junto con la asignación de un material, porque un modelo gris mate sobre el fondo del visor es difícil de juzgar y las dos correcciones son de dos clics cada una.

El búfer de índices del GLB pasa tal cual: cada entrada del accesor se convierte en una línea «v» en el mismo orden y cada índice en una entrada «f». En esta ruta no se fusiona nada, a diferencia de lo que ocurre al leer STL o PLY, donde los duplicados son la norma.

Eso importa cuando el GLB salió de un exportador real, porque glTF guarda una UV y una normal por vértice. Un vértice que cae sobre una costura de textura o sobre una arista dura tiene que estar duplicado dos o tres veces en la misma posición para que esos atributos difieran. Esas copias sobreviven al OBJ, donde los atributos que las justificaban ya no están, así que un modelo cerrado puede declarar aristas de contorno a lo largo de sus costuras. Fusionar por distancia lo resuelve en una orden.

El primero es cualquiera que use compresión Draco. Descomprimirla necesita un descodificador que no se distribuye aquí, así que la conversión se detiene con una frase que pide volver a exportar el fichero sin Draco, en lugar de devolver una malla vacía o rota.

El segundo es un glTF suelto que apunta a un .bin externo: sin ese fichero al lado no hay geometría que leer, y la respuesta es convertir el GLB, que lleva el búfer dentro. En la misma línea, solo se leen primitivas de triángulos; tiras, abanicos, líneas y nubes de puntos se saltan, y si un fichero no contiene ninguna otra cosa la conversión lo dice en vez de entregar un OBJ vacío.

El caso típico es un activo que nació para la web y tiene que entrar en un programa anterior a glTF: un importador de CAD, una versión veterana de Maya o 3ds Max, una utilidad de reparación de malla, un laminador. También aparece mucho en fotogrametría y digitalización de patrimonio, donde la cadena de herramientas es antigua, académica y habla OBJ, PLY y STL.

Para esos destinos la pérdida de materiales suele ser irrelevante, porque lo que interesa es la superficie: medirla, repararla, seccionarla o imprimirla. Y hay una ventaja que a veces es el motivo real de convertir: un OBJ es texto plano, un vértice por línea, así que se puede abrir, inspeccionar, buscar y comparar con herramientas corrientes, cosa que un GLB binario no permite.

Es la reacción habitual al ver el fichero resultante. Un GLB guarda cada coordenada en cuatro bytes binarios; un OBJ la escribe como texto decimal, con su signo, su punto y sus decimales, más un salto de línea por vértice. Para la misma geometría, eso multiplica el tamaño varias veces.

A cambio desaparecen las texturas, que en muchos modelos web eran la mayor parte del peso, así que la comparación total no siempre va en la misma dirección. Lo que sí es seguro es que la parte geométrica crece, y que un modelo denso —un escaneado, una malla de fotogrametría sin decimar— produce un fichero de texto incómodamente grande para enviar por correo.

Si el destino lee glTF, no conviertas. Blender, los motores de tiempo real, los visores de Windows y macOS y las bibliotecas web abren un GLB con sus materiales intactos, y pasarlo por OBJ te cuesta todos ellos a cambio de nada.

Cuando sí toca, el trabajo se hace en tu navegador: el GLB se lee, la escena se aplana y el OBJ se escribe en la propia pestaña, sin que el modelo salga de tu equipo. Para un encargo bajo acuerdo de confidencialidad o una pieza sin patentar todavía, eso no es una comodidad sino la condición para poder convertir.