Houdini Assets vs Runtime Geometry: slop-newyork and My Garden, Profiled
> AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.
> Originally published by Alicia on 2026-10-23: Digital Garden by Alicia.
The most useful number in this comparison was the one missing from the initial headline: the library download. My local copy of slop-newyork transferred about 785 KB of compressed project files, close to the 784 KB figure in its launch post. It also fetched about 777 KB of compressed JavaScript from the Three.js CDN. Counting both made the observed encoded payload about 1.56 MB.
That does not make the original number wrong. It makes the boundary important. The same rule applies to my garden: a plant GLB, the first seasonal load and every background-preloaded season are different download budgets.
!Actual slop-newyork city and spring Digital Garden recordings with OpenStreetMap and NYC Open Data credits
Tested locally with Codex on 23 October 2026. Download the measured results. The image is from a separate recording, not one of the timed trials.
Two real scenes, two mixed pipelines
I pinned mrdoob's slop-newyork at 0049a497be6e36c79f854771f3018f8f41f07fab. I inspected its live demo and ran that source locally. It builds city geometry and TSL materials at runtime around generated geographic data; the captured load did not fetch GLB or texture files. “Procedural” does not mean “no data download.”
My garden was built from local Git revision 7a9d1cf29a60d949dbc3e72634eb53112c797182, using an isolated output directory. Its plant manifests record Houdini 22.0.429 and metre/Y-up GLB assets. But the garden layout is not a whole scene baked in Houdini: deterministic planting is implemented in TypeScript, and the browser handles instancing, LOD, wind, lighting and interaction.
The city loaded Three.js 187dev from an unpinned @dev CDN URL. The garden's package lock pins 0.186.1. This is a profile of two applications, not an A/B experiment isolating the effect of Houdini, JavaScript or a renderer version.
What went over the wire
I used the browser's Resource Timing entries, disabled the HTTP cache through DevTools protocol, and served local files with gzip level 9 and Cache-Control: no-store. CDN responses retained their real delivery encoding. These are encoded response-body bytes, excluding protocol/header overhead; decimal KB/MB are used below. This is not a public-CDN latency benchmark or a clean device/GPU-cache reset.
The “before ready” budget includes requests started before the application's loading overlay disappeared, even if their responses finished later. A small injected readiness probe adds a few hundred HTML bytes. The raw receipts preserve each resource URL and its encoded, decoded and transfer sizes.
| Observed response-body category | slop-newyork | Garden, first spring load |
| --- | ---: | ---: |
| Application JavaScript | 387,234 B | 359,646 B |
| Geographic data | 384,199 B | — |
| Three.js CDN JavaScript | 777,277 B | Included in app bundles |
| GLBs | 0 B | 2,982,529 B across 36 requests |
| HTML, CSS, manifests and other files | 13,710 B | 23,783 B |
| External font CSS observed | 723 B | 0 B |
| Before-ready total | 1,563,143 B | 3,365,958 B |
The captured city dependency graph included three.webgpu.js, three.tsl.js, three.core.js and addons. Looking only at the repository's JS files would miss those requests. The first-party subtotal is 785,143 B; it is a measured local subtotal, not an exact reproduction of the author's compression process.
The garden continued preloading. At the later recorded snapshot, its cumulative observed response bodies totaled 18,369,320 B, including 72 GLB requests. That is a later network snapshot, not a required first frame payload or a complete four-season download inventory. It would be misleading to put that number beside the city's initial project-only subtotal and call the ratio a pipeline result.
Same render size, different work
The machine was a Ryzen 9 9950X with an RTX 5070 Ti, Windows and Chromium 155. Both applications actually rendered through WebGPU at 1920×1080, renderer DPR 1, displayed in a 1280×720 browser viewport. I checked drawing-buffer dimensions; the garden's ?benchmark mode fixes them to 1080p regardless of the CSS viewport. An earlier 1280×720 city run is retained only as an exploratory record.
I ran three 30-second observations per scene, with one GPU test page active at a time. For the city, the sequence spent ten seconds each on chase, observatory and drone presets. The preset order is repeatable; the moving city and director do not create pixel-identical trajectories. The garden used its resettable 40-second benchmark orbit, sampled for 30 seconds, with the spring scene and default high quality. Each scene kept its own lights and effects.
| Observation | slop-newyork | Spring garden |
| --- | ---: | ---: |
| Average FPS, run 1 / 2 / 3 | 59.79 / 59.96 / 58.89 | 52.25 / 50.84 / 50.01 |
| Median of run averages | 59.79 | 50.84 |
| Median frame interval | 16.7 ms | 16.7 ms |
| 95th-percentile frame interval | 16.8 ms in all runs | 33.4 ms in all runs |
| Median reported draw calls by run | 663 / 675 / 692 | 68 / 68 / 68 |
| Median submitted triangles by run | 10.11M / 9.79M / 10.17M | 9.34M / 9.62M / 9.37M |
Frame intervals came from requestAnimationFrame; counters came from each application's existing renderer telemetry. The garden publishes its counters periodically, so repeated samples of one counter value are not independent frame observations. Counters include each application's rendering passes and are not an audited comparison of identical GPU commands. Submitted triangles are not the number of unique mesh triangles in the project.
The city was close to this display's 60 Hz ceiling. I cannot infer its uncapped throughput from 60 FPS. The garden's much lower draw-call count did not guarantee a lower frame time: draw calls alone leave out pixel cost, material complexity, overdraw and rendering passes. This test did not isolate which of those costs caused the difference.
Claims these measurements cannot support
These measurements do not establish that code procedural is smaller in general, that Houdini is faster, or that my whole garden layout was baked. Neither application is a pure category. No matched hybrid asset replacement was performed, so there is no measured hybrid byte-saving result.
I did capture application-visible readiness during local loading, but did not turn that into a first-frame ranking. Overlay transitions, compilation, HTTP fetches, GPU caches and concurrent setup work have different scopes. The evidence contains exploratory timestamps; it does not contain an accepted device-cold, GPU-fenced first-frame comparison for these applications.
No physical phone, WebGL2 performance comparison, GPU timer-query study, author token cost or untouched AI-agent benchmark was tested here. The launch post's reference to tokens does not establish exactly how every part of the project was authored.
The production decision I would take from this
I would use compact runtime parameters when many variations can be reconstructed cheaply, and authored assets where shape control and close-up quality justify the geometry payload. For the garden, that means keeping its current mix: procedural plant authoring, explicit web assets, and runtime planting and motion. A further optimization needs a matched element, equal appearance targets and measured quality loss; these two complete scenes cannot supply that result by themselves.
The immediately actionable habit is to report three numbers separately: project files, shared dependencies and the actual initial load. Then report later preloads as a different budget. That makes a small demo's achievement easier to understand without turning it into a universal winner.
Credits and evidence
slop-newyork code © its authors, MIT. City geography: © OpenStreetMap contributors, ODbL, and NYC Open Data; retain these credits with the screenshots and video. Digital Garden imagery © Alicia. Source, license and provenance are retained with the local clone.
Results and method. Raw frame observations: city-1080 run 1, city-1080 run 2, city-1080 run 3, garden run 1, garden run 2, garden run 3. The byte table uses Resource Timing rather than the truncated diagnostic network-event log.
Continue with the Three.js rendering guide or visit the garden.
---
Read the original article, supporting data and updates.
Mentions
I made a drivable 3D Ann Arbor from the city’s open data I've been building a little open-world Ann Arbor you can walk, drive, bike, fly, or paddle around in: mrubens.github.io Not quite GTA 6, but GTAA will have to do for a couple more weeks. It's built on a ton of amazing open data and open source code: City of Ann Arbor - Building footprints: ckan.a2gov.org - Street trees: a2gov.org - Urban tree canopy: a2maps.a2gov.org - 2023 impervious surfaces (driveways and walks): a2maps.a2gov.org - Streetlights: a2gov.org - Road centerlines (speed limits): a2maps.a2gov.org - Fire hydrants: ckan.a2gov.org - Park amenities: ckan.a2gov.org - Address points: ckan.a2gov.org - Land use: ckan.a2gov.org - Historic districts: ckan.a2gov.org Live - National Weather Service (current conditions at Ann Arbor Municipal Airport): weather.gov - USGS Huron River at Ann Arbor gauge: waterdata.usgs.gov Transit - TheRide timetable feed: theride.org - Amtrak timetable feed (Wolverine): content.amtrak.com Maps and terrain - OpenStreetMap: openstreetmap.org - Terrain Tiles (Mapzen and USGS elevation): registry.opendata.aws Built on - Slop New York by Mr.doob, the game this started from (MIT license): mrdoob/slop-newyork - Mr.doob also made three.js, which the game is drawn with: threejs.org Source code if you want to report bugs or build on it: mrubens/go-to-ann-arbor
Elderwake: three.js browser game and free to play. elderwake-kaiju.vercel.app Major updates to every system. I've been working on this extension of a base project repo from @mrdoob called Slop New York on Github (mrdoob/slop-newyork). Turned it into an Earth Defense Force styled game with much more planned to come like multiplayer, pvp, saved profiles with permanent unlocks, skins, and mechs. I think everyone can enjoy this one now as it's in pretty good shape to throw it out there as an alpha test. Have Fun and thanks for play testing!
Flying car simulator over a 1:1 Manhattan, built on mrdoob's Slop New York (three.js WebGPU) I took mrdoob's Slop New York and had Claude Opus 5.5 turn it into a flying car sim. You drive a Roadster through Manhattan, jump, and fly it with thrusters. Press U for Ludicrous mode (unlimited air). - Built with three.js WebGPU - 1:1 Manhattan streets, real landmarks, live traffic - The flight in the video is an autopilot script. Cruise sped up 1.5x, clips cut together Play: flyingcarsimulator.io Original: mrdoob/slop-newyork Happy to answer questions about how it's put together.
Houdini Assets vs Runtime Geometry: slop-newyork and My Garden, Profiled > AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article. > Originally published by Alicia on 2026-10-23: Digital Garden by Alicia. The most useful number in this comparison was the one missing from the initial headline: the library download. My local copy of slop-newyork transferred about 785 KB of compressed project files, close to the 784 KB figure in its launch post. It also fetched about 777 KB of compressed JavaScript from the Three.js CDN. Counting both made the observed encoded payload about 1.56 MB. That does not make the original number wrong. It makes the boundary important. The same rule applies to my garden: a plant GLB, the first seasonal load and every background-preloaded season are different download budgets. !Actual slop-newyork city and spring Digital Garden recordings with OpenStreetMap and NYC Open Data credits Tested locally with Codex on 23 October 2026. Download the measured results. The image is from a separate recording, not one of the timed trials. Two real scenes, two mixed pipelines I pinned mrdoob's slop-newyork at 0049a497be6e36c79f854771f3018f8f41f07fab. I inspected its live demo and ran that source locally. It builds city geometry and TSL materials at runtime around generated geographic data; the captured load did not fetch GLB or texture files. “Procedural” does not mean “no data download.” My garden was built from local Git revision 7a9d1cf29a60d949dbc3e72634eb53112c797182, using an isolated output directory. Its plant manifests record Houdini 22.0.429 and metre/Y-up GLB assets. But the garden layout is not a whole scene baked in Houdini: deterministic planting is implemented in TypeScript, and the browser handles instancing, LOD, wind, lighting and interaction. The city loaded Three.js 187dev from an unpinned @dev CDN URL. The garden's package lock pins 0.186.1. This is a profile of two applications, not an A/B experiment isolating the effect of Houdini, JavaScript or a renderer version. What went over the wire I used the browser's Resource Timing entries, disabled the HTTP cache through DevTools protocol, and served local files with gzip level 9 and Cache-Control: no-store. CDN responses retained their real delivery encoding. These are encoded response-body bytes, excluding protocol/header overhead; decimal KB/MB are used below. This is not a public-CDN latency benchmark or a clean device/GPU-cache reset. The “before ready” budget includes requests started before the application's loading overlay disappeared, even if their responses finished later. A small injected readiness probe adds a few hundred HTML bytes. The raw receipts preserve each resource URL and its encoded, decoded and transfer sizes. | Observed response-body category | slop-newyork | Garden, first spring load | | --- | ---: | ---: | | Application JavaScript | 387,234 B | 359,646 B | | Geographic data | 384,199 B | — | | Three.js CDN JavaScript | 777,277 B | Included in app bundles | | GLBs | 0 B | 2,982,529 B across 36 requests | | HTML, CSS, manifests and other files | 13,710 B | 23,783 B | | External font CSS observed | 723 B | 0 B | | Before-ready total | 1,563,143 B | 3,365,958 B | The captured city dependency graph included three.webgpu.js, three.tsl.js, three.core.js and addons. Looking only at the repository's JS files would miss those requests. The first-party subtotal is 785,143 B; it is a measured local subtotal, not an exact reproduction of the author's compression process. The garden continued preloading. At the later recorded snapshot, its cumulative observed response bodies totaled 18,369,320 B, including 72 GLB requests. That is a later network snapshot, not a required first frame payload or a complete four-season download inventory. It would be misleading to put that number beside the city's initial project-only subtotal and call the ratio a pipeline result. Same render size, different work The machine was a Ryzen 9 9950X with an RTX 5070 Ti, Windows and Chromium 155. Both applications actually rendered through WebGPU at 1920×1080, renderer DPR 1, displayed in a 1280×720 browser viewport. I checked drawing-buffer dimensions; the garden's ?benchmark mode fixes them to 1080p regardless of the CSS viewport. An earlier 1280×720 city run is retained only as an exploratory record. I ran three 30-second observations per scene, with one GPU test page active at a time. For the city, the sequence spent ten seconds each on chase, observatory and drone presets. The preset order is repeatable; the moving city and director do not create pixel-identical trajectories. The garden used its resettable 40-second benchmark orbit, sampled for 30 seconds, with the spring scene and default high quality. Each scene kept its own lights and effects. | Observation | slop-newyork | Spring garden | | --- | ---: | ---: | | Average FPS, run 1 / 2 / 3 | 59.79 / 59.96 / 58.89 | 52.25 / 50.84 / 50.01 | | Median of run averages | 59.79 | 50.84 | | Median frame interval | 16.7 ms | 16.7 ms | | 95th-percentile frame interval | 16.8 ms in all runs | 33.4 ms in all runs | | Median reported draw calls by run | 663 / 675 / 692 | 68 / 68 / 68 | | Median submitted triangles by run | 10.11M / 9.79M / 10.17M | 9.34M / 9.62M / 9.37M | Frame intervals came from requestAnimationFrame; counters came from each application's existing renderer telemetry. The garden publishes its counters periodically, so repeated samples of one counter value are not independent frame observations. Counters include each application's rendering passes and are not an audited comparison of identical GPU commands. Submitted triangles are not the number of unique mesh triangles in the project. The city was close to this display's 60 Hz ceiling. I cannot infer its uncapped throughput from 60 FPS. The garden's much lower draw-call count did not guarantee a lower frame time: draw calls alone leave out pixel cost, material complexity, overdraw and rendering passes. This test did not isolate which of those costs caused the difference. Claims these measurements cannot support These measurements do not establish that code procedural is smaller in general, that Houdini is faster, or that my whole garden layout was baked. Neither application is a pure category. No matched hybrid asset replacement was performed, so there is no measured hybrid byte-saving result. I did capture application-visible readiness during local loading, but did not turn that into a first-frame ranking. Overlay transitions, compilation, HTTP fetches, GPU caches and concurrent setup work have different scopes. The evidence contains exploratory timestamps; it does not contain an accepted device-cold, GPU-fenced first-frame comparison for these applications. No physical phone, WebGL2 performance comparison, GPU timer-query study, author token cost or untouched AI-agent benchmark was tested here. The launch post's reference to tokens does not establish exactly how every part of the project was authored. The production decision I would take from this I would use compact runtime parameters when many variations can be reconstructed cheaply, and authored assets where shape control and close-up quality justify the geometry payload. For the garden, that means keeping its current mix: procedural plant authoring, explicit web assets, and runtime planting and motion. A further optimization needs a matched element, equal appearance targets and measured quality loss; these two complete scenes cannot supply that result by themselves. The immediately actionable habit is to report three numbers separately: project files, shared dependencies and the actual initial load. Then report later preloads as a different budget. That makes a small demo's achievement easier to understand without turning it into a universal winner. Credits and evidence slop-newyork code © its authors, MIT. City geography: © OpenStreetMap contributors, ODbL, and NYC Open Data; retain these credits with the screenshots and video. Digital Garden imagery © Alicia. Source, license and provenance are retained with the local clone. Results and method. Raw frame observations: city-1080 run 1, city-1080 run 2, city-1080 run 3, garden run 1, garden run 2, garden run 3. The byte table uses Resource Timing rather than the truncated diagnostic network-event log. Continue with the Three.js rendering guide or visit the garden. --- Read the original article, supporting data and updates.
Elderwake: kaiju attack themed three.js game elderwake-kaiju.vercel.app Original credit for city repo "Slop New York" mrdoob/slop-newyork @mrdoob Mrdoob, Thank you for the headstart with your Slop New York repo. I've had a lot of fun feeding Opus tokens and ai slopping it into a Godzilla / kaiju / Pacific Rim / Evangelion Neon Genesis / Gundam Wing type thing. @mrdoob your work was truly inspiring. I didn't realize how expansive a world was possible with three.js as I've only been working with it for like... less than two months now 😅 Seriously though, it's been a lot of work directing my vision into these ai coded projects. Whoever said one prompt and poof you have this perfect game is a liar and a fraud... it doesn't work like that. It's probably more frustrating than hand coding everything. The idea here is that we get a lot more done in a short amount of time instead of taking years with huge teams. Here's my original Backrooms inspired passion project. I wanted to create an online multiplayer version of the backrooms that seems endless and procedurally generated. This world is MASSIVE with much to explore here and several hidden zones like level ! Run and the neighborhood zone. backrooms.86.com They both need a lot of work, but what we have here are prototypes to flesh out and the full game loops are in place. We're not copying games; we are exploring possibilities with all this new technology. Every apprentice or student of the arts studies the masters and copies their work until they reach the level where they can properly execute their own original visions. Enjoy and stay tuned as I continuing building these two games and others since I have what seems to be ADHD and can't stay on just 5 projects at any given time... Thank you in advance for all your support and again to @mrdoob for the original main code for Elderwake! Have fun and leave suggestions. I read them all! Haters and negative shills, please just block me instead of replying to my posts. I don't need the toxicity. Yes I know, the real kaiju models are coming... I've only had two days on this one so far and the player model took a minute or two... not to mention all the other systems and full game loop logic, destructive buildings, stripping out unused code etc.
Es del creador de Three.js, usa WebGPU (se nota bsatante el buen rendimiento) y es totalmente de código abierto: mrdoob/slop-newyork ¡Me encanta! mrdoob/slop-newyork
mrdoob.github.io Kod: mrdoob/slop-newyork (MIT, 152 yıldız). Harita NYC Open Data ve OpenStreetMap verisi, ODbL lisanslı; video ya da oyunda OSM kaynak satırı şart. WebGPU kullanıyor, güncel Chrome ya da Edge'de açın.
mrdoob.github.io Kod: mrdoob/slop-newyork (MIT, 152 yıldız). Harita NYC Open Data ve OpenStreetMap verisi, ODbL lisanslı; video ya da oyunda OSM kaynak satırı şart. WebGPU kullanıyor, güncel Chrome ya da Edge'de açın.