2026-08-14 · 7 min · 3d-generation · agents · world-models · procedural-generation · paper · explainer
WorldClaw (arXiv 2608.05248, 2026-08-05, Tencent Hunyuan) generates large, freely explorable 3D worlds from open-ended text. The thing that separates it from most work in this area is the output format: not a radiance field, not a mesh soup, but explicit instance-level assets sitting on a continuous terrain, all of it editable afterwards in Blender.
The way it gets there is the interesting part. WorldClaw does not generate 3D. It writes programs that generate 3D.
The pipeline
Formally the paper writes it as three functions and a compose:
P = F_plan(q)— a text prompt becomes a structured specification of regions, terrain conditions and object conditionsT = F_terrain(P)— the specification becomes a global terrainO = F_region(P, T)— regions that need detail get objects, conditioned on the terrain already builtS = Compose(T, O)
The ordering carries the whole design. Terrain is built first and objects are generated conditioned on it, so a hut sits on a slope the system already knows about rather than being placed onto a surface it has to discover.
That middle panel is the system in miniature. The agent's deliverable is a Python function that composes noise octaves and landform primitives into a height field. Not a heightmap image — a program that computes one.
The height field
Four regions, each with its own base elevation, noise octaves and landform bump, summed under normalized masks. The mask normalization is the part that matters: because the weights sum to one everywhere, neighbouring regions blend instead of butting against each other, so a beach can become a forest without a seam. Turn normalization off and the overlaps add rather than average — elevations pile up wherever two regions meet, which is exactly the artefact a tile-stitching approach has to fix afterwards. This is one continuous field that happens to be authored per region, which is what lets the planning agent write regions independently and still get a coherent world.
Equation 6 is the core of the terrain stage:
H(x) = Σ_r m̃_r(x) · [ h_r + Σ_k w_r,k N_r,k(x) + Σ_j α_r,j G_r,j(x) ]
Each region r contributes a base elevation h_r, a weighted sum of noise octaves N, and a weighted sum of landform primitives G — and the whole contribution is gated by a normalized region mask m̃_r.
The normalization is the part worth dwelling on. Because the masks sum to one everywhere, adjacent regions blend rather than abut. A beach becomes a forest without a seam, and no post-hoc stitching step is needed. That is what lets the planning agent describe regions independently — writing "coastal", "dense jungle", "volcanic ridge" as separate specifications — and still get a single continuous world out.
It is also why this is a genuinely different approach from tiling. There is one field. It just happens to be authored per region.
Placing objects is a solved geometry problem
For regions that need detail, WorldClaw renders the terrain from a viewpoint, generates a composition image conditioned on that render, segments the objects out of it, reconstructs each as a textured mesh, and then has to work out where each mesh goes in 3D.
That last step is where the paper does real work rather than prompting. Placement is recovered by solving for a similarity transform per object: a scale from the ratio of depths and focal lengths (s_i = (Z_t/Z_o)(f_i^o/f̂_i)), a rotation, and a translation, assembled into T_place. There is also a bounded contact constraint — the projected base of each object has to land within a tolerance band of a reference height, written as a two-sided inequality rather than an exact equality.
This is the difference between an agent that asks a model where the tree goes and one that computes it. The bounded constraint in particular is doing something specific: it permits a tree to sink slightly into a slope or stand slightly proud, which is what contact looks like on real terrain, while forbidding it from floating.
Six models in a trench coat
"Current open-source language models often struggled to generate procedural terrain and materials that were both executable and consistent with user requirements." Executable is the hard half: the output is a program that either runs in Blender or does not.
Decomposing a hard task into stages is supposed to make each stage easier. The paper reports the opposite for the two stages that produce something executable: planning has to emit Blender programs that run, and image generation has to emit layouts precise enough to segment. Both are places where a weaker model does not degrade gracefully, it fails. That is why the honest version of this system’s requirements is not “an agent” but Claude Opus 4.8 plus GPT-Image-2 plus Hunyuan3D, which the authors say outright.
WorldClaw uses Claude Opus 4.8 as the agent model, with task-specific skills that wrap GPT-Image-2, SAM3, SAM3D and Hunyuan3D, executing into Blender 5.1.1 on 4× NVIDIA H20 GPUs.
The Limitations section is more candid than most, and it is the most useful part of the paper:
In our experiments, current open-source language models often struggled to generate procedural terrain and materials that were both executable and consistent with user requirements. Likewise, open-source image generation models frequently failed to produce usable semantic layout maps or to preserve object appearance and pose.
And then, plainly:
Consequently, fully validating this decoupled pipeline at the current stage still requires capable models such as Claude Opus 4.8, GPT-Image-2, and Hunyuan3D.
Decomposing a task into stages is supposed to make each stage easier. Here it did the opposite for the two stages whose output has to be executable: a plan that becomes a Blender program either runs or does not, and a layout map is either segmentable or is not. Neither degrades gracefully when the model gets weaker.
The second limitation is the one anyone building on this should read twice. Several stages depend on LLM-generated programs, and:
Errors in scale estimation, numerical parameters, or node connectivity directly manifest in the resulting 3D scene as inconsistent landforms, inaccurate material effects, or object layouts that deviate from the user intent, often necessitating multiple render–inspect–refine iterations.
A wrong number in a generated program is not a crash, it is a mountain in the wrong place. The render-inspect-refine loop exists because the failure mode is silent and visual.
What the paper does not contain
There are no quantitative results. Section 3.2 is "Qualitative Results" and 3.3 is "Qualitative Comparison"; there are thirteen tables in the HTML and every one of them is a display equation. No user study, no CLIP or FID-style score, no timing table, no ablation with numbers.
For a system paper this is more defensible than it would be for a model paper — the claim is "you can build worlds this way and they are editable afterwards," and a render plus an instance mask demonstrates that. But it means nothing here is measured. The comparison figures show WorldClaw's worlds looking bigger and better organized than the baselines', and that is the entire evidential basis.
The third limitation is the honest counterweight: generating and reconstructing every object separately, then iterating refinement over terrain, assets and contacts, "incurs substantial inference latency and computational cost," and the pipeline "can be unnecessarily lengthy and inefficient for simpler scenes that holistic generation methods can synthesize in fewer steps." No wall-clock figure is given for either.
Why it is still worth attention
The output format is the argument. A generated radiance field is a thing you can look at; a terrain with named regions, instance-level meshes, PBR materials and solved placements is a thing you can open — move a building, restyle a material, swap an asset, run physics against the ground. The paper's stated next step is generating objects as executable node graphs too, which would make composition and material logic editable in the same way the terrain already is.
The cost is that WorldClaw is currently less a model than an orchestration of four proprietary and open systems that its own authors could not substitute. Whether that is a stepping stone or a ceiling depends entirely on whether open models get good enough at writing Blender.