CCORE Releases GLB-3D-Coder 4B for Reusable 3D Asset Generation

Summary:CCORE has released the final version of GLB-3D-Coder 4B, a full fine-tune of Qwen3.5-4B for generating reusable 3D assets. Given a natural-language request, the model produces a complete Three.js HTML scene with an Export GLB control, allowing the resulting geometry, materials, and animations to be imported into tools such as Godot, Blender, and Unity. The release includes an approximately 2.7 GB Q4_K_M GGUF build, a Q8_0 GGUF build, and full Safetensors weights. Its compact footprint makes loc

---

A 4B model that directly produces importable GLB assets

CCORE has released the final version of GLB-3D-Coder 4B, a full fine-tune of Qwen3.5-4B. Instead of producing a static preview or a WebGL scene that can only be viewed, the model generates a complete Three.js HTML program containing both the scene logic and an "Export GLB" control. The resulting glTF Binary asset can then be imported into Godot, Blender, Unity, and other tools that support GLB.

The model targets more than fantasy characters. Demonstrated categories include buildings, environments, weapons, vehicles, laboratory equipment, sports props, and furniture. Some outputs also include animation, which is exported with the GLB file. The workflow places text-to-code and code-to-asset conversion inside one interactive pipeline, shortening the path from a natural-language prompt to a reusable 3D asset.

Technical mechanism: from an LLM to a procedural 3D scene

GLB-3D-Coder is fundamentally a code-generation model rather than a native 3D diffusion model trained directly on meshes. Its output describes geometry, materials, lighting, cameras, animation tracks, and export logic through a Three.js program. Whether the final file is reusable elsewhere depends on correct glTF serialization, valid material references, consistent transforms, and properly structured animation hierarchies.

This programmatic approach has a practical advantage: the same HTML file can dynamically adjust parameters and reuse Three.js geometry algorithms, loaders, and controls. Its quality is therefore not limited to visual appearance. The generated code must also use valid APIs, preserve object relationships, avoid naming collisions, and remain portable across browsers and GLB importers.

A 4B-parameter model has limited capacity for simultaneously reasoning over complex geometry, program logic, and long contexts. Errors can propagate through an object hierarchy, and a single invalid Three.js call may break the complete export path. Retries, code repairs, and runtime validation consequently remain part of a production workflow rather than optional cleanup.

Weights and quantization: a low local-deployment barrier

The project provides an approximately 2.7 GB Q4_K_M GGUF build, a Q8_0 GGUF build, and full Safetensors weights. Q4_K_M is aimed at consumer GPUs and systems constrained by memory, disk capacity, or bandwidth. The tradeoff is that quantization error may affect code generation, coordinate precision, and material parameters. Q8_0 usually preserves more numerical fidelity but requires additional memory and bandwidth.

| Build | Primary use case | Main tradeoff | |---|---|---| | Q4_K_M GGUF | Local inference on consumer hardware | Small footprint, but generation reliability should be tested carefully | | Q8_0 GGUF | Higher-fidelity inference and controlled comparisons | Higher memory and bandwidth cost | | Safetensors | Fine-tuning, retraining, and research | Largest deployment footprint and the greatest training-resource requirement |

Throughput cannot be inferred from file size alone. For a 4B dense model, inference still depends on context length, KV-cache usage, batching, and the runtime implementation. Code generation further increases the number of output tokens. Developers should separately measure time to first token, end-to-end scene generation time, peak memory, and export success rate instead of estimating performance solely from the GGUF footprint.

Evaluation and comparison: more than visual quality is required

The author demonstrates character design, scene detail, and animation, including selected side-by-side comparisons with DeepSeek V4.1 Flash. However, the current information does not provide a complete prompt set, sampling configuration, success rate, number of manual repairs, mesh-topology quality, cross-tool GLB compatibility, or evidence that both systems used identical context, tools, and post-processing.

A 3D generation model should be evaluated on at least four axes: semantic alignment between prompt and asset, geometric and material defects, successful GLB import in Blender, Unity, and Godot, and correct animation binding. Visual examples can demonstrate the upper bound, but they do not establish average reliability in batch production. At this stage, the defensible conclusion is that the model offers a lightweight and locally runnable route to 3D asset generation, while its consistency and any advantage over DeepSeek V4.1 Flash still require reproducible evaluation.

Deployment guidance for developers

1. Validate the export path first: Check that the scene loads completely in a browser and that the GLB opens in the intended DCC or engine. A normal HTML preview is not sufficient evidence of a valid asset.
2. Pin the generation environment: Record the system prompt, recommended settings, quantization build, Three.js version, and browser version to avoid mistaking runtime differences for model variability.
3. Automate acceptance checks: Validate mesh counts, material references, animation tracks, bounding boxes, filenames, and critical object hierarchies, while preserving export logs.
4. Choose quantization by task: Use Q4_K_M to screen prompts on constrained hardware, then verify important assets with Q8_0. Avoid treating only a quantized build as the evaluation baseline.
5. Wait for the dataset and reproduce the experiment: The training data is scheduled for November 6. Its composition, licensing, duplicate rate, and cleaning procedure will directly affect reproducibility and commercial-use boundaries.

Engineering value

The key contribution of GLB-3D-Coder 4B is not a single visually impressive demonstration. It extends a downloadable, resource-efficient, locally runnable language model into editable code that exports reusable 3D assets. Its competitiveness will depend on export success, cross-engine compatibility, and how easily failures can be diagnosed and repaired—not on visual detail alone.

---

Source: Reddit r/LocalLLaMA (2026-11-05)

— END —

Tags: #CCORE Follow #GLB-3D-Coder Follow #Qwen3.5-4B Follow #Three.js Follow #3D Generation Follow