Convertir OBJ a GLTF

Casi todo lo útil de la cadena de herramientas 3D moderna toma glTF como entrada. gltf-transform poda, suelda, remuestrea y comprime; el validador de Khronos lo revisa; three.js y Babylon.js lo consumen; cualquier servicio de optimización de recursos lo da por supuesto. Un OBJ está fuera de todo eso, y el primer paso para meterlo dentro es producir un documento que esas herramientas acepten.

La razón de apuntar al .gltf y no al .glb en esta fase es que la forma JSON es la que puedes leer y modificar. Un GLB es el artefacto del final del proceso, cuando el material ya está bien y la pasada de compresión ya ha corrido. Esta página es para el principio, donde poder abrir el archivo en un editor vale más que poder servirlo en una sola petición.

Un bloque de recurso que declara la versión 2.0 y a Quinvert como generador, un índice de escena, una escena que lista todos los nodos, un nodo por malla, una malla por grupo del OBJ, y en cada malla una sola primitiva en modo de triángulos con un atributo de posición y un accesor de índices. Después, los accesores, las vistas de búfer y un único búfer.

Se escribe con sangría de dos espacios, lo que lo deja alrededor de un tercio más grande que minimizado y perfectamente legible sin pasar por un formateador. Para un documento que vas a editar ese es el valor por defecto correcto: minimizarlo después es un comando, y deshacer un JSON de cuarenta mil líneas sin formato no lo es.

El glTF admite tres formas de guardar los datos de vértices: un archivo .bin aparte, un URI de datos en base64 dentro del campo del búfer, o el bloque binario de un GLB. Una conversión produce un archivo, así que el URI de datos es la única opción que mantiene la salida autocontenida, y es la que se escribe. Nada tiene que quedarse al lado y ninguna ruta relativa puede romperse.

De ahí se siguen dos consecuencias. El archivo pesa aproximadamente un tercio más que esos mismos bytes en binario, porque el base64 cuesta cuatro caracteres por cada tres bytes: aceptable en un documento de trabajo y un desperdicio en producción. Y toda herramienta que lea glTF lo resuelve sin configuración especial, incluidos gltf-transform, el validador y three.js.

Conviene decirlo sin adornos porque es lo que decide si esta conversión te sirve. Lo que se convierte es dónde están los triángulos, y nada más. El lector del OBJ atiende a las líneas de vértice, de objeto, de grupo y de cara; las coordenadas de textura y las normales que pueda haber en el archivo no se leen, y el archivo MTL que acompaña al OBJ no se abre.

Así que la primitiva resultante tiene un atributo de posición y ninguno más: ni UV, ni normales, ni colores de vértice, ni cámaras, ni luces, ni animación, ni jerarquía de escena más allá de un nodo por malla. Un OBJ con texturas convertido aquí es un OBJ con texturas del que has extraído la forma. Si las UV eran el motivo de la conversión, el camino honesto es Blender y no esta página.

El documento no tiene lista de materiales, porque el MTL no se ha leído. Añadir uno son cuatro líneas: una lista de materiales con un objeto que contenga un bloque de metálico-rugosidad y un color base de cuatro números, y luego una propiedad de material en la primitiva que indique su índice.

Eso te da un modelo coloreado y correctamente iluminado en cualquier visor de glTF sin tocar la geometría. Las texturas son otro asunto, porque necesitan imágenes, muestreadores, texturas y —lo decisivo— unas coordenadas de textura que esta conversión no ha producido. Para eso hace falta volver a la herramienta de autoría.

Cada línea de objeto o de grupo abre un grupo nuevo, y cada grupo se convierte en una malla con nombre. Ese nombre es la única información no geométrica que atraviesa la conversión, y en un documento que vas a editar a mano es lo que marca la diferencia entre encontrar la pieza que buscabas y ponerte a contar nodos.

Un grupo sin nombre en el origen tampoco lo tiene en la salida: la malla se escribe sin propiedad de nombre, y el nodo que la referencia no lleva más que el índice de la malla, así que cualquier herramienta posterior tendrá que inventarse una etiqueta. Si el glTF se va a leer o editar después, pon nombres a los grupos en el OBJ primero: es una edición de texto fácil, y reconciliar mallas anónimas en el JSON después no lo es.

Las caras de cuatro o más esquinas se triangulan en abanico desde la primera esquina. Eso es correcto para cuadriláteros y polígonos convexos, que es lo que contienen estos archivos en la práctica, y puede producir triángulos superpuestos en una cara cóncava: una limitación que conviene conocer si tu OBJ salió de una herramienta que emite polígonos complicados.

Los índices de cara negativos se resuelven durante la lectura, porque cuentan hacia atrás desde el vértice más reciente y no pueden interpretarse fuera de orden. Después los vértices se sueldan por grupo con seis decimales de precisión, así que un grupo que solo usaba doce vértices de un archivo de cuatro mil lleva doce vértices al glTF y no cuatro mil.

Un archivo OBJ guarda números sueltos y no dice si son milímetros, centímetros o pulgadas: la escala es un acuerdo entre quien exportó el modelo y quien lo abre. La especificación de glTF, en cambio, define que una unidad es un metro, precisamente para que los visores y los motores no tengan que adivinar.

Esta conversión no reescala nada: las coordenadas se copian tal cual del OBJ al búfer. Así que un modelo exportado en milímetros llega al glTF midiendo mil veces lo que debería y aparece gigantesco en el primer visor que lo abra. La corrección es una escala en el nodo o en la herramienta de destino, y saber que hace falta antes de abrirlo evita el susto de un modelo que parece haberse convertido mal cuando lo que ha ocurrido es que ahora sí tiene unidades.

La salida está escrita contra las partes de la especificación que los validadores comprueban de verdad. Las vistas de búfer se rellenan para que el desplazamiento de cada accesor sea múltiplo del tamaño de su componente, que es un requisito y no una cortesía, y una causa habitual de errores en escritores caseros. Cada accesor de posición lleva su mínimo y su máximo, que también es obligatorio y que los visores usan para encuadrar el modelo.

Si pasas el resultado por el validador de Khronos, lo interesante no serán los errores sino un aviso de nivel informativo diciendo que las mallas no tienen normales. Es cierto, y la especificación lo resuelve indicando a los visores que calculen normales planas.

El inflado del base64 sobre el búfer, más el JSON con sangría alrededor. En un modelo que solo lleva geometría el búfer domina, así que cuenta con alrededor de un tercio más de bytes que el mismo modelo como GLB, antes de aplicar ninguna compresión.

Ese es el intercambio correcto en este punto del proceso y el equivocado al final. La forma habitual del trabajo es: convertir a glTF aquí, editarlo o procesarlo, y producir el GLB como artefacto final, ya sea convirtiéndolo de vuelta o dejando que lo escriba gltf-transform, que es además donde corresponde aplicar Draco o meshopt.

Si entre la conversión y la entrega no va a pasar nada, ve directo al GLB. Es más pequeño, es una sola petición, y la editabilidad que estás pagando con los bytes extra no vale nada si nadie va a abrir el archivo.

Elige glTF cuando haya un paso siguiente: un material que añadir, un validador que satisfacer, una pasada de transformación que ejecutar, o un repositorio donde un archivo de texto se diferencia línea a línea y uno binario no. Las dos conversiones se ejecutan enteras en tu navegador, sin ningún motor pesado que descargar y sin subir nada, con un tope de 100 MB por archivo. Así que la elección no cuesta más que la extensión.