La novedad no está en un producto comercial ni en una herramienta cerrada, sino en el enfoque: el modelo escribe escenas de **Three.js** con exportación a GLB para que el resultado pueda reutilizarse fuera del entorno web. El autor explica que esta ruta evita tener que entrenar un modelo específico para cada motor y que, al menos en sus pruebas, el flujo ya funciona con ejemplos importados en Godot.
Qué ha mostrado exactamente
El mensaje público presenta el proyecto como el primer checkpoint funcional. Según el autor, el entrenamiento continúa y el objetivo es que el modelo sirva para generar activos 3D que luego puedan llevarse a editores y motores de juego. En la demostración menciona ejemplos de prueba y señala que, de momento, muchas generaciones salen bien a la primera, aunque algunas todavía requieren repetir la consulta o aplicar una pequeña corrección al código generado.
También concreta el tipo de uso esperado: el autor recomienda apoyarse en el *system prompt* incluido en la tarjeta del modelo y lanzar peticiones simples, como pedir una “poción de maná” o una estación médica de frontera desgastada. Añade que, en sus pruebas, las instrucciones en inglés han funcionado mejor. Eso no equivale a una validación independiente, pero sí marca el nivel de madurez que pretende alcanzar: un flujo de trabajo lo bastante directo como para que un usuario no tenga que diseñar *prompts* complejos.
Por qué importa para Godot y otros motores
La parte más interesante del anuncio es el uso de **GLB**, un formato 3D que puede moverse entre herramientas y motores sin depender de un entorno concreto. El autor insiste en que el modelo no está “portando” código de Three.js a Godot, sino generando el activo y exportándolo como geometría y materiales en un formato estándar. En teoría, eso facilita que el mismo resultado pueda reutilizarse en Godot, Blender, Unity y otros entornos compatibles.
Ese detalle es importante porque resuelve un problema práctico habitual en la generación 3D con modelos de lenguaje: no basta con que el sistema “dibuje” algo en su propia interfaz; el contenido tiene que salir en una forma que luego pueda editarse, validarse y reutilizarse en una cadena de producción real. Aquí, el foco está en el activo exportable, no en una escena cerrada que solo sirve dentro del propio generador.
Lo que está confirmado y lo que sigue abierto
Hay varias cosas que sí quedan claras. La primera es que el modelo existe, está asociado al nombre **Qwen3.5-4B-GLB-3D-Coder** y se ofrece ya en formato usable, incluido GGUF, según responde el autor en comentarios. También confirma que la versión que está enseñando es un checkpoint intermedio y que más adelante publicará los pesos completos y el conjunto de datos de entrenamiento cuando termine el proceso.
La segunda es que el proyecto todavía no está cerrado. El propio autor explica que el entrenamiento sigue en marcha y que espera terminarlo al día siguiente por la tarde, en UTC. En otras palabras: esto es una muestra temprana, no una versión final estabilizada.
También hay límites que conviene no perder de vista. El autor reconoce que algunos resultados requieren un segundo intento o una pequeña corrección de código. Además, admite que todavía está explorando la variedad y la calidad de los datos de entrenamiento, que considera una parte crítica del proyecto. En sus respuestas dice incluso que esa fase de curación, ejecución y validación del contenido puede costar más esfuerzo que el entrenamiento en sí. Esa observación es relevante porque recuerda que, en generación de activos 3D, el cuello de botella no siempre es la arquitectura, sino el dato que la alimenta.
Qué puede hacer un usuario ahora mismo
Con la información disponible, lo prudente es tratarlo como un experimento prometedor para pruebas locales y prototipado, no como una solución lista para producción. El autor afirma que la versión cuantizada Q4 ronda los 2,7 GB y que podría ejecutarse en un equipo con 8 GB de RAM si el contexto es pequeño, aunque avisa de que en CPU irá lento y de que las generaciones grandes pueden chocar con límites de memoria. También dice que el entrenamiento completo que él usa requiere 96 GB de VRAM en una RTX 6000 por las longitudes de contexto superiores a 70.000 tokens.
Eso dibuja un escenario bastante claro: el modelo apunta a desarrolladores y aficionados que quieran experimentar con la generación de activos 3D reutilizables, pero todavía depende de hardware potente y de ajustes finos. Aun así, el planteamiento tiene recorrido porque no intenta crear un ecosistema nuevo desde cero, sino apoyarse en un formato estándar que ya encaja con herramientas muy extendidas en desarrollo de juegos.
La siguiente pieza que falta es la más importante: ver si los próximos checkpoints reducen los fallos, mantienen la calidad y confirman que el flujo de trabajo sirve de verdad para producir activos aprovechables fuera de una demo. Hasta que llegue esa versión final, lo que hay sobre la mesa es una prueba de concepto útil, pero todavía incompleta.
