Convertir STL a GLTF

Ningún navegador dibuja un STL, y tampoco dibuja un glTF: los dos necesitan una biblioteca por encima. Lo que cambia es la calidad del camino. three.js incluye un cargador de STL, así que la respuesta ingenua es servir el STL y olvidarse, y para una herramienta interna de un solo uso esa respuesta es razonable.

Deja de serlo en cuanto la página es pública y el modelo es el contenido. Un STL es la forma menos eficiente de mover una malla por una conexión que existe de verdad, no lleva límites, de modo que la cámara hay que calcularla después de analizar el archivo entero, y cada triángulo llega con sus tres vértices propios para que la tarjeta gráfica los deduplique o no. glTF se diseñó exactamente para ese transporte y resuelve las tres cosas.

Merece la pena saber qué vas a abrir si lo inspeccionas. El bloque `asset` declara la versión 2.0 y anota Quinvert como generador. Debajo hay una escena, un nodo por malla, una malla con una única primitiva en modo triángulos, un accesor de posiciones de tipo VEC3 en coma flotante de treinta y dos bits y un accesor de índices escalar de treinta y dos bits sin signo. Nada más.

Esa brevedad es una propiedad, no una carencia. Un glTF salido de un exportador de CAD suele traer cientos de nodos, materiales heredados y extensiones que ninguna de tus herramientas lee; este documento cabe en una pantalla y se puede validar de un vistazo. Si tu cadena de compilación pasa por un validador de glTF, este archivo es de los que no dan trabajo.

El accesor de posiciones se escribe con sus valores mínimo y máximo por eje, que la especificación exige y que en la práctica son la diferencia entre un modelo que se ve y uno que no. Tanto `model-viewer` como three.js deducen de esos seis números la distancia inicial de la cámara.

Un archivo escrito sin ellos se abre con la cámara pegada a la nada, y ese fallo es indistinguible de una carga rota hasta que abres el JSON y miras. Es el motivo número uno por el que alguien concluye que su conversor «no funciona» cuando en realidad el modelo está ahí, a diez mil unidades del punto donde la cámara se colocó por no tener nada mejor.

No se escribe ningún atributo de normales, y la especificación de glTF indica que en ese caso el visor calcule normales planas por cara. En un modelo orgánico traído de una herramienta de escultura eso sería un defecto y la gente pregunta cómo arreglarlo. En una pieza que salió de un CAD como STL es la verdad.

Un STL no tiene superficies curvas. Tiene los triángulos que el exportador produjo con la tolerancia de cuerda que estuviera puesta, y dibujarlos con sombreado suave es una mentira favorecedora sobre la geometría que una impresora va a reproducir. Si quieres que la vista previa se vea más suave, el arreglo honesto está aguas arriba: vuelve a exportar el STL con una tolerancia más fina para que haya más triángulos, en lugar de promediar normales para disimular las que hay.

Un STL binario mide exactamente ochenta y cuatro bytes más cincuenta por triángulo, sea cual sea la forma. De esos cincuenta, doce son una normal de cara, treinta y seis son tres vértices completos y dos no se usan. No se comparte nada: un cubo son treinta y seis registros de vértice para ocho esquinas distintas.

La conversión redondea las coordenadas a seis decimales para construir una clave y funde en un solo vértice todas las esquinas que están en la misma posición. Sobre una superficie cerrada cada vértice sirve típicamente a cinco o seis triángulos, así que los datos de posición caen aproximadamente en esa proporción antes de escribirse en coma flotante de treinta y dos bits. Súmale doce bytes de índices por triángulo y la geometría del glTF queda claramente por debajo del STL en cualquier malla que esté realmente cerrada.

El `.gltf` que se escribe aquí lleva su búfer incrustado como URI de datos en base64, de modo que no hay ningún `.bin` que servir al lado ni ninguna ruta relativa que se rompa al mover el archivo. Base64 cuesta cuatro caracteres por cada tres bytes, así que esa comodidad son alrededor de un treinta y tres por ciento más de bytes, con JSON indentado encima.

La regla práctica es limpia. Para el archivo que vas a inspeccionar, versionar, comparar o pasar por `gltf-transform` en tiempo de compilación, coge el glTF. Para el archivo que descarga la visitante, coge el GLB: la misma geometría, los mismos límites, el búfer en binario y una sola petición. Convertir el STL a uno o a otro es aquí la misma operación y la extensión es toda la diferencia.

Las dos discrepancias clásicas llegan intactas porque las coordenadas se copian sin tocar, y eso es deliberado: reescalar por un factor que el origen nunca declaró sería adivinar. glTF 2.0 define su unidad lineal como el metro y el mundo de la ingeniería y la impresión lee los números de un STL como milímetros, así que una pieza de 60 mm se convierte en una pieza de sesenta metros. Y el CAD trabaja con Z hacia arriba mientras glTF y todos sus visores usan Y.

En un catálogo con cientos de piezas eso no se arregla archivo por archivo. Aplica una escala uniforme de una milésima y la rotación sobre X una sola vez, en el nodo, con `gltf-transform` dentro de tu proceso de compilación, y deja el modelo convertido tal como salió. Así el archivo sigue coincidiendo con el STL que va a la impresora y la corrección vive en un sitio donde se puede leer y cambiar.

Como un STL no tiene piezas, grupos ni objetos, el glTF contiene exactamente una primitiva. Eso es lo más barato que se le puede pedir a un motor de dibujo y significa que un modelo procedente de un STL nunca sufre el problema de llamadas de dibujo que crea una exportación de CAD con trescientos grupos.

Tampoco lleva material, ni textura, ni coordenadas de textura, ni colores por vértice, porque el STL no tenía ninguna de esas cosas. Tu visor aplicará su material por defecto, que suele ser un gris medio de tipo físico. Asignar algo mejor en three.js es una línea y merece la pena: una pieza técnica se lee muchísimo mejor con un material ligeramente metálico y un mapa de entorno que con el gris de fábrica.

Si alguna vez vuelves en la otra dirección, conviene conocer tres negativas explícitas. Un glTF que guarda su geometría en un `.bin` externo se rechaza con un mensaje que te dice que conviertas el `.glb` en su lugar, porque una conversión de un solo archivo no puede ir a buscar un segundo. La compresión Draco se rechaza también. Y solo se leen primitivas de triángulos: las tiras, los abanicos, las líneas y los puntos se saltan.

Son negativas con mensaje y no fallos silenciosos, que es la diferencia que importa cuando esto vive dentro de una cadena automatizada. Merece la pena tenerlo presente si estás pensando en aplicar Draco al glTF que sale de aquí para servirlo más pequeño: hazlo al final del proceso, sobre el archivo que se publica, y conserva la versión sin comprimir como la que puede volver a entrar.

Este conversor traslada geometría —dónde están los triángulos— y nada más. No hay materiales, ni texturas, ni coordenadas de textura, ni normales de autor, ni colores por vértice, ni cámaras, ni luces, ni animaciones, ni esqueletos, ni objetivos de deformación, ni grafo de escena. Con un STL como origen eso no cuesta nada, porque el STL tampoco llevaba ninguna de esas cosas.

Donde sí importa es al planificar el catálogo. Si dentro de un año quieres que las piezas aparezcan con acabados, con explosionados o con una animación de montaje, esa información no va a venir del archivo de impresión: tendrá que salir del CAD original por otra ruta. Conviene decidirlo antes de construir el visor alrededor de la suposición contraria.

En ninguna parte más que en tu equipo. El par funciona como JavaScript corriente dentro de la página: no hay motor de WebAssembly que descargar, ni petición que lleve el modelo, ni cola. Importa más de lo habitual en este par, porque los STL que se convierten para una vista previa web son con frecuencia la pieza de un cliente o un producto sin anunciar, y un servicio de impresión que presupuesta sobre geometría subida tiene un motivo real para preocuparse de adónde fue.

El techo gratuito son 100 MB, que a cincuenta bytes por triángulo es un modelo de dos millones de triángulos. Los archivos de ese tamaño conviene reducirlos antes de convertir y no después: el glTF será proporcionalmente enorme, y un visor de navegador en un móvil no lo va a agradecer llegue en el formato que llegue.