mrdoob/slop-newyork

It is best treated as a sandbox and starting point rather than a finished game: fork it, remix it, and see what the three.js setup gives you before investing further.

The problem

You want to build a 3D city scene, and the first hours go into assembling a plausible Manhattan: streets, blocks, and enough geometry to walk or drive through. Slop New York ships an explorable version of that, so the starting point is a working scene rather than an empty grid. The README frames the result as something to fork and take in a new direction, not a product to play through.

What's different

The project is built on three.js with WebGPURenderer and TSL, and the README's explicit invitation is remixability: make games, animations, films, experiments, or something completely different. Its geographic data comes from NYC Open Data and OpenStreetMap contributors, which matters more than the feature list because it gives the scene real city coordinates rather than hand-modeled blocks.

The trade-off is that the renderer choice shapes the audience. WebGPU is not the same baseline as ordinary WebGL, so a device or browser without it may not run the demo as intended, even though the README does not spell out a fallback. The integration surface is three.js-specific: useful if you are already in that ecosystem, less so if you work in another engine. The data licensing also has two layers: the code is MIT, while OSM-derived data is ODbL and third-party dependencies keep their own licenses, so attribution and redistribution need care once you modify or publish.

Who should try it

Good fit: a three.js developer who wants a large, data-backed city scene to prototype movement, rendering ideas, or a small game on top of. Seeing a working Manhattan in the browser is a faster way to judge whether the structure suits your idea than starting from a blank scene.

Poor fit: someone who wants a game to play rather than a base to modify, or a team committed to a different engine. Changing engines would mean losing the setup that gives the project its value. Anyone planning a public derivative should also check the ODbL data terms before treating the MIT code license as the whole story.

Requirements and limitations

There is no documented setup guide here, only a live demo and the README's fork-and-remix message. Getting from that to a customized build means working through the repository's code and dependencies yourself; the README does not state a step-by-step process or supported browsers. Because the renderer uses WebGPU, hardware and browser support are the first things to confirm; the README mentions no alternate path for devices without it.

Ongoing upkeep has two parts. Rendering APIs and three.js evolve, so the WebGPU/TSL layer is the part most likely to need attention when you upgrade. Separately, if you redistribute a modified scene, you must keep track of which assets came from OpenStreetMap and what the ODbL requires, alongside the MIT code license.

HotRepo's take

HotRepo recorded 329 total stars and a #12 position on its NEW-REPOSITORY board for JavaScript on 2026-10-25, four days after creation. That is a snapshot from a new-project board, not a daily growth curve, and comparable daily history is insufficient, so persistence cannot yet be judged. The practical thing to check is the live demo on your own browser and graphics setup before forking; if WebGPU works there, the next question is whether the scene's structure matches what you want to build.