fable51-worlds: procedural Three.js reconstructions of real places, built by agent swarms

The problem: a 3D scene you cannot diff

A generated scene is usually a binary blob. You get a mesh, a splat file or a set of tiles, and when something is wrong you re-run the generator and hope the fix lands. The README frames fable51-worlds against that: "A world written as code is not the same kind of object as a world generated as pixels or held in a latent space." The repository's claim is that a place can be expressed as modules with contracts, so that a change is a diff rather than a re-roll, and so that a wrong elevation is a failing test rather than a matter of taste.

Who this is for is narrower than the topic list suggests. The audience is engineers who want to read a working example of a full pipeline, from a one-line brief to a browser app, and who are comfortable in Three.js and Node tooling. It is not a drop-in scene loader and it is not a hosted service. There is no homepage, no published package and no releases, so consumption means cloning and reading.

Four stages, and the artefacts each one leaves behind

The README documents four stages, and each one produces something you can inspect.

Reconnaissance runs parallel research agents that pull map geometry, elevation, transit and street specifications, plus what the README calls a storefront census. Each fact carries its source and a confidence level. That last detail is the design decision worth noting: the pipeline keeps provenance attached to individual numbers instead of collapsing research into an untraceable summary.

Asset generation emits the kit a world needs: façade modules, street furniture, vehicles, vegetation, fixtures. The README states that some worlds ship no binary assets at all and draw every texture at start-up. That is a real constraint as much as a boast, because procedural texture generation moves cost into page load and into the renderer code.

The runtime is a pure Three.js app that assembles terrain, streets, façades, props, crowds and traffic from JSON specs. The specs are the seam between generation and rendering, and they are the part most likely to be reusable in another project.

Verification closes the loop. Playwright drives the real app, screenshots fixed viewpoints and diffs them against photographs taken from the same spot. Reviewer agents (architect, geographer, technical artist, interaction) file reports that drive the next fix cycle, and the README states plainly that builders never grade their own work. Every world ships its own QA report, defects included.

What actually ships in the repository

Three worlds are listed, each as a directory with a documented input type.

union-square-sf is built from a text brief and has a companion directory, union-square-sf-gpt-astra, holding a second build of the same brief. The two are presented side by side in a 59-second video, with the GPT-6 Astra build on the left and the Fable 5.1 build on the right, filmed to the same camera route and shot timing. The Fable build alone has a 1920x1080 walkthrough covering an aerial pass, the plaza, a Nintendo storefront, the lower level and an Apple store.

kyoto-higashiyama is also text-driven, described as seven scenes from Gion to Kiyomizu-dera at sunset, with a 53.9-second head-to-head video and a full Codex walkover GIF in the comparison directory.

death-star-trench-run takes a clip from a film as its input and ships a PROMPT.md with the brief and a COMPARISON.md describing the method. Its head-to-head runs 28.2 seconds.

Two things follow from this layout. First, the repository is as much a benchmark harness as a world collection: the paired directories exist so the same brief can be rendered twice and compared. Second, the comparison material is video, and the README does not publish a numeric scoring method for it. The method file for the trench run is the only one named, and its contents are not reproduced in the README.

Running a world: what the README does and does not give you

This is where the documentation thins out, and it is worth being direct about it. The README describes the pipeline and links to per-world directories, but it does not include an install command, a dev server command, or a list of config keys. The only concrete technical statements about running the output are that it is a plain Three.js app that opens in a browser, and that verification is driven by Playwright against the real app.

So the honest instructions are structural rather than copied: clone the repository, open a world directory such as union-square-sf or kyoto-higashiyama, and serve it over HTTP, because ES module imports and any asset fetches will not work from a file:// URL. For the Playwright stage you would need the test configuration inside the world directory, which the README does not quote. If you need a documented entry point before you commit time, that is the first thing to check in the tree, not in the README.

The JSON specs are the more promising integration surface. The README says the runtime assembles terrain, streets, façades, props, crowds and traffic from JSON specs, which implies the spec schema is the contract between the generators and the renderer. Nothing in the README documents that schema, so treat it as something to reverse-engineer from the world directories.

The limitation the README does not address: no library boundary

The compositional claim is the strongest part of the pitch and the least evidenced part of the repository as presented. The README says each generator is a module with a contract, and that a district is a few hundred lines that calls them. That describes internal structure, not a published interface. With no releases, no package name and no homepage, there is no versioned surface for another project to depend on. Upgrading means tracking the main branch.

The second limitation is the one the README is candid about: builders never grade their own work, and every world ships its defects. That is the right posture for a research artefact and the wrong posture for a production dependency. If you need a scene that is correct by construction rather than correct after a review cycle, this pipeline's verification stage is a diff against photographs, which catches geometric and visual mismatch but does not certify that the world is fit for your purpose.

The third is scope. The worlds are urban and place-based, with one film-derived exception. A brief that names a subject and a style is the input shape; if your problem is interior CAD, mechanical assembly or anything requiring exact engineering tolerances, the surveyed-ground approach here has nothing to offer.

Where it sits next to photogrammetry and Gaussian splatting

The natural alternative for reconstructing a real place is a capture pipeline: photogrammetry or Gaussian splatting, where you photograph the location and the result is a dense representation of what the camera saw. The difference in approach is fundamental, not incremental. A splat is a measurement of appearance. It cannot be edited at the level of "make the shopfront recesses deeper", it does not expose named parts, and it has no notion of elevation as a queryable number. Its strength is fidelity to the captured view; its weakness is that everything outside the captured views is undefined.

fable51-worlds inverts that. Geometry comes from map and survey research plus procedural generators, so the world continues past the edge of any photograph, and the README's Kyoto description explicitly covers a route rather than a viewpoint. The cost is fidelity: a procedural façade is a plausible façade, and the Playwright diff against photographs exists precisely because the two will not match on their own. The README's own framing is that a code world is verifiable, compositional and editable, and the trade it accepts is that it is not a capture.

A conventional game engine is the other comparison, and the README rules it out by design: no engine, no proprietary 3D tiles, no downloaded meshes. That keeps the whole scene inspectable as source, at the cost of everything an engine's editor and asset pipeline would give you.

Maintenance, licence and what to check before you build on it

Maintenance cost is dominated by the fact that this is a monorepo of one-shot results. Each world is a self-contained app with its own QA report and its own defects, and there is no indication in the README that the worlds share a versioned core. If you fork a world, you inherit that world's code, not a dependency you can bump. The last push recorded is 2026-09-09 and the repository is not archived, so it is active, but activity is not the same as a support commitment, and the README's roadmap lists animation, agent environments, 4D and test-time scaling as future work rather than shipped features.

On licensing, the README states that the code and generated assets are MIT, and that the geometry is derived from OpenStreetMap. The sentence is truncated in the material available here, so the exact terms of that derivation are not visible. MIT on the code is permissive and unsurprising for a repository of this kind, but the OpenStreetMap derivation is a separate question from the code licence and the README does not resolve it in the text provided. Read the LICENSE file and the full attribution sentence before redistributing a world, and if attribution obligations matter for your use, get that checked rather than inferred. Nothing here is legal advice.

The concrete first step is to clone the repository, open union-square-sf, and look for the Playwright configuration and the JSON spec files. Those two things tell you whether the pipeline is something you can extend or only something you can admire.

Editorial conclusion

Adopt fable51-worlds if you want to read, run or fork a worked example of a code-generated urban scene, and if you are willing to treat the worlds as reference implementations rather than as a product with a stable API. Do not adopt it if you need a maintained library with released versions, a support commitment, or a headless batch pipeline that renders worlds without a browser. Verify first whether the repo exposes any documented entry point beyond opening a world's index.html, and check the LICENSE file for the exact scope of the MIT grant, because the README states that the code and generated assets are MIT while the geometry is derived from OpenStreetMap, and it does not spell out the attribution terms that derivation carries.

Official sources

1. Issues
2. License: MIT
3. PhiloLabs/fable51-worlds on GitHub
4. README