CCORE Releases the GLB-3D-Coder Dataset with 3,918 Validated Three.js Examples
By Mr.Xu Community Post
Published:
Summary:CCORE has open-sourced ThreeJS-3D-GLB-Assets, the dataset used to train its 4B-parameter GLB-3D-Coder model. The release contains 3,918 examples spanning 40 domains, split into 3,501 training and 417 validation samples. Each record includes complete conversations, reasoning traces, HTML/JavaScript responses, and rendered reference images, with coverage of static assets, animations, and interactive scenes. Every example was executed, rendered, and validated through GLB export before inclusion, pr
Core Release: A 3D Code Dataset with Rendered and GLB-Validated Outputs
CCORE has released ThreeJS-3D-GLB-Assets under the MIT License. The dataset was used to train CCORE GLB-3D-Coder, a 4B-parameter model for generating 3D assets with Three.js and exporting them as GLB files. It contains 3,918 examples across 40 domains, including characters, creatures, vehicles, laboratory equipment, musical instruments, architecture, machinery, natural scenes, and everyday objects. The data is split into 3,501 training examples and 417 validation examples.
Unlike an ordinary instruction dataset containing only prompts and code, each example forms a validation chain that connects a generation trajectory to an executable asset and its rendered result. Every record includes the complete conversation, reasoning trace, HTML/JavaScript response, and rendered reference image. Static assets, animations, and interactive scenes are included. The publisher states that every example was tested and rendered, and that its exported GLB file was validated before inclusion.
Data Format and Task Pipeline
Technically, this is not a simple text-to-code dataset. It represents a multi-stage 3D asset pipeline: the model generates HTML/JavaScript scene code from a natural-language request, Three.js constructs geometry, materials, lighting, and cameras, and a GLB exporter serializes the result into an asset consumable by other 3D tools.
Because the dataset preserves full conversations and reasoning traces, it can support several training strategies:
- Instruction-to-code supervised learning, teaching the model to translate asset descriptions into Three.js and HTML/JavaScript implementations.
- Execution-feedback reinforcement learning, using render outputs, GLB export results, and runtime failures to improve code executability and geometric correctness.
- Multimodal alignment, using the correspondence among text, code, and rendered images to align generated programs with visual outcomes.
The announcement does not yet specify the exact validation rules, retry policy, depth of GLB structural inspection, automated scoring method, or whether the reasoning traces were manually filtered. “Rendered and tested” therefore reduces the amount of obviously invalid data, but it does not establish that the model will consistently generate geometrically correct, importable, and visually faithful assets for unseen requests.
Engineering Value of the Training Data
The most immediate value is that it lowers the data-engineering barrier for 3D generation research. Similar projects often spend substantial effort writing runnable scenes, rendering reference images, and verifying exported files. This dataset packages those tasks into reusable assets, allowing researchers to proceed directly with supervised fine-tuning, preference learning, execution-feedback training, or automated evaluation.
A dataset of 3,918 examples is still appropriate for specialized fine-tuning rather than pretraining. It can test whether a small model learns Three.js, GLB export, and a bounded set of asset categories. It can also support research on joint optimization of structured code and visual results for small models. Broad programmatic modeling would require additional data covering mechanical topology, parametric constraints, physically meaningful materials, and complex hierarchy relationships.
The domain mix may also introduce bias. Characters and everyday props are relatively easy to construct by composing primitive geometries, while architecture, machinery, and laboratory equipment depend more heavily on scale, part relationships, and functional semantics. If validation mainly checks whether a page loads and whether GLB export succeeds, the model may learn structural validity without learning geometric or physical plausibility. Evaluation should separately measure code executability, GLB re-importability, topology integrity, proportions, visual similarity, and multi-view consistency.
Deployment Implications for a 4B Model
The companion checkpoint is named Qwen3.5-4B-GLB-3D-Coder, indicating a Qwen3.5-series backbone. A 4B model is practical for inference and fine-tuning on consumer GPUs or a single workstation, and it is easier to integrate into coding toolchains than larger multimodal models. Its output is an inspectable program and asset rather than an opaque result that can only be judged through an image, making it suitable for agentic workflows: the model generates or modifies a scene, a Three.js runtime executes the code, a GLB exporter validates the output, and a renderer returns feedback to the model.
End-to-end cost cannot be assessed from parameter count alone. Three-dimensional generation also requires a browser or Node.js environment, Three.js dependencies, loading textures and static assets, GPU rendering, image encoding, and GLB serialization. If generated programs are long, autoregressive decoding may dominate latency. Concurrent inference also requires isolation of filesystems, browser caches, and WebGL contexts so that untrusted generated code cannot exhaust resources or contaminate other requests.
Recommendations for Developers
When using the dataset for further training, preserve the mapping among source code, rendered image, and exported asset. Use the validation split for model selection rather than monitoring training loss alone. A practical evaluation pipeline can apply four levels of checks: syntax and static-resource validation, error-free Three.js execution, GLB parsing and re-import, and multimodal consistency between the rendered result and the requested asset.
For production or tool integration, generated code should run inside a sandbox that limits network access, filesystem writes, CPU time, and GPU contexts. Dependency scanning is also advisable. Generated GLB files should pass checks for polygon count, texture dimensions, node hierarchy, material parameters, and coordinate units before entering a production asset library.
The central value of this release is not the raw size of the dataset, but the packaging of conversations, programs, renderings, and valid GLB assets into reusable examples. It provides an engineering starting point for small-model-driven procedural 3D generation, although model quality still requires independent generation tasks, cross-domain testing, and validation in real toolchains.
— END —Source: Reddit r/LocalLLaMA (2026-11-06)
Tags: #CCORE #GLB-3D-Coder #Three.js #3D Asset Generation #Dataset
Editorial & Fact-Checking Note: This article is compiled from primary research, official release documentation, and source papers by the ZICQ Newsroom pipeline with automated entity verification and human editorial review. If you notice any technical inaccuracy, please submit a correction via our corrections policy or email our editorial desk directly.
Community Comments