Cómo convertir de glTF a GLB (modelos 3D en un solo archivo)
glTF vs. GLB: ¿Cuál es la diferencia real entre estos dos formatos?
En esencia, glTF y GLB son lo mismo. Están definidos por la misma especificación del Khronos Group y comparten estructuras de datos idénticas, soportando los mismos materiales PBR, animaciones y jerarquías de escena. La única diferencia real es el empaquetado. Un activo glTF estándar es toda una colección de archivos que deben permanecer juntos. Obtienes un archivo JSON .gltf legible por humanos que describe la escena, los materiales y la topología de la malla. Junto a él, encontrarás uno o más archivos .bin que contienen los datos brutos de la geometría: posiciones de los vértices, normales, UVs, etc. Luego hay una carpeta con las imágenes de las texturas, normalmente PNGs o JPEGs. Un modelo de personaje medianamente complejo podría distribuirse como character.gltf, character0.bin y una carpeta textures/ con diez imágenes. Si pierdes uno de esos archivos, el modelo simplemente no se cargará. GLB, por otro lado, es la versión de contenedor binario. Empaqueta de forma ordenada el JSON, los datos binarios y todas las texturas en un único archivo .glb. Todo se mantiene unido por una pequeña cabecera de 12 bytes que contiene un número mágico (0x46546C67, que es 'glTF' en ASCII), un campo de versión (actualmente 2) y la longitud total del archivo. El resto del archivo es solo una secuencia de fragmentos de datos. Esto hace que un archivo GLB sea completamente autocontenido. Puedes enviarlo por correo electrónico, soltarlo en un configurador de productos web o entregárselo a un cliente sin preocuparte por rutas rotas o texturas faltantes. El tamaño del archivo casi siempre está dentro del 1-3% del paquete original, por lo que no pagas ninguna penalización real de almacenamiento por esta inmensa comodidad.
Cuándo deberías convertir de glTF a GLB (y cuándo no)
Para la entrega final y el despliegue, mi opción por defecto es siempre GLB. La simplicidad de un único archivo autocontenido es demasiado buena como para dejarla pasar. Pero durante el desarrollo activo, mantener el formato glTF multifichero puede ser la opción más inteligente. El argumento a favor de GLB es más fuerte cuando estás desplegando un modelo en un visor web como model-viewer, Babylon.js o Three.js. Una única solicitud de búsqueda es siempre mejor que una cascada de llamadas de red para cada archivo binario y textura. Un GLB de 4 MB se cargará notablemente más rápido en una conexión móvil que el mismo modelo dividido en un .gltf de 120 KB, un .bin de 2.1 MB y seis texturas que suman 1.8 MB. ¿Por qué? Porque cada archivo separado requiere su propio viaje de ida y vuelta HTTP. También deberías convertir a GLB al distribuir a clientes o marketplaces; plataformas como la Unity Asset Store, Sketchfab y el pipeline AR Quick Look de Apple funcionan perfectamente con él. Entonces, ¿dónde brilla el glTF multifichero? Durante la creación de contenido. Si un artista de texturas está iterando en un mapa de rugosidad 2K, puede simplemente soltar un nuevo PNG en la carpeta de texturas y refrescar. Eso es mucho más rápido que reempaquetar todo el activo cada vez. La misma lógica se aplica a los sistemas de compilación automatizados. Si tu pipeline ejecuta compresión de texturas para generar variantes KTX2 o Basis Universal, es mucho más simple operar sobre archivos sueltos individuales que desempaquetar y reempaquetar un GLB en cada compilación. Y aquí hay una limitación clave que recordar: por diseño, GLB no puede hacer referencia a texturas externas. Si tu glTF original estaba configurado inteligentemente para enlazar a texturas en un CDN —un patrón para compartir atlas de texturas entre modelos—, convertirlo a GLB incrustará copias locales y romperá ese patrón de recursos compartidos.
Cómo convertir de glTF a GLB usando CocoConvert
Usar la herramienta de CocoConvert basada en el navegador es la forma más sencilla de obtener un GLB, ya que no requiere instalar ningún software. Todo el proceso funciona del lado del cliente para archivos de menos de 100 MB, lo que significa que tus valiosos datos de geometría y texturas nunca salen de tu ordenador. Paso 1: Prepara tus archivos. Un activo glTF es un paquete completo, por lo que necesitas subir todo junto. La única forma de hacerlo es comprimir en un solo archivo zip tu archivo .gltf, todos sus archivos .bin asociados y la carpeta completa de texturas. Es fundamental mantener intacta la estructura interna de carpetas. El archivo .gltf se basa en rutas relativas como ./textures/baseColor.png, y el convertidor necesita que esas rutas sean correctas dentro del zip. Paso 2: Abre el convertidor. Ve a /convert/gltf-to-glb y haz clic en el área de carga o simplemente arrastra tu archivo .zip a la página. La herramienta es lo suficientemente inteligente como para encontrar el punto de entrada de glTF automáticamente. Si por alguna razón tu zip contiene múltiples archivos .gltf (como variantes de LOD), aparecerá un menú desplegable para que puedas elegir el correcto para usar como raíz. Paso 3: Revisa las opciones de conversión. CocoConvert te ofrece un par de ajustes. 'Incrustar texturas' está activado por defecto, que es exactamente lo que quieres para un verdadero GLB de archivo único. Si lo desactivaras, el resultado haría referencia a URIs de texturas externas, anulando todo el propósito de la conversión. La otra opción es 'Aplanar búfer'. ¿Mi consejo? Déjalo activado. Fusiona múltiples archivos .bin en un único fragmento binario, que es el comportamiento estándar de GLB. Paso 4: Descarga. Eso es todo. La conversión suele tardar entre 5 y 20 segundos, dependiendo de cuántas texturas tengas y del tamaño total del archivo. Obtendrás un único archivo .glb, listo para desplegar.
Alternativa por línea de comandos: Usando gltf-pipeline para flujos de trabajo automatizados
Cuando estás convirtiendo docenas de modelos como parte de un pipeline de compilación, usar una interfaz web uno por uno simplemente no es práctico. Para cualquier tipo de flujo de trabajo automatizado, la herramienta de Node.js gltf-pipeline del equipo de Cesium es la opción de código abierto más fiable que existe. Primero, instálala globalmente con npm: `npm install -g gltf-pipeline`. Convertir un solo activo es entonces sencillo: `gltf-pipeline -i scene.gltf -o scene.glb`. El indicador -i apunta a tu archivo .gltf de entrada. A diferencia de una herramienta web, gltf-pipeline encuentra automáticamente los archivos .bin y las texturas asociadas en el mismo directorio, por lo que no es necesario comprimir nada en un zip. El indicador -b (de --binary) está implícito cuando tu nombre de archivo de salida termina en .glb, lo cual es una buena comodidad. Para procesar por lotes un directorio entero, un simple bucle de shell es tu amigo: `for f in models/*.gltf; do gltf-pipeline -i "$f" -o "${f%.gltf}.glb"; done`. El comando equivalente para Windows PowerShell es `Get-ChildItem -Filter *.gltf | ForEach-Object { gltf-pipeline -i $_.FullName -o ($_.FullName -replace '.gltf','.glb') }`. gltf-pipeline también soporta la compresión de mallas Draco con el indicador --draco.compressionLevel (valores de 0 a 10, por defecto 7). Para cualquier modelo con una malla densa, deberías activarlo sin dudarlo. Puede reducir drásticamente el tamaño de la geometría en un 60-80%. Un escaneo de 500,000 polígonos que ocupa 18 MB sin comprimir puede reducirse a unos 4 MB con el nivel 7 de Draco. El tiempo de decodificación ligeramente más largo en el navegador casi siempre vale la pena. La principal limitación de la herramienta es que no maneja la compresión de texturas (KTX2/Basis). Para eso, necesitarás un paso separado en tu pipeline usando una herramienta como toktx o basisu, ya sea antes o después de empaquetar el GLB.
Validando tu archivo GLB de salida antes del despliegue
No te saltes este paso. Un GLB que se abre perfectamente en un visor puede fallar silenciosamente en otro si contiene datos no conformes. Haz de la validación una parte estándar de tu proceso antes de entregar cualquier activo convertido. El Validador de glTF de Khronos es la referencia definitiva. Puedes usarlo en línea en validator.khronos.org; simplemente arrastra tu .glb a la página. Genera un informe JSON estructurado que detalla errores, advertencias y otra información. Los errores son críticos. Cosas como desajustes en el componentType de un accesor o vistas de búfer que exceden la longitud declarada del búfer harán que la mayoría de los cargadores rechacen el archivo al instante. Las advertencias son menos graves pero aun así vale la pena leerlas; una común como 'MESH_PRIMITIVE_UNUSED_TEXCOORD' solo significa que tienes un conjunto de UVs que ningún material está usando. Para pipelines automatizados, puedes instalar el validador como un paquete de Node: `npm install -g gltf-validator`. Luego ejecuta `gltf-validator scene.glb --stdout > report.json` y pasa ese informe a una comprobación de CI. Una compilación debería fallar sin lugar a dudas si el recuento de errores es mayor que cero. Más allá del estricto cumplimiento de la especificación, siempre haz una comprobación visual en al menos dos renderizadores diferentes. Recomiendo model-viewer (modelviewer.dev) y el Sandbox de Babylon.js (sandbox.babylonjs.com). Utilizan diferentes implementaciones de WebGL y son excelentes para exponer problemas sutiles de materiales. Cualquiera que haya lidiado con un mapa de normales que se veía bien en su herramienta DCC pero que misteriosamente aparecía invertido en la web conoce este sufrimiento. La especificación glTF requiere normales estilo OpenGL (Y hacia arriba), pero muchas herramientas exportan por defecto estilo DirectX (Y hacia abajo). Si tu iluminación parece tener protuberancias invertidas, invierte el canal verde de tu mapa de normales y vuelve a convertir.
Errores comunes de conversión y cómo solucionarlos
La mayoría de los errores de conversión de glTF a GLB son frustrantes pero, afortunadamente, tienen soluciones sencillas. Aquí están los problemas que surgen una y otra vez. Texturas faltantes en el archivo de salida: Este es el problema número uno. El culpable es casi siempre que las rutas URI de las texturas en el archivo .gltf no se resolvieron durante la conversión. Para depurar esto, abre tu .gltf en un editor de texto y busca el array de imágenes. Verás entradas como `"uri": "textures/Material_baseColor.png"`. Debes asegurarte de que esos archivos existan exactamente en esa ruta relativa dentro de tu archivo zip o directorio de trabajo. Recuerda que los separadores de ruta y las mayúsculas/minúsculas importan en los servidores: `Textures/BaseColor.png` no es lo mismo que `textures/baseColor.png`. Archivo de salida demasiado grande: Si tu GLB es inesperadamente grande, la causa son casi con toda seguridad tus texturas. Un único PNG RGBA de 4096×4096 puede ocupar 64 MB sin comprimir en memoria. Aunque el propio formato PNG utiliza compresión sin pérdidas, un GLB simplemente incrusta los bytes brutos del archivo PNG. Eso significa que tu textura PNG de 12 MB añade 12 MB al GLB. Para uso web, deberías considerar seriamente reducir la resolución de las texturas a 2048×2048 (la diferencia visual suele ser insignificante) o aplicar compresión KTX2 antes de empaquetar el GLB. Animaciones que no se reproducen: Si tu glTF de origen tenía animaciones esqueléticas pero han desaparecido en el GLB, es probable que los datos de la animación nunca se incluyeran. Algunos exportadores 3D escriben los datos de animación en un archivo .bin separado. Si ese archivo faltaba en tu entrada de conversión, los datos de la animación simplemente se han perdido. La solución es reexportar desde tu herramienta 3D, asegurándote de que todos los datos binarios se escriban en un único archivo .bin, y luego ejecutar la conversión de nuevo. CocoConvert mostrará una advertencia en su registro si detecta archivos referenciados que no pudo encontrar en tu archivo comprimido. Revisa siempre el registro antes de descargar.
Tamaño de archivo, rendimiento y qué esperar en proyectos reales
Dejemos la teoría y pasemos a la práctica. Las expectativas concretas son mejores que las promesas vagas, así que aquí tienes cómo es realmente el proceso de conversión para algunos activos típicos. Un modelo de mueble simple —una malla, dos materiales, cuatro texturas de 1K— podría empezar como un paquete glTF multifichero de 3.2 MB. Después de la conversión, se convierte en un GLB de 3.1 MB. Esa ligera reducción de tamaño proviene de eliminar los espacios en blanco del JSON y fusionar las cabeceras de los búferes. En un ordenador de escritorio con una conexión rápida, no notarás diferencia en el tiempo de carga. Pero en una conexión móvil 4G, ese GLB de archivo único comenzará a renderizarse entre 300 y 500 ms antes al evitar la sobrecarga de múltiples solicitudes HTTP. Ahora considera un personaje complejo con animación esquelética, 12 materiales y texturas 2K. Esto podría ser un paquete glTF de 28 MB. Como un GLB simple, es de unos 27.4 MB. Si añades compresión Draco para la geometría, podría bajar a unos 22 MB. Pero si primero aplicas compresión de texturas KTX2 Basis Universal, el GLB final podría ser tan pequeño como 9-11 MB. CocoConvert maneja perfectamente el empaquetado básico de glTF a GLB, pero actualmente no aplica Draco ni KTX2. Para esas optimizaciones avanzadas, necesitarás usar herramientas como gltf-pipeline y toktx en un paso separado. Para proyectos de RA, el tamaño del archivo es crítico. Tanto AR Quick Look de Apple como Scene Viewer de Google tienen límites documentados. Apple sugiere mantener los GLB por debajo de 20 MB para una carga fiable en una red móvil. El límite estricto de Google es de 200 MB, pero recomiendan mantenerse por debajo de 15 MB para un buen rendimiento. Si tu GLB convertido supera estos límites, no recurras inmediatamente a las herramientas de simplificación de geometría. Tu primer movimiento y el de mayor impacto es casi siempre la compresión de texturas. La conversión en sí en /convert/gltf-to-glb no tiene pérdidas con respecto a los datos 3D: la geometría, los materiales, las animaciones y la jerarquía de la escena se conservan exactamente. Lo que metes es lo que sacas, simplemente reempaquetado para una máxima portabilidad.