Roblox Cube: a foundation model for 3D, with weights you can run

The ambition, stated plainly

The README opens with a comparison. Foundation models trained on vast amounts of data have demonstrated remarkable reasoning and generation capabilities in the domains of text, images, audio and video, and the goal here is to build such a foundation model for 3D intelligence.

What that would support is spelled out as a list of Roblox production tasks: generating 3D objects and scenes, rigging characters for animation, and producing programmatic scripts that describe object behaviours. The project describes itself as opening a family of models towards that vision, and asks the research community to work on the same goals.

It is worth being precise about which of those are shipped. The models in the repository generate geometry. Rigging and behaviour scripting are stated as parts of the wider goal, not as features of the released weights. The shape tokenizer and the text-to-shape generation model were the first step, in the March 2025 launch of Cube 3D v0.1, and the framing has been that the model is accessible to individuals, creators, researchers and businesses of all sizes.

The repository is a working research codebase rather than a packaged product. There is a cube3d/ directory for the generation code, a cubepart/ directory for the newer model, examples/ with generated .obj files and renders, resources/ with the figures, a pyproject.toml, a setup.py, CODEOWNERS and a SECURITY.md.

Cube 3D v0.5: compositions and bounding box conditioning

The July 2025 update introduced two upgrades to the auto-regressive base model for 3D geometry generation from text: higher fidelity 3D compositions, and bounding box conditioning.

The compositions work is about the model holding several concepts at once. The example in the README is a mechanical lobster with mechanical tank treads, and the stated improvement is better text adherence, illustrated with a lowpoly paper craft victorian rabbit. The earlier models could produce a recognisable single object; the point of the update is that a prompt describing a compound object produces a compound object rather than one part of it.

Bounding box conditioning is the more interesting engineering idea, and it is what makes the model usable in a content pipeline. You give the model a prompt and a target bounding box, and it balances between the two. The README's examples are a seashell and a tall pagoda, both interpreted into distinct shapes that respect the requested proportions.

The technique comes with a documented failure mode, and the README does not hide it. The model sometimes struggles when the bounding box is too extreme for a given prompt, and the example given is a cat, where it can produce disconnected components or generate it along a diagonal to fit the constraints. That is a reasonable failure for a shape generator to have, and knowing about it in advance is worth a lot.

The technical details are in the arXiv report. The v0.5 model was trained on an additional 2.8 million or so synthetic 3D assets, there were several refinements to the VQ-VAE architecture and training procedures, and the VQ-VAE latent length was increased from 512 to 1024 to raise generation fidelity. The README also notes that the model is now available to individuals, creators, researchers and businesses of all sizes.

The CLI, and what comes out of it

The updated CLI inference path is documented in enough detail to be useful, and the command is short enough to read at a glance:

python -m cube3d.generate \
            --gpt-ckpt-path model_weights/shape_gpt.safetensors \
            --shape-ckpt-path model_weights/shape_tokenizer.safetensors \
            --fast-inference \
            --prompt "A tall pagoda" \
            --bounding-box-xyz 1.0 2.0 1.5

The flags map onto the two-model structure. The shape tokenizer checkpoint is the VQ-VAE that turns geometry into tokens and back, and the shape generation checkpoint is the language model that writes those tokens. The bounding box arguments are the new addition in v0.5, and the config under ./cube3d/config/ defaults to the version that supports them.

The fast inference flag has a caveat worth reading. It is optional, it may not be available for all GPUs that have limited VRAM, and it will not work on macOS. Those are the three constraints that decide whether you can use it, and they are stated rather than implied.

The output is an .obj file saved in the specified output directory, which is the format that every 3D tool reads. There is no mesh cleanup stage, no rig and no materials, so what you get is geometry, and the pipeline around it is your responsibility. The examples directory shows the shape of the results, with boat, bulldozer, dragon and sword, each as a .obj file and a .gif render, plus a prompts.json holding the prompts that produced them.

CubePart and the schema idea

The May 2026 update added CubePart, described as an open-vocabulary, part-controllable 3D generator.

The mechanism is a schema. You give it an input mesh and a user-defined parts schema, and it synthesises a set of meshes, one per schema element, that assemble into a coherent object while respecting the specified semantic structure. The claim in the README is that the resulting assets can be directly integrated into game engines and driven by animation, physics and behaviour scripts without manual post-processing.

That is a different problem from text-to-3D, and it is arguably the more useful one for a game engine. Text-to-shape gives you a shape you asked for. Part-controlled generation gives you a shape assembled from parts that you defined, which means the parts can be rigged, animated and scripted independently, because the boundaries between them are known.

It also explains the connection to the wider goal in the README's opening. A character that can be rigged is a character made of parts rather than a single mesh, and a script that describes object behaviour is only writable if the objects have structure the script can refer to. CubePart is the part of the vision that makes behaviour scripts conceivable, and it is a separate model in a separate directory, with its own project page, its own arXiv entry and its own weights on Hugging Face, plus a demo space.

The dependency stack, and an alpha that says so

The packaging tells you what kind of project this is. The package is named cube at version 0.1, with a description of a generative 3D model to accelerate the creation of 3D assets, accessories and experiences, authored by Foundation AI at Roblox, and it is classified as Development Status 3 - Alpha with the intended audience of developers.

The runtime dependencies are the ones you would expect for this work and reveal the stack: torch at 2.2.2 or newer, transformers, accelerate, numpy, tqdm, omegaconf for configuration, warp-lang, scikit-image, trimesh for mesh handling, and huggingface_hub with the cli extra for pulling weights. There are two optional extras, meshlab which installs pymeshlab, and lint which pins ruff to 0.9.10.

The setuptools configuration points the package finder at the cube3d directory and includes the cube package with namespaces turned off, which is how the source layout maps onto the importable name. There is a separate setup.py that declares the same package name at version 0.0.1, which is a leftover that would confuse a build tool reading it in preference to the pyproject.

One more detail is worth flagging for anyone setting this up. The project declares requires-python of 3.7 or newer while the classifier names Python 3.10, and torch 2.2.2 sets a higher floor in practice, so the declared minimum is not the real one.

Where the output is not ready for production

The README's own examples are the strongest evidence, and they are worth reading as a user rather than as a reader of a paper.

A model asked for a cat with an extreme bounding box may produce disconnected components, or the cat along a diagonal to satisfy the constraint. That is a failure a content pipeline has to detect, and the tool offers no validation step to help with it. The .obj output arrives with no normals, no UVs, no rig and no materials, so anything beyond a static prop needs a pipeline behind it.

The research framing helps here. A foundation model for 3D is a research programme, and a repository of weights with a CLI and a documented failure mode is exactly what an open research release should look like. The problem is only if the model is treated as a production asset generator, where the difference between a good shape and a broken one is a human review step nobody budgeted for.

The examples directory is honest in the same way, with the renders next to the .obj files, so a reader can see the quality rather than infer it from a claim.

A custom licence, an open release and a family of models

The project licence is recorded as a custom licence that GitHub cannot classify, with a LICENSE file at the root of the repository, and because this is a model release rather than code, that file is the one to read before you use the weights commercially. The repository is not archived, and the last push was on 2026-05-28, which lines up with the CubePart work in May 2026 rather than with a later model release.

There are no GitHub releases, which is a little unusual for a project with versioned model weights, but consistent with the distribution model: the weights live on Hugging Face, under the Roblox organisation, with the v0.5 model at cube3d-v0.5 and the CubePart model at cubepart, and the demos are Hugging Face spaces and a Google Colab notebook rather than a binary you download.

That arrangement is the sensible one for a model, because the weights change far more often than the code, and a platform that versions model files separately from code handles that better than a repository tag. It also means the model you get is whatever the Hub currently serves for that name, so pinning means recording the revision hash rather than a version string.

The last piece of the picture is the research framing, which the README keeps returning to. The family of models is being opened in the hope that others work on the same goals, and the artefacts that matter for that are the papers, the weights and the code, all of which are here.

Editorial conclusion

Adopt Cube if you need 3D assets generated from text and you are willing to treat the output as a starting point rather than a finished asset, and start with the Colab demo before touching the weights. Do not adopt it for anything that needs a guaranteed topology, a rigged character or a production pipeline, because the README is clear that the model can produce disconnected components and that rigging and behaviour scripts are still goals rather than shipped features. Before you build on it, read the arXiv report for the method, check the licence file in the root, and confirm the generation code path, cube3d/, still matches the weights you download, since the model and the code are versioned separately.

Frequently asked questions

Official sources

1. Issues
2. README
3. Roblox/cube on GitHub