CubePart Turns AI 3D Into Interactive Game Assets

Current Observation

Generative AI can now produce convincing 3D objects quickly, but game development exposes a major gap between an object that looks complete and an asset that actually works. A generated car may have a recognizable body, four wheels, doors, and lights. That does not mean the wheels can rotate independently, the doors can open, the lights can switch on, or gameplay code can find the correct component.

Roblox introduced CubePart on May 28, 2026, as an attempt to move that structural work into the generation process. CubePart accepts both a global text prompt describing the object and a user-defined parts schema describing how the object must be divided. It then generates a set of separate, named meshes that assemble into one coherent object.

The important change is not that CubePart can generate another attractive vehicle. It is that the output begins with downstream production requirements in mind. Generative 3D is moving from simply creating geometry toward creating structure that animation, physics, and gameplay code can understand.

Background Analysis

From a Monolithic Mesh to an Asset Contract

Most text-to-3D systems answer one primary question: what should the object look like? A production game pipeline needs answers to several additional questions. Which pieces move? Which pieces need collision? How does a script find them? Can a new visual variation reuse existing gameplay behavior? What must remain consistent when the asset changes?

CubePart treats the parts schema as an API contract between the asset and the game code. A creator can describe the global appearance, such as “a jellyfish-themed cartoon racing car,” and separately list the components that the project requires:

parts:
  - body
  - wheel_front_left
  - wheel_front_right
  - wheel_rear_left
  - wheel_rear_right
  - headlights
  - exhaust

That separation between appearance and function matters. A racing game may only need a body and four wheels, while a combat game may also require a turret, armor, and destructible components. CubePart therefore uses an open-vocabulary schema. Creators define the part names required by their own experience instead of selecting from a small group of predetermined templates.

This approach extends Roblox’s earlier work on 4D generation. The initial rollout used fixed schemas such as Car-5, a car made from one body and four wheels, and Body-1, a single-mesh object. Those schemas demonstrated that generated geometry could be paired with predefined behavior. CubePart moves toward the broader goal: allowing creators to define the schema themselves.

Why CubePart Uses Two Generation Stages

Generating each requested part independently would create a serious consistency problem. A separately generated wheel may not match the vehicle’s proportions. A door may not fit its opening. A mechanical attachment may collide with the body or use a different shape language. The parts need independence, but they also need to behave as one designed object.

CubePart addresses this with a two-stage diffusion architecture built on a VecSet latent shape representation. The first stage interprets the global text prompt and the schema, then produces a latent representation of the complete object’s foundational shape. According to Roblox, this stage uses an MMDiT architecture with a Qwen-VL text encoder and was trained on roughly 4.7 million mesh-text pairs. It handles the data-intensive task of mapping open-ended language to global 3D geometry.

The second stage receives that global representation and produces one part latent for each schema entry. It reconstructs the complete object as a group of distinct meshes. For a cartoon tow truck, for example, the requested schema might contain a cab, chassis, wheels, roof beacon, and tow assembly. The second stage decides where those semantic boundaries belong while preserving the global design established in the first stage.

The model first decides what the object is, then decides how the requested functional pieces should divide it. The research reports that removing the first stage’s pretraining reduces the second stage’s ability to generalize to open-vocabulary schemas.

CubePart also introduces dedicated cross-part attention blocks. These allow generated components to exchange information without disrupting the pretrained global pathway. A wheel still needs to align with the chassis, a light must attach to the front of the body, and a tow assembly must connect to the correct support structure. Separate meshes cannot be generated as isolated ideas; they must coordinate spatially.

Part-Labeled Data Is Harder to Build

Training this type of system requires more than a large collection of complete 3D models. The data must identify part boundaries, semantic names, and spatial relationships. A dataset that labels every vehicle component simply as “wheel” does not teach a model to distinguish a front-left wheel from a rear-right wheel. That distinction is critical when scripts and physics expect exact names.

The CubePart team built a dataset containing more than 460,000 assets and 2.02 million parts. Roblox describes it as more than eleven times larger than previous public part-labeled datasets. Instead of relying entirely on manual annotation, the team created a vision-language model pipeline to help label the data.

The pipeline renders models from multiple viewpoints in pairs. One render shows the textured object and provides semantic context. The second uses distinct colors for parts and provides clear boundaries. Matching numbered markers appear in both views, giving the vision-language model references it can use to reason about and name components across the 3D object.

Impact Assessment

CubePart’s most immediate potential is moving some repetitive technical art work earlier in the pipeline. If a generated result reliably follows its schema, artists do not need to separate and name every output manually. Programmers can attach rotation, switching, destruction, or physics behavior to stable component names. That advantage becomes substantial when a project needs many variations of vehicles, mechanical props, doors, furniture, or modular interactive objects.

Teams could also validate one schema and one set of behavior scripts, then generate multiple visual styles that follow the same contract. Roblox also states that CubePart can decompose an existing artist-created mesh according to a new schema, which could help add interaction to legacy assets.

These benefits do not mean the output is automatically ready to ship. “Directly integrated” should be understood as an official research result, not a guarantee that every studio requirement has disappeared. Teams still need to inspect topology, UVs, materials, LODs, collision accuracy, pivots, performance budgets, naming conventions, and engine-specific import behavior.

Roblox also identifies several current limitations. CubePart primarily handles rigid-body decomposition. Skinned vertex weights for organic character deformation are still being developed. Cross-part attention reduces part overlap but does not eliminate it. Spatial reasoning, including distinctions such as front-left and rear-right, still has room to improve.

For those reasons, CubePart is best understood today as a more structured generation starting point, not a button that replaces technical artists or delivers final production assets without review.

Future Outlook

CubePart represents a larger shift beyond text-to-3D. Future generation tools are likely to read project constraints before producing content. A parts schema is one example, but the same principle could expand to skeleton requirements, material slots, LOD levels, collision types, naming rules, performance budgets, platform targets, and provenance metadata.

Once a generator can consistently respect those conditions, generative AI becomes less like a showcase tool and more like production infrastructure. Artists spend less time repeatedly cleaning individual outputs and more time designing schemas, defining quality gates, reviewing exceptions, and maintaining a coherent visual language.

For small teams, the lesson is not that everyone must adopt one platform immediately. The useful practice is schema-first asset planning. Even without CubePart, a team can document which components must exist, how they should be named, where pivots belong, and which systems will use them. Once that contract is clear, assets are easier to hand off whether they are made internally, outsourced, or generated.

Practical Application

A team evaluating part-controllable generation should start with a narrow rigid-body test rather than a full character workflow. A small vehicle or mechanical prop is a better validation target because its functional pieces and expected motion are easy to define.

1. Select an object with six to ten rigid components.
2. Ask art, animation, and engineering to define the schema, names, pivots, and expected behaviors together.
3. Write a minimal behavior test before generating the asset, such as wheel rotation, light switching, and detachable components.
4. Generate three visually different versions using the same schema.
5. Test whether all versions can reuse the same behavior without manual renaming or structural changes.
6. Inspect part overlap, orientation, topology, collision, LODs, materials, and performance.
7. Record both the generation time and the cleanup and integration time.

The key metric is not how many seconds generation takes. The useful metric is the total time from prompt to a stable, interactive object inside the game. If cleanup and integration still dominate the schedule, an attractive generated result has not yet improved the pipeline.

Keep the first schema conservative and request only parts with a clear gameplay purpose. Treat validation like an API test: the asset should fail review if a required component is missing, misnamed, incorrectly oriented, or unable to support its assigned behavior.

Personal Perspective

The most important idea in CubePart is that the creator states the functional requirement before the AI generates the content. That is closer to real production logic than generating an object first and attempting to repair it into something usable afterward.

The next bottleneck for AI-generated 3D is not only better geometry. It is whether generated assets can respect the contracts that hold a team together. Engineering needs stable names. Animation needs correct pivots and deformation structures. Art needs editable geometry. Production needs predictable cost and review standards. A generator that serves all of those requirements has a much stronger chance of entering repeatable production.

CubePart does not solve every part of that challenge, but it frames the challenge correctly. The meaningful question is not whether an AI can produce a compelling mesh. It is whether the output reduces total production friction while preserving control, quality, and accountability.

Conclusion

CubePart moves generative 3D from appearance-driven output toward structure-driven assets. By combining a global text prompt with a user-defined parts schema, it attempts to produce meshes that animation, physics, and gameplay scripts can understand, rather than one attractive monolithic mesh.

The system still requires human inspection and does not replace character rigging or a complete shipping pipeline. Its current limitations around rigid-body decomposition, overlap, and spatial reasoning matter. Even so, it establishes a clear direction for useful AI-generated 3D: generated objects must be usable, maintainable, and extensible by the teams that receive them.

Related Resources:

• CubePart Official Introduction

  • Features, architecture, dataset, and current limitations

• CubePart SIGGRAPH 2026 Publication

  • Research abstract and paper information

• Roblox Cube on GitHub

  • Open model code, examples, and system requirements

Tags: #CubePart #AI #3DAssets #GameDevelopment #ArtPipeline #TechNews