Convertir OBJ a GLB

Conviene empezar por el límite, porque decide si esta página te sirve. Lo que se convierte aquí es dónde están los triángulos. La forma intermedia por la que pasa todo modelo tiene sitio para una lista de vértices, una lista de índices y un nombre: no hay ningún hueco donde poner un color, una coordenada de textura, una normal ni un fotograma de animación.

Así que se quedan fuera los materiales, las texturas y sus coordenadas, las normales, los colores por vértice, las cámaras, las luces, las animaciones, los esqueletos y el propio grafo de escena. Si tu entregable es una pieza que hay que ver como forma, esto es exactamente lo que necesitas. Si tu entregable es una pieza texturizada, esta no es la ruta y más abajo está la que sí.

Ningún navegador lee OBJ, y tampoco lee GLB de forma nativa: un .glb al que navegas directamente se descarga en lugar de dibujarse. Lo que cambia es el ecosistema de bibliotecas. Los visores que se usan hoy toman un GLB como entrada principal y lo cargan en una sola petición, mientras que el soporte de OBJ es un cargador secundario que además necesita el MTL y cada textura como peticiones aparte.

De modo que la pregunta práctica no es qué formato entiende el navegador sino cuál espera el motor que estás a punto de incluir. Para casi todo lo publicado en los últimos años la respuesta es GLB, y en una ficha de producto o en una pieza de museo donde el modelo es el contenido, juntar cuatro o cinco peticiones en una se nota de verdad en un móvil.

Un archivo OBJ no contiene materiales. Contiene una línea que nombra un .mtl que está a su lado y unas líneas que van cambiando entre las entradas de ese archivo, y es el .mtl el que guarda el color difuso, los valores especulares y las rutas de las imágenes de textura. Este conversor lee las líneas de vértice, de objeto, de grupo y de cara, e ignora el resto.

La consecuencia es inequívoca y hay que planificar con ella: tu GLB contiene geometría y nombres de grupo, y el visor lo dibuja con el material por defecto que tenga, que en la mayoría de los casos es un gris mate. Si el modelo se iba a enseñar con sus texturas, el camino es un programa de modelado: importa el OBJ con su MTL y exporta glTF binario, que empaqueta las imágenes dentro del GLB.

Un glTF 2.0 binario: cabecera de doce bytes, un bloque JSON rellenado con espacios hasta un múltiplo de cuatro y después un bloque binario rellenado con ceros. Dentro del JSON, una malla por grupo del OBJ, un nodo por malla, una escena que los enumera todos, la versión 2.0 del formato y, por malla, un accesor de posiciones en coma flotante de 32 bits y un accesor de índices enteros de 32 bits.

Cada accesor de posiciones lleva escritos su mínimo y su máximo. Es un requisito de la especificación y es además la diferencia práctica entre un modelo que aparece al cargarlo y uno que no: los visores calculan la distancia inicial de la cámara a partir de esos límites, y los archivos escritos sin ellos son una causa habitual de una escena aparentemente vacía.

El lector abre un grupo nuevo en cada línea de objeto o de grupo, y el escritor emite una malla de glTF por cada uno, con su propio nodo y su propia primitiva. Un OBJ exportado desde un programa de CAD con un grupo por parche de superficie puede llevar cientos de grupos, y el GLB contendrá fielmente cientos de mallas.

En una página eso es un coste real: cada primitiva es una llamada de dibujo y una vinculación de búfer distintas, y unos cuantos cientos en un móvil de gama media es donde se cae la fluidez. Unir los objetos en el programa de modelado antes de exportar el OBJ, o quitar las líneas de grupo con un editor de texto si no significan nada, es un arreglo de dos minutos que vale más que casi todo lo que venga después.

No se escribe ningún atributo de normales. La especificación de glTF es explícita sobre qué debe hacer entonces un visor: calcular normales planas por cara. De modo que una superficie que se veía suave en tu programa de modelado se dibuja en el navegador con cada triángulo visible como una faceta, lo que se lee como un estilo de baja poligonización deliberado y casi nunca lo es.

Hay dos arreglos limpios. En el visor, pedirle que calcule las normales por vértice, que promedia las normales de cara y necesita que la malla esté correctamente soldada —lo está, porque las posiciones se unifican durante la conversión—. O hacer el paso de normales antes, en el programa de modelado, y exportar glTF desde allí, lo que además trae los materiales.

glTF fija las dos: es dextrógiro, con la Y hacia arriba, y su unidad lineal es el metro. Un OBJ no fija ninguna: es una lista de números sin cabecera, sin unidad y sin convenio de ejes, y cada programa que escribe uno tiene su propia costumbre.

Aquí no se aplica ninguna transformación, así que un OBJ con la Z hacia arriba produce un GLB cuyo modelo aparece tumbado de espaldas, y un OBJ modelado en centímetros produce uno de doscientos metros de alto. Los dos se arreglan en un momento cuando sabes cuál tienes —un giro de menos noventa grados sobre X y una escala uniforme— y los dos son invisibles hasta que cargas el archivo. Comparar la caja de límites con una medida que conozcas es el diagnóstico más rápido.

Las caras de más de tres esquinas se triangulan en abanico desde la primera esquina, lo que es correcto para los cuadriláteros y polígonos convexos que estos archivos suelen contener y puede producir triángulos superpuestos en una cara cóncava. Los índices negativos, que cuentan hacia atrás desde el vértice más reciente, se resuelven mientras se lee el archivo y no después, porque su significado depende de la posición en el fichero.

Después las posiciones se sueldan: se comparan con seis decimales, de modo que una coordenada que aparece en veinte triángulos se guarda una vez y se referencia veinte veces. Eso encoge el búfer y le da al navegador una malla cuya adyacencia es real, que es lo que hace que el cálculo de normales suaves funcione en lugar de devolver el mismo resultado facetado.

Doce bytes por vértice para las posiciones y doce bytes por triángulo para los índices, más una cabecera JSON pequeña. Un modelo de 200.000 triángulos con 100.000 vértices sale por tanto alrededor de 3,6 MB, y nada de eso va comprimido. Los índices son de 32 bits sin excepción, lo que cuesta cuatro bytes donde bastarían dos por debajo de 65.535 vértices y a cambio elimina una condición que cambiaría el comportamiento en silencio al cruzar ese umbral.

Si esa cifra es demasiado para tu página, las respuestas están antes y después, no aquí: reduce la malla en tu programa de modelado primero, y aplica una compresión de geometría con una herramienta de línea de órdenes después, recordando que eso obliga al navegador a cargar el descodificador correspondiente, que es su propio coste en una página que enseña un solo modelo.

Un escaneo por fotogrametría de una pieza —un capitel, una vasija, una herramienta de un museo etnográfico, una talla— llega casi siempre como OBJ con su MTL y su textura al lado, y esa textura suele ser el archivo más pesado del conjunto. Cuando lo que quieres publicar es la forma para que alguien pueda girarla, medirla o compararla, este camino te da un solo archivo pequeño y bien encuadrado.

Cuando lo que quieres publicar es la pieza con su color, no. La textura fotográfica es en ese caso la mitad del dato, y hay que pasar por un programa que la incruste. Merece la pena decidirlo antes de convertir doscientas piezas: son dos flujos de trabajo distintos y el segundo no se improvisa a partir del primero.

Si el modelo necesita sus texturas, convierte pasando por un programa de modelado para que el MTL y sus imágenes vengan con él. Si el modelo tiene medio millón de triángulos, redúcelo antes de convertir en lugar de publicarlo y esperar. Si necesitas que se vea suave, resuelve las normales en el visor o en el exportador, porque por esta ruta no vas a obtener ninguna.

Para lo que sí sirve esta página es para el caso intermedio honesto: un OBJ limpio de una pieza, un accesorio o un escaneo que tiene que aparecer en una página como forma, en un archivo, sin subir el modelo a nadie. Esa conversión ocurre entera en tu navegador, sin ningún motor que descargar y con un tope de 100 MB por archivo, y produce un fichero que cualquier visor web actual acepta.