# Braffolk/fable5-world-demo: a 4x4 km procedural world that exists only as code

> LAAS is a WebGPU-only three.js demo built almost entirely by a language model, and its real value is as a test harness for procedural world generation rather than as a game. The catch is that it runs on Chrome and nothing else.

**Braffolk/fable5-world-demo** — Laas: 3D world built by Claude Fable 5 to test its capabilities using three.js

- Repository: https://github.com/Braffolk/fable5-world-demo
- Website: https://dc5fzrbo8ssfx.cloudfront.net/laas/
- Stars: 726 · Forks: 113
- Language: TypeScript
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/braffolk-fable5-world-demo

## What LAAS actually is, and who should care

The repository is not a game. It is a measurement of what one model could produce from a written brief. The README states that the project was built roughly 99% by Claude Fable 5, with the human author partially writing a single document, PROJECT_LAAS_v2.md, which sets visual targets, triangle-count floors, a system list, world size, and banned outcomes such as black shadows, cloned trees, and fog used to hide draw distance. That brief deliberately omits implementation instructions. Everything else, architecture, engine systems, verification tooling, debugging, and the README itself, came from the model across long autonomous sessions.

The intended audience is therefore narrow and specific. Graphics engineers who want to see how a modern browser renderer is assembled in TypeScript will find a real codebase: about 21,000 lines of strict TypeScript across 90+ commits, with zero any. People evaluating model-generated code will find something rarer, a project where the verification harness is part of the deliverable. Players looking for a Fable demo are in the wrong place entirely, despite what search results suggest.

## How the world is generated: one seed, no assets

The README claims the repository contains no image, model, or audio assets, and that every mesh, texture, and light in the hero frame is generated by code at boot. The whole world is reproducible from a single URL parameter, ?seed=N. That constraint is what makes the project interesting: there is nothing to load, so everything visible comes from a generator.

The pipeline described in the README runs from terrain outward. A 4096 squared heightfield is synthesized, then eroded with a pipe-model hydraulic pass plus thermal erosion. Flow accumulation carves river channels into lakes that have outlets. Moisture and biome classification follow, with snow driven by slope and exposure. Meshing uses a CDLOD quadtree with crack-free skirts and far-shell detail synthesis out to a visible range beyond 4 km.

Vegetation is grown rather than placed. Six tree species come from a procedural branching grammar with per-instance uniqueness, so no two trees share a mesh. Foliage uses cluster cards baked from real generated leaf geometry, then octahedral impostors for distance. Around 190,000 trees and 450,000 understory instances are positioned by GPU clustered-Poisson scatter and culled per frame into compacted indirect draws. Lighting is four-cascade shadow maps with PCSS and screen-space contact shadows, plus a terrain-relative irradiance-probe field for global illumination. The README notes that a no-black-shadows rule is enforced by automated pixel sampling, which is the part worth copying: the visual rule is checked by code, not by eye.

## Installing LAAS and taking a first look

There is no package on a registry. The README gives two commands, and the dev server is pinned to port 5173 with --strictPort in package.json, so it will fail rather than silently pick another port if that one is taken.

```bash
npm install
npm run dev
```

Open http://localhost:5173 in Google Chrome 113 or newer on a desktop or laptop. The README states that other Chromium-based browsers such as Edge, Brave, Arc, and Opera should work, while Safari and Firefox are not supported because the engine is built and tested against Chrome's WebGPU implementation. The page detects unsupported browsers before loading and says so. Mobile and tablet browsers get a notice recommending a computer.

Once the world is up, click to capture the mouse. WASD moves, Shift sprints, Space jumps, and V toggles between walk and fly. Keys 1 through 9 jump to composed bookmarks, F starts a 90-second flythrough, and F3 opens a debug HUD with per-pass GPU timings. The README documents these URL parameters: ?seed=N for the world seed, ?T=hours for time of day from 0 to 24, ?shot=1..9 to boot into a bookmark, ?cam=x,y,z,yaw,pitch[,fov] for an exact pose, ?preset=low|high|ultra, ?freeze=1 to freeze world motion, and ?hud=1 to open the HUD at boot. Pressing P in the running world prints the current camera pose as a ?cam= string, which is the fastest way to get a reproducible viewpoint for a bug report.

## Chrome-only is a design decision, not an oversight

The README is blunt about this: there is no WebGL fallback by design, and if Chrome is present but WebGPU is unavailable, the page fails loudly with diagnostics listing the exact things to check, including hardware acceleration and chrome://gpu. That is the correct behaviour for this project and the wrong behaviour for almost any product. A visitor on an unsupported setup sees an error instead of a degraded scene.

The dependency is also pinned tightly. package.json lists three at 0.184.0 and @types/three at ^0.184.1, with @webgpu/types for the compute-side typings. The repository includes docs/THREE-NOTES.md, described as verified three.js, TSL, and WebGPU API notes accumulated against that pinned version. That file exists because the model needed it, but it doubles as a warning: the renderer and TSL surface move between three.js releases, so upgrading three is not a routine dependency bump here. Expect to re-verify shader and node-graph code against the new version, and treat the notes file as the starting checklist.

The second limitation is subtler. The README says human input was limited to things a model cannot judge well from static output: wind sway amplitude, walk-camera bob, cloud motion lagging the camera, water coverage taste. Those are exactly the qualities a static screenshot cannot capture, which means the automated verification loop, for all its pixel sampling and frame diffing, does not cover them. If you reuse the harness, know its blind spot.

## What the verification harness does that most demos do not

The tools/ directory is the most transferable part of the repository. The README describes a model doing its own QA: booting the world headless with Playwright driving Chromium against a WebGPU/Metal adapter, taking screenshots, sampling pixels, diffing frames against baselines with frame-aligned determinism, profiling GPU passes per encoder, and writing regression probes for bugs it finds. Diagnosis logs, measurements, and decisions are recorded in STATUS.md, which the README calls the model's durable memory between sessions.

package.json exposes that harness as npm scripts, which means you can run the same comparisons yourself:

```bash
npm run shoot
npm run compare
npm run battery
```

The determinism claim is the load-bearing one. Frame-aligned diffing only works if the same seed and the same time of day produce the same frame, which is why ?freeze=1 and ?cam= exist as URL parameters. Combined with ?seed=N, they give you a reproducible input for a screenshot pipeline. That combination, deterministic world state plus a scripted camera plus pixel comparison, is the pattern worth borrowing even if you never touch the renderer. Compare it to the usual approach of eyeballing a running scene after a shader change and it is a different category of tool.

## Where LAAS is the wrong choice

If your goal is a shippable browser experience, this is not a foundation. The README states there is no WebGL fallback by design, and the page refuses to load on Firefox and Safari. That single constraint rules out a large fraction of desktop traffic and effectively all mobile traffic, since mobile browsers get a notice recommending a computer. A production renderer would need a fallback path, and adding one here means writing a second renderer, because TSL materials and raw WGSL compute do not translate to WebGL.

The scale is also a constraint. The README lists around 190,000 trees, 450,000 understory instances, roughly a million grass blades per meadow, 131,072 GPU particles, and volumetric cloud raymarching. The preset parameter exists because the high end is heavy. If you are targeting integrated graphics or a laptop from several years ago, the ultra preset is not a realistic default, and the README does not publish frame-rate numbers per preset, so you will have to measure on your own hardware.

Finally, treat the repository as a snapshot of an experiment in progress. The README says all phases of the brief are built with an ongoing performance pass, and that known open issues are tracked at the top of STATUS.md. There are no releases retrieved for this repository, and the version in package.json is 0.1.0. Nothing here promises API stability.

## Alternatives and the actual difference in approach

The obvious comparison is three.js itself. LAAS is a consumer of three.js, not a replacement, and the difference is scope rather than philosophy: three.js gives you a renderer, scene graph, and material system that work across WebGL and WebGPU, while LAAS adds a world generator on top and commits to WebGPU only. If you want to render a model you exported from Blender, three.js is the direct answer and LAAS has nothing to offer, since the repository contains no asset pipeline at all.

A second comparison is with conventional procedural terrain in WebGL, the kind built on noise functions and a heightmap texture. The mechanism differs in where the work happens. LAAS synthesizes a 4096 squared heightfield with hydraulic and thermal erosion, then scatters vegetation through GPU clustered-Poisson sampling into indirect draws. A typical WebGL terrain demo displaces a mesh from a noise texture and places objects on the CPU. The LAAS approach moves placement and culling to the GPU, which is what makes six-figure instance counts plausible, and it is also what makes a WebGL port impractical rather than merely laborious.

The third comparison is the one the repository is really about: hand-written versus model-written engine code. The README's claim of roughly 99% model authorship, with human input limited to motion feel and interactive performance, is the experiment. Whether the result is good is a judgement you make by reading src/ and STATUS.md, not by reading the README.

## Conclusion

Adopt it if you want a reference implementation for WebGPU compute, TSL materials, or GPU-driven vegetation scatter, and you already develop against Chrome. Skip it if you need Firefox or Safari support, a WebGL fallback, or a game you can ship. Before cloning, check the top of STATUS.md for the open issues the model is still working through, and confirm that your Chrome build reports a working WebGPU adapter at chrome://gpu, because the page fails loudly rather than degrading when it does not.

## FAQ

### What is the difference between Fable 5 and Mythos 5?

The repository does not mention Mythos 5 or compare the two models. It only describes Claude Fable 5 as the model that built the project, so this question cannot be answered from the repository.

### Is Claude Fable 5 any good?

The repository is a test of that question rather than an answer to it. The README states the project was built roughly 99% by Claude Fable 5 from a human-written brief, and that the model ran its own QA with headless screenshots, pixel sampling, and frame diffing. The README also says human input was still needed for motion feel and interactive performance, which static output cannot judge.

### How much does Claude Fable 5 cost?

The repository does not list any pricing for Claude Fable 5. Its only runtime dependency is three.js, and the project itself is MIT licensed.

### Is Fable returning in 2026?

This repository has no connection to any Fable game release. It is a three.js WebGPU world demo named LAAS, and the README describes it as an experiment in what Claude Fable 5 can build.

## Sources

- [Braffolk/fable5-world-demo on GitHub](https://github.com/Braffolk/fable5-world-demo)
- [Issues](https://github.com/Braffolk/fable5-world-demo/issues)
- [License: MIT](https://github.com/Braffolk/fable5-world-demo/blob/main/LICENSE)
- [Project website](https://dc5fzrbo8ssfx.cloudfront.net/laas/)
- [README](https://github.com/Braffolk/fable5-world-demo/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/braffolk-fable5-world-demo