Convertir STL a GLB

Tres situaciones cubren casi todas las llegadas a esta página. Un formulario de subida —de una ficha de producto, de una plataforma de documentación, de un gestor de contenidos— que enumera `.glb` porque es lo que carga el componente visor que lleva dentro. Un cliente, un compañero o un profesor que tiene que ver la pieza y no tiene laminador ni programa de CAD ni la menor intención de instalar ninguno. Y una función de vista previa o de realidad aumentada construida alrededor de glTF, que es lo que la web acabó estandarizando.

En ninguna de las tres está la persona montando una aplicación tridimensional. Quiere un archivo que se abra al otro lado, que enseñe la forma, esta tarde. Conviene sostener ese encuadre, porque casi todo lo que se escribe sobre glTF está pensado para quien ensambla escenas y responde preguntas que este lector no tiene.

Un GLB es el mismo documento glTF con los datos de vértices pegados detrás: una cabecera de doce bytes cuyos primeros cuatro deletrean `glTF`, después un trozo con el JSON y después un trozo con el binario, cada uno rellenado hasta un múltiplo de cuatro bytes como pide la especificación. Un archivo, una petición, nada al lado.

Eso importa frente a la otra salida de este sitio. Convertir el mismo STL a `.gltf` también produce un archivo suelto, pero tiene que llevar los datos de vértices como un URI de datos en base64 dentro del JSON, y base64 gasta cuatro caracteres por cada tres bytes: alrededor de un tercio más, con el JSON indentado encima. El GLB guarda esos mismos bytes en crudo. Si el archivo lo va a descargar alguien, esta es la versión que hay que mandar.

Un STL no tiene color, ni textura, ni coordenadas de textura, ni colores por vértice, y el conversor escribe una primitiva con un accesor de posiciones, un accesor de índices y ninguna referencia a material. Lo que aparece en pantalla lo produce enteramente el visor con sus valores por defecto.

De ahí que el mismo archivo parezca un objeto sólido y bien iluminado en un visor y una mancha gris en otro. El arreglo es de iluminación y no de conversión: `model-viewer` trae iluminación de entorno neutra y un atributo de intensidad de sombra, y poner los dos son dos atributos y cambia el resultado por completo. En three.js, un mapa de entorno más una luz hemisférica hacen lo mismo. Si la pieza necesita un color de verdad, se le añade un material al glTF después con `gltf-transform`: es una edición pequeña sobre un documento que por lo demás está completo.

Es lo que más veces hace pensar que algo salió mal. Los programas de CAD y el mundo entero de la impresión trabajan con Z hacia arriba: la bandeja es el plano XY y la altura es Z. glTF define Y como el eje vertical y todos los visores lo respetan. Aquí no se rota nada, porque inventarse una rotación sería adivinar qué convención seguía el origen, y adivinar sobre un archivo que quizá acabe en una impresora es peor que dejarlo quieto.

Así que una pieza exportada desde Fusion, SolidWorks, FreeCAD o un laminador llega al visor girada noventa grados sobre su espalda. Corrígelo en la escena y no en el archivo: `model-viewer` admite un atributo de orientación y en three.js es una línea sobre la rotación en X del objeto. Hacerlo en el visor mantiene el GLB coincidiendo con el STL, que es lo que importa si esa misma geometría va después a imprimirse.

Ninguno de los dos formatos declara una unidad. El STL lo lee en milímetros cualquier laminador que se haya escrito nunca; glTF se crea dando por hecho que una unidad es un metro. Los números pasan sin tocarse, así que un soporte de 60 mm se convierte en un objeto de sesenta unidades, que un visor calibrado en metros dibuja como un soporte de sesenta metros y encuadra desde muy lejos.

Divide por mil en la escena y compruébalo contra una medida que puedas verificar en vez de a ojo: `model-viewer` tiene un atributo de escala y three.js una llamada para fijar una escala uniforme. Y si el visor se ve correcto sin escalar nada, lo probable es que el STL no estuviera en milímetros, cosa que merece la pena descubrir antes de que la pieza vaya a una impresora y no después.

Un STL guarda cada triángulo con sus tres vértices independientes y sin compartir ninguno, así que un cubo llega con treinta y seis posiciones donde bastarían ocho. El lector fusiona primero los vértices coincidentes comparándolos a seis decimales, porque dos triángulos que se tocan en una arista discrepan rutinariamente en el último bit de un número en coma flotante.

Para un archivo pensado para entregar eso no es un detalle estético. La forma sin fusionar metería entre cuatro y seis veces más vértices en el búfer y por tanto en la descarga, y además rompería el sombreado suave, porque un visor que promedia normales necesita vértices compartidos para poder promediar. El resultado es un GLB cuya geometría es a la vez más pequeña y mejor educada que la de una reescritura ingenua.

Todo lo que se encuentra en el STL se escribe como una sola malla con una sola primitiva, porque un STL no tiene grupos que conservar. Es el modelo más barato que se le puede dar a un motor de dibujo —una llamada, ningún cambio de material—, y es exactamente la forma correcta para una pieza en una ficha de producto o en un panel de vista previa.

La primitiva usa índices de treinta y dos bits sin signo y posiciones en coma flotante de treinta y dos bits en todos los casos. Existen tipos de índice más estrechos que ahorrarían algo en un modelo pequeño, pero una malla que pasa de 65.535 vértices necesita entonces otro tipo distinto, y esa condición es fácil de equivocar por unos pocos kilobytes. El accesor de posiciones lleva sus valores mínimo y máximo como exige la especificación, y eso es lo que permite al visor encuadrar el modelo al cargarlo en vez de abrirse mirando a la nada.

Este es el caso silenciosamente útil, y en talleres, fablabs y aulas de tecnología es el habitual. Alguien tiene que ver una pieza y no tiene programa para ello: mandarle un STL es explicarle qué instalar, y mandarle una captura es quitarle la posibilidad de girarla. Un GLB se abre en un visor dentro del navegador sin instalar nada, y cualquier móvil u ordenador actual puede dibujar uno desde una página.

Qué conviene mandar con él: las medidas reales, en una frase, porque el archivo no las lleva y el visor enseñará la escala que le pongas. Y una nota sobre la orientación si importa. Dos líneas de contexto convierten un objeto gris flotando en un visor en una pieza sobre la que alguien puede opinar.

Normalmente bastante menos. Un STL binario mide exactamente ochenta y cuatro bytes más cincuenta por triángulo, venga de donde venga, y no comparte nada; el GLB guarda cada vértice una sola vez en doce bytes y cada índice en cuatro. En una malla cerrada, donde cada vértice sirve a cinco o seis triángulos, esa diferencia es la mayor parte del archivo.

El techo gratuito son 100 MB, que a cincuenta bytes por triángulo son unos dos millones de triángulos. Mucho antes de llegar ahí un modelo se vuelve incómodo de cargar en un navegador: unos cuantos cientos de miles de triángulos es un límite sensato para algo que alguien va a abrir en un móvil. Si el STL es más denso que eso, reduce la malla antes de convertir.

El STL binario y el de texto comparten extensión y el archivo no dice cuál es. La prueba habitual —mirar si empieza por la palabra `solid`— no es fiable, porque la cabecera de ochenta bytes de un STL binario puede contener cualquier texto y varios programas ponen justo esa palabra ahí.

La prueba que sí funciona es una cuenta: un STL binario mide exactamente ochenta y cuatro bytes más cincuenta por el número de triángulos que anuncia su propia cabecera, y ninguna otra cosa mide eso. Es la que usa este conversor. Si la longitud no cuadra, el archivo se lee como texto y se interpretan sus líneas de vértices. Por cualquiera de los dos caminos el modelo llega a la misma forma fusionada antes de escribirse el GLB.

La conversión es JavaScript corriente en esta misma pestaña: no hay ningún módulo de WebAssembly que descargar, ninguna petición que lleve el modelo, ninguna cuenta y ningún cupo diario. La pestaña de red de las herramientas de desarrollo lo enseña mientras conviertes, y esa comprobación tarda diez segundos.

Es el punto relevante para una pieza que se prepara para una ficha o para la revisión de un cliente, porque con mucha frecuencia el modelo no está publicado y con mucha frecuencia es de otra persona. Una conversión que nunca transmite la geometría elimina la pregunta entera en lugar de responderla con una política de privacidad. Se admiten hasta cien archivos por tanda; si sueltas más, los que sobran se descartan sin avisar.