Convertir GLTF a OBJ

Los dos formatos son texto, y ese parecido despista. Al abrir un `.gltf` te encuentras un documento JSON en el que los datos de vértices son una cadena en base64 dentro de un búfer, troceada por desplazamientos de bytes que registran las vistas de búfer, e interpretada por accesores que declaran un tipo de componente y un tipo de elemento. Hay cuatro indirecciones entre el archivo y una coordenada, y sacar una a mano es genuinamente tedioso.

Un OBJ no tiene nada de eso. Una línea que empieza por `v` es un vértice y los tres números que siguen son sus coordenadas. Una línea que empieza por `f` es un triángulo y los tres números que siguen son índices dentro de la lista de vértices. Esa es toda la gramática que hace falta para la geometría, y es la razón por la que el OBJ ha sobrevivido a todos los formatos diseñados para sustituirlo siempre que la tarea es inspeccionar y no representar.

Una sola línea de comentario arriba que nombra al escritor, y después, por cada malla: una línea `o` con el nombre que la malla tenía en el glTF, una tanda de líneas `v` y una tanda de líneas `f`. No aparece nada más: ni coordenadas de textura `vt`, ni normales `vn`, ni grupos de suavizado `s`, ni `usemtl`, ni `mtllib`, ni líneas en blanco separadoras que despisten a un lector ingenuo.

Eso hace que el analizador que escribirías para leerlo ocupe unas seis líneas, y hace directamente útiles herramientas como `wc`, `grep` y `awk`. Contar líneas `f` da el número de triángulos; contar líneas `v` da el de vértices. Si vas a consumir esta salida con código, ten en cuenta que los números se imprimen con el formato de coma flotante propio de JavaScript, así que verás `1` y `1.0000001` en el mismo archivo: analiza, no compares patrones.

Los índices de cara del OBJ empiezan en uno. Además corren de forma continua por el archivo entero en lugar de reiniciarse en cada grupo `o`, que es el detalle que más analizadores caseros se comen. El conversor lleva un desplazamiento acumulado de vértices mientras escribe cada malla y se lo suma a todos los índices de esa malla.

Si vas a leer el archivo de vuelta, la regla es: acumula el número de líneas `v` vistas hasta ese punto y resta uno para obtener un índice desde cero. Los índices negativos son legales en OBJ y cuentan hacia atrás desde el último vértice; este escritor no los emite nunca, aunque el lector de las páginas inversas sí los acepta, porque bastantes exportadores los usan.

Un árbol de nodos de glTF puede colocar una malla en cualquier sitio mediante una cadena de matrices, e incluso colocar la misma malla en varios sitios a la vez. El OBJ no tiene grafo de escena ni instanciación, así que la conversión resuelve el árbol: cada matriz de nodo se compone con la de su padre y la matriz de mundo resultante se aplica a cada vértice antes de escribirlo.

Para quien va a medir el resultado eso es una buena noticia, porque los números que lees son donde la geometría está de verdad y no donde estaría antes de una transformación. Para el tamaño del archivo significa que las instancias repetidas se convierten en datos repetidos: un glTF que coloca un mismo tornillo cuarenta veces produce cuarenta grupos de forma idéntica en cuarenta posiciones distintas.

Materiales, texturas, imágenes, muestreadores, coordenadas UV, normales, tangentes, colores por vértice, objetivos de deformación, esqueletos, canales y muestreadores de animación, cámaras, luces y cualquier extensión que el archivo declare. Nada de eso se lee y nada de eso se escribe. Lo que cruza es la geometría de triángulos, el nombre de cada malla y las transformaciones de nodo ya cocidas en los vértices.

El OBJ podría en principio llevar las UV y las normales, y un MTL aparte podría llevar una referencia de material. Este conversor no escribe ninguna de las dos cosas, porque mueve geometría entre varios formatos y fabricar un archivo de materiales a partir de datos que nunca extrajo sería peor que omitirlo. Si necesitas conservar las coordenadas de textura, este no es el camino.

Las primitivas de glTF declaran un modo. El modo 4, la lista de triángulos, es el único que se lee: puntos, líneas, bucles de línea, tiras de línea, tiras de triángulos y abanicos se saltan. Un archivo que no contenga más que geometría de líneas termina con un mensaje diciendo que no se encontró geometría de triángulos, que es más útil que un OBJ vacío.

La geometría comprimida con Draco se detiene con un mensaje que nombra a Draco, porque el descodificador de esa extensión no se distribuye aquí. Si tu glTF salió de una tubería de exportación optimizada para peso, esa es la causa más probable de que no convierta, y volver a exportar sin Draco es una casilla en cualquier herramienta que lo aplique.

El formato admite dos disposiciones: un `.gltf` que incrusta su búfer como URI de datos en base64, y un `.gltf` que remite a un `.bin` externo al lado. La segunda es la que escriben muchos exportadores por defecto y es la que se rechaza, con un mensaje que dice qué hacer.

El motivo es que un conversor de un solo archivo no puede seguir la referencia: el navegador recibe el que has soltado y no puede ir a buscar el vecino, y aunque pudiera, no sabría si es el correcto. Las dos salidas son volver a exportar con los búferes incrustados o convertir el `.glb`, que es el mismo contenido en un contenedor binario autocontenido.

Coinciden exactamente, malla por malla. En este camino no se fusiona nada: el accesor POSITION se descodifica elemento a elemento en líneas `v` en el mismo orden, y el accesor de índices se convierte en entradas `f` que apuntan a ellas. El paso de fusión que colapsa coordenadas coincidentes se usa al leer STL y OBJ, donde los vértices no compartidos son la norma, y no se aplica a un glTF que ya trae un búfer de índices.

Eso hace del recuento una verificación utilizable: si tu herramienta declaraba 48.213 vértices y el OBJ tiene 48.213 líneas `v`, no se ha saltado nada. También significa que los vértices coincidentes sobreviven, porque los exportadores parten un vértice allí donde dos caras necesitan UV o normales distintas, y esos duplicados llegan como líneas `v` separadas en coordenadas idénticas. Una superficie cerrada puede entonces declarar aristas de borde a lo largo de sus costuras: si tu análisis depende de la adyacencia, fusiona por distancia antes.

Buena parte de los glTF que circulan en español no vienen de un videojuego sino de un escaneo: un capitel, un retablo, una portada, una pieza de un museo provincial, un hallazgo de una excavación. Se distribuyen en glTF porque es lo que se ve en un visor web, y quien tiene que trabajar con ellos casi nunca quiere verlos: quiere medirlos, compararlos con el levantamiento del año pasado o contarlos.

Para eso el OBJ es mejor archivo que el glTF, no peor. Un `.obj` de este conversor es un listado de puntos en coordenadas de mundo que se abre en un editor de texto, se carga en un script de Python en tres líneas y se puede diferenciar con las mismas herramientas que un código fuente. Lo que se pierde —el color, la textura del escaneo, el aspecto— es justamente lo que no interviene en una medición.

Una coordenada float32 ocupa cuatro bytes en un búfer de glTF. Ese mismo número escrito como texto decimal ocupa habitualmente entre ocho y dieciocho caracteres más un separador, así que el OBJ es varias veces mayor que la parte geométrica del glTF incluso contando el inflado del base64. Un modelo de un millón de triángulos es un archivo de texto grande, y conviene esperarlo.

La precisión se conserva en lugar de truncarse: los valores se imprimen con los dígitos que JavaScript necesita para reproducir exactamente el número, de modo que nada se redondea en silencio al salir. El único redondeo de la tubería es la clave a seis decimales que se usa al fusionar vértices, y esa decide qué vértices son el mismo, no cuáles son sus coordenadas.

Si vas a representar el modelo, quédate con el glTF. Todo lo que hace que merezca la pena mirarlo —materiales, texturas, animación— está en las partes que esta conversión descarta, y cualquier visor moderno lo lee directamente sin intermediarios.

Convierte cuando el modelo es un dato y no un activo: cuando necesitas un recuento de triángulos del que te fíes, una caja envolvente que hayas medido tú, una diferencia entre dos exportaciones de la misma pieza, o una entrada para código que has escrito. Es una razón estrecha y es real, y es la única para la que está escrita esta página.