WorldClaw builds a whole 3D world from a sentence. The assets are the bottleneck.

On 6 August 2026, Tencent's Hunyuan team published WorldClaw, an agentic framework that turns an open-ended sentence into a large, freely explorable 3D world: terrain, regions, objects, materials, placement. Not a video of a world, and not a radiance field you can only look at. Explicit meshes you can open in Blender and edit.

It is a good paper, and the demo scenes (a tropical pirate island, a river canyon with tribal settlements, a desert battlefield) are the most convincing open-world generation results so far. But the part worth reading twice is not the terrain. It is a small subsection called Terrain Asset Prototypes, because that subsection is a library slot, and what goes in it decides whether the world holds together.

What WorldClaw actually does

The pipeline is coarse-to-fine and runs in three stages, each one driven by agents rather than a fixed script.

1. Intent analysis and planning. Planning agents turn the prompt into a structured specification: regions, terrain parameters, assets, materials and spatial relations. When the prompt names something the agent does not know, it searches for references; when words are not enough to pin down a look, it generates a concept image to condition the rest.
2. Global terrain generation. A semantic layout map and a region-aware height field build the landform. Materials come from two paths: generated texture channels (albedo, normal, roughness) for detailed surfaces, and procedurally assembled Blender material nodes for large tileable regions. Then reusable asset prototypes are scattered across it.
3. Regional object generation and placement. For regions that need detail, the system composes a terrain-conditioned 2D layout, reconstructs individual instances as editable textured meshes, and recovers each one's position, scale and orientation. Render-based agents then look at the result and fix terrain, objects, appearance and contacts.

That last loop is the genuinely new part. An agent renders the scene, notices that a hut is floating four metres above the hillside or that a boulder is the size of a house, and corrects it. Placement has always been where procedural world building looks wrong, and looking at the render is the obvious fix that nobody had wired up at this scale.

The paper is candid that this only works with strong models. From its own limitations section: fully validating the pipeline "still requires capable models such as Claude Opus 4.8, GPT-Image-2, and Hunyuan3D".

The slot everybody skips

Read the terrain stage again:

For environmental elements that are repeatedly instantiated across the global terrain, this stage generates reusable 3D asset prototypes without determining instance-specific positions, scales, or orientations.

Rocks. Vegetation clusters. Landform attachments. The things a world is mostly made of, by count. WorldClaw generates a representative image for each category, runs image-to-3D over it, and gets back a prototype mesh that then gets scattered a few hundred times.

This is the right architecture. Generating a thousand individual rocks would be absurd; you generate one and instance it. But it means the visual identity of the entire world rests on a handful of prototype meshes, and the paper says exactly what that costs:

The visual quality of the final scene is also directly bounded by the 3D generation backbone, as low-fidelity geometry and textures noticeably reduce immersion.

A world generator has a library slot. Right now it is filled by whatever image-to-3D returns that day.

Why a freshly generated mesh makes a poor library

Four problems, and none of them get better as the generators improve.

Coherence. A rock generated from one reference image and a bush generated from another have no relationship. Different palettes, different implied scale, different texel density, different silhouette language. Humans read that instantly as "asset flip", and it is the single most common reason an AI-generated scene feels wrong even when every individual object is fine. Coherence is a property of a set, and generating objects one at a time cannot produce it, no matter how good each object is.

The prototype is frozen. Scattering one mesh 300 times gives you 300 identical rocks. The usual fix is random scale and rotation, which fools nobody: the silhouette repeats. What you actually want is 300 variants, and a mesh cannot give you that. You would have to run the generator 300 times, which costs 300 times as much, takes 300 times as long, and reintroduces the coherence problem you were avoiding.

Cost and latency per world. Every regeneration is GPU time. A pipeline that has to mint its own props on every run pays for the same rock forever, and the iteration loop (change the prompt, look, change it again) is exactly where that cost compounds.

Provenance. Generated geometry arrives with no licence, no triangle budget, no guarantee it is manifold, no UV discipline, and nobody who checked. That is survivable in a research demo and disqualifying in a shipped game.

What a world generator actually wants from an asset library

If you were designing the library that fills that slot, working backwards from the pipeline above, you would ask for six things.

That is a fair description of what we build.

Where this lands for Polyfork

Polyfork ships 512 published low-poly assets, 259 of them free, organised into kits. Two things about them matter here.

A kit is coherent by construction. A kit is designed as a set before any of it is modelled: one 32-colour palette, one grid module, one style contract every part is built against. The sixty parts of a city block are chosen together, which is why the crosswalk paint, the roller shutters and the air-con units look like they belong to the same street. That is the property a scattering system cannot synthesise object-by-object.

Every model is a program, not a mesh. This is the part that answers the prototype problem directly. 457 of our published assets ship as ES modules that build their geometry, with 4,889 declared knobs between them: colours, ranges, choices, toggles. Each knob is published as JSON with a plain-language description written for a machine reader, and a knob only ships once there are renders proving it visibly changes something without breaking the model.

So the "vegetation cluster" problem has a one-line answer. Here is a real free asset from our Nature & Forest kit, Tall Pine Tree:

import { createAsset } from 'https://polyfork.dev/cdn/tall-pine-tree-ab4108.mjs';

for (const p of scatterPoints) {
  const tree = createAsset({
    colorway: pick(['deep-pine', 'spring-fir', 'shadow-spruce', 'golden-larch']),
    tallness: 6.4 + rand() * 3.2,    // declared range: 6.4 to 9.6 m
    facets:   7 + (rand() * 6 | 0),  // declared range: 7 to 12
    flare:    0.25 + rand() * 0.75,  // declared range: 0.25 to 1
    season:   'summer',              // or 'snow'
  });
  tree.position.copy(p);
  scene.add(tree);
}

Three hundred pines, no two alike, one asset, no GPU, no generation step, and every one of them still in the same palette as the terrain underneath, because both came out of the same kit. An agent that wants to know what it may pass reads the schema first:

GET https://polyfork.dev/cdn/tall-pine-tree-ab4108-params.json

For consumers that cannot run JavaScript, the same variant can be baked server-side and fetched as a GLB:

GET https://polyfork.dev/cdn/tall-pine-tree-ab4108-remix.glb?p={"colorway":"golden-larch","tallness":8.2}

The picture at the top of this post is that loop run once: one terrain program, seven assets from the same kit, and 178 instances between them, every one built from a different parameter set. No mesh in it was generated for the occasion, and the whole scene is 51,741 triangles.

Terrain is the same argument, one layer down

WorldClaw's terrain is a region-aware height field assembled from parameters an agent chose. We arrived at the same shape from the other direction, and shipped it: every Polyfork kit now gets its own procedural terrain generator, a program rather than a set of ground props. Chunks are 64 m, which divides evenly by every kit module in the catalogue, and two different kits' terrain can be laid side by side on a shared world grid and join without a crack.

The first two are live: Coral Reef Terrain with 14 knobs (rock formations, deep fissures, sand channels) and Nature & Forest Terrain with 12 (hillocks, a stream bed, boulder fields).

We think this is where world generation ends up: the generator decides the plan, and the plan is executed by parametric programs that were built to fit together. Not because generation is bad, but because a plan is cheap and geometry is not, and a program you can re-run at any parameter is worth more than the one mesh it happened to produce first.

What we would like to be wrong about

The honest counterargument is that image-to-3D keeps improving, and that at some point generating a coherent set in one pass becomes tractable, at which point a curated library is a nice-to-have. That may happen. But coherence, licensing and triangle budgets are not model-capability problems, and the paper's own limitations section is mostly about the difficulty of getting heterogeneous models to agree with each other. A library that is coherent, parametric and documented removes work from that pipeline rather than adding to it.

The other thing we would like to see: a world generator that treats an asset library as a first-class input, with the planner choosing from a catalogue it can query, and generation reserved for what the catalogue genuinely lacks. Nobody has built that yet. Our catalogue is queryable over an HTTP API and an MCP server today, in case somebody wants to.

Frequently asked questions

What is Hunyuan3D WorldClaw?

WorldClaw is an agentic framework from Tencent Hunyuan that generates large-scale, explorable 3D worlds from an open-ended text prompt. Planning agents turn the prompt into a structured specification of regions, terrain, assets and materials; the system then builds a region-aware height field, scatters reusable asset prototypes over it, generates detailed objects for individual regions, and uses render-based agents to refine placement, scale and contacts. It was published as a paper on 6 August 2026; no code or weights have been released.

Does WorldClaw output editable 3D assets?

Yes. That is one of its stated goals. WorldClaw produces explicit textured meshes at instance level rather than a video or a radiance field, so the resulting scene can be opened and edited in a normal 3D pipeline. The paper describes reconstructing "editable textured meshes" and recovering each instance's placement on the terrain.

Can a world generator use an existing 3D asset library instead of generating everything?

Architecturally, yes: WorldClaw's terrain stage already separates reusable asset prototypes from their instance placements, which is exactly the boundary a library plugs into. The prototypes are currently produced by image-to-3D. A library supplies the same slot with assets that share a palette and grid, carry declared parameters, and come with a known licence and triangle count.

Why do parametric assets suit AI world generation better than static meshes?

Because scattering needs variety and a mesh has none. One parametric asset produces hundreds of distinct instances by varying declared parameters, at no generation cost, while staying inside one palette. A static mesh gives you the same silhouette every time, and generating a fresh mesh per instance costs GPU time per instance and loses set coherence.

Are Polyfork assets usable from an agent without a human in the loop?

Yes. Every remixable asset publishes its knobs as JSON with machine-readable descriptions, the catalogue is queryable over an HTTP API and an MCP server, and variants can be baked server-side to GLB by passing parameters to the CDN. See the agent guide.