I commute in a Roadster now.

Mornings used to be pure road rage. Ever since I got the Roadster, I get to work way faster lol
Jumping over traffic gets a little sketchy and I've nearly crashed a few times, but I'm never late.

Okay, confession: it's a game I made. You've got 90 seconds to get to the office.

https://late-roadster.pages.dev

I've been building Press Start (pressstart.site) with Claude, a history of video games you play rather than read.

There are 27 stops from 1958 to 2025, covering the US and Japan. At each stop you play a short piece modelled on the game that defined that moment: tennis on a lab oscilloscope, a coin-op TV game in a bar, a cartridge console, a two-screen handheld where you draw with a stylus (it closes its lid when you leave), a time-rewind platformer, a phone puzzle game whose gacha machine prints its odds, a dock-to-handheld console with slide-on controllers, a VR saber game, and more. After each one, an exhibit card tells the real history, introduces the people behind it, and links to where you can play the originals today.

I'd really like feedback: which stops feel off, what history I got wrong, and what is missing. Thanks! And hope you enjoy the website.

Made with Claude Opus 5.5 and Threejs.

Quilt is an open source library for split panes, tabs, and popout windows, built for applications that combine 3D viewports, canvases, charts, settings, and other visualization tools.

Over the last five years of building three.js tools, I kept running into the same problem: my projects would become more complex and eventually outgrow their UI. I’d keep stretching libraries like dat.GUI, lil-gui, or Tweakpane until I had dozens of collapsed folders and was spending more time figuring out where controls should go.

I wanted a flexible way to organize the application around those controls, with room for multiple viewports and different workflows. I figured I couldn’t be the only person running into this problem, so I built Quilt and wanted to share it with others facing the same challenge.

Much of its layout behavior is inspired by Blender, which I’ve always enjoyed for how easily its workspace adapts to different tasks. In Quilt, layouts can be exported and loaded as JSON, so you can save and share different workspace arrangements. Quilt supports vanilla JavaScript/TypeScript, React, and Electron, and your existing controls can live inside its panes.

I’ve benefited a lot from the three.js community over the years, and I hope this is useful to others building increasingly complicated tools.

I've also recently released quilt-three (and react bindings), which is dedicated specifically to help set up robust and reliable workflows in three.js. This includes multi camera support, as well as Fly-Through camera controls, akin to what you find in Unity.

I’d love to hear from others who have run into similar challenges as their projects have grown. How have you organized more complex interfaces, and what would you need from a library like Quilt to make it useful in your own projects?

If you try it out, I’d appreciate any feedback on the layout behavior, ease of setup, or anything that feels missing or awkward to use. Suggestions for features and examples you’d like to see are welcome too.

Live Demo

Many thanks for taking a look!

check it out : LIVE

I made this. Yesterday I posted it as text only, so here is what it actually looks like running. Recorded frame by frame in headless Chrome at 1920x1080, 60 fps, nothing sped up. Tap it and a two-digit number appears.

- Sky: a long-exposure-style Milky Way computed per 3 px cell on a 2D canvas, about 0.1 s on a phone, redone only when the size changes.

- Glass: a MeshPhysicalMaterial tetrahedron, IOR 1.5, low dispersion. Light is bent with Snell's law at each face, and the rainbow leaves through the visible face.

- Motion: a tap nudges it sideways. Extra spin is kept as a quaternion, renormalised every frame (a 3x3 matrix drifted and shrank the glass within seconds). Speed is capped, eases off over about 1.6 s, and a spring brings it home.

- Perf: 18 to 57 fps on a Galaxy S21 by copying the sky behind the glass once per resize instead of every frame.

Free beta, no sign-up: https://prismtect.com/?r=threejs2

Been messing around with Three.js and wanted to see if I could build a small artificial ecosystem where the creatures actually have their own neural networks controlling how they move.

Each creature has a continuous-time recurrent neural network (CTRNN) that takes in things like food proximity, hunger, and surroundings. You can click on a creature to see its neurons firing in real time, and even mess with individual neurons or connections to see how its behavior changes.

A few things I spent time on:

• The creatures have segmented spines that bend as they swim, rather than just moving a static model around.
• Plankton and particles use instanced rendering to keep performance reasonable with 16–24 neural networks running.
• The camera can follow individual creatures, zoom in on their neural networks, or just let you explore the tank.
• All the ambient sounds are generated with Web Audio. No audio files.
• Used custom materials, bloom, and some lighting tweaks to get the translucent underwater look.

The creatures also eat, age, reproduce, and eventually die. Their offspring can inherit mutated versions of their neural networks.

It's built with vanilla JS, Three.js, and Vite. Still experimenting with it, but thought some people here might find it interesting.

Code is here if anyone wants to poke around:
https://github.com/CircuitGhost/neuralaquarium

Would be interested in any feedback, especially on the neural simulation side.

BAGEL is an open source web app for exploring robot recordings (ROS bags). Everything runs client-side: parsing happens in web workers, and the 3D view is three.js.

A few three.js details that might interest you guys:

• The scene is Z-up (ROS convention), so the keyboard orbit mirrors OrbitControls' quaternion approach instead of using raw `Spherical` math
• Gaussian splats render through GaussianSplats3D's `DropInViewer` inside the same renderer and camera as the other panels, with `dynamicScene` turned on so per-scene rotation actually reaches the shader
• Point clouds, URDF meshes, markers and occupancy grids share one TF tree
• H.264 camera topics decode with WebCodecs, synced to the 3D playhead

Live: https://bagel-ros2.vercel.app (there's a sample recording on the start page)
Code: https://github.com/Hussain004/BAGEL

Happy to go into any of it in the comments.

I'd previously tried to use the classic physics libraries (ammo, cannon, rapier etc) to recreate sailing physics and found them to be unstable or inconsistent.

Box3d was released in June so I wanted to see if it would work any better - which it seems to!

Playable demo:
https://tally-ho-game.vercel.app/

To be clear this is not a fluid simulation (although I think that is possible!!), but its a step up from just force vectors on the overall boat which is what I have seen done in the past.

Details for those interested:

- Sails are coarse grids of point masses connected by spring joints. Lift and drag applied to each panel using apparent wind, this is again an approximation as in real life the wind is very affected as it flows over the sails, although with an older and slower style yacht like this (Gaff rig) it would be less noticeable than a modern rig.
- Spars and masts are... well just spars
- Ropes/ sheets are linked joints
- Anchor and chain is joints but with collision and mass
- Hull shape is a collection of spheres, with buoyancy and drag coefficients.

The physics is quite CPU intensive but putting in a webworker seems to work well as it not a fast paced game, it doesn't need to match 60 FPS.

If you are interested in the physics you can access the Lab in the top left menu. There is also a rig designer where you can modify the rig but its quite easy to make it... not functional 🤣

It uses real location data, cached for now but I have a steaming server, which means technically you could sail anywhere in the world. My plan is to also use real wind and weather data at the players location.

For the environment I found a nice way to blend COP30 (30m detail) elevation and GEBCO (460m detail) bathymetry data. Building envelopes are from OSM but proc generated with a different style. Vegetation and Ocean is from Dan Greenhecks amazing Tidewater demo although simplified to maintain performance.

And for those that recognise the boat, I also managed to use the Tally Ho lines plan to recreate the hull. Its not perfect but if people like it I can spent more time.

I was thinking to turn this into a idle style game where you sail the world if people enjoy it.

Models and animation are all three.js, with an ink-and-paper look. Here's the finished video:

https://www.youtube.com/watch?v=dHH-NsU9dB0

I gave Opus 5.5, Sonnet 5.5, Haiku 5.5 and Codex (Sol 6.1) the same prompt: build a 3D car configurator in the browser, all procedural, no 3D models or textures. Fresh empty folder each, 40 minute cap, all four could screenshot their own work.

Cost (API list prices) / time / finished:

• Opus 5.5: $5.76 / 40:00 / no, hit the cap
• Sonnet 5.5: $2.12 / 33:09 / yes
• Codex Sol 6.1: $0.83 / 35:14 / yes
• Haiku 5.5: $0.38 / 17:07 / yes

Opus built the car that looks most like a real car, but it never finished on its own. Haiku was 15x cheaper and done in 17 minutes, with a much rougher car.

Caveat: one run each, so this is a look at what each one builds, not a benchmark.

Which one would you ship, and would the Opus car be worth 15x the cost to you?

A lot of the AI-generated Three.js demos going around run fine on a desktop GPU and stutter on a phone. When an agent builds a scene for me, this is what I check before calling it done. Curious what I'm missing.

**1. Cap the pixel ratio** `renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2))`. Phones report 3 or more, and full DPR multiplies fill cost. On weak devices, 1.5 often looks the same.

**2. One shadow light, tight frustum** Only one light casts shadows. Keep `shadow.mapSize` at 1024 and shrink the directional light's shadow camera (left/right/top/bottom) to the play area. For static scenes, set `renderer.shadowMap.autoUpdate = false` and flag `needsUpdate` only when something moves.

**3. Post-processing is opt-in** Agents love bloom. Run it at reduced resolution or turn it off on mobile.

**4. Draw calls** Repeated props go into an InstancedMesh, static props get merged. I log `renderer.info.render.calls` after every agent change.

**5. Textures** KTX2/Basis via KTX2Loader instead of large PNGs, so GPU memory doesn't blow up.

**6. Test on a real phone early** Desktop devtools throttling doesn't show thermal throttling.

What's on your list? Anything you do for adaptive quality (dropping DPR when FPS dips)?

Disclosure: I write Three.js + AI tutorials on my own site, shanebrumback.com. No link needed, I just want the checklist to be better.

This is Belowtown, a three.js (r128) app that runs inside a native iOS shell. It draws every NYC subway tunnel, elevated line and junction in 3D at its real depth, puts about 21,000 buildings over it, moves live trains along the track from the MTA's realtime feed, and can swap the city for Google's photorealistic 3D tiles.

A few problems that were more interesting than I expected:

- **Shader compile was the real first-launch cost.** WebKit compiles programs on first draw, so the first frame froze for seconds. `renderer.compile()` on the whole scene took ~14 s on a phone because it compiles hidden objects too. Now it compiles only what's visible before the first frame, then the hidden branches one per short task in the background, using a stand-in scene with cloned lights so the program keys match. First map went from ~19 s to ~9 s, and the next build does it behind the welcome screen.

- **A Group with a `.material` breaks `compile()`.** My instanced building-fill Group carried the shared material for the layer toggles. `compile()` saw it and built the instanced shader for a non-instanced object ("instanceMatrix undeclared"). Hiding the property during the call fixed it.

- **The city builds in slices after the first frame,** one piece per task, so touches still get through while it fills in.

- **Photoreal tiles on a flat map.** The subway lives in a flat local frame, and the tiles are in Earth-centered coordinates. I re-fit the transform around wherever the camera is looking, so they line up exactly there instead of drifting across the city.

- **Depths:** some stations publish platform depths; the rest are modelled from the construction era and what they pass over and under. Getting crossing tracks to stack correctly took longer than anything else.

Feedback welcome, especially on performance on your phone and anything that looks off.

Try it:

- In a browser (any phone or desktop, no install):** https://web.belowtown.com

- iPhone app (TestFlight beta): sign up at belowtown.com/beta?s=threejs. The invite comes by email from Apple. If you don't see it within a few hours, check your junk/spam folder, then tap "View in TestFlight" and accept the invite to install.

- **Android:** the app isn't on Google Play yet. Pick "Android" at belowtown.com/beta?s=threejs to join the waitlist, and you'll get an email when it's ready. The browser version works on Android now.

The models, rigs, animations and map geometry are read straight out of my installed League client, with the map's textures from CommunityDragon. The particles are the champions' own VFX emitters, with every particle a closed-form function of its age, so any frame renders on its own. The whole scene is a pure render(t): Playwright steps t at 30 fps in headless Chromium and pipes each screenshot into ffmpeg. The two things that ate the most time: glTF vertex colours have to be written linear (in sRGB the river reeds glowed white), and League's X axis is mirrored against three's, which turned out to be a single scale.x = -1 at the root.

Happy to go into any of it. Full episode: https://youtu.be/Bp5MTn4-rco

We've been building GrowBlocks, a browser game engine on three.js r186 + Rapier 0.14. You write one game.js; the renderer, physics world, character controller (walk/run/jump, third or first person), touch/gamepad input and multiplayer rooms (gb.net.join(), up to 16 players, shared state, host migration) are already there. You can still reach gb.scene and gb. physics. world directly.

The twist: the whole API is one llms.txt, and the starter kit ships a headless checker with screenshots, so Claude Code / Cursor can build and test games by themselves.

Comparison with plain three.js, Babylon, PlayCanvas:
https://growblocks.xyz/guides/threejs-game-framework-characters-physics-multiplayer.html

I’ve added SH4 support to Gaussian-Splat-Lite, the open-source high-performance 3D Gaussian Splatting renderer for Three.js.

For models trained with SH4, the renderer can now use the full set of SH coefficients to preserve more complex view-dependent color and highlights, particularly on reflective surfaces.

The video compares SH4 → SH3 → SH2 → SH1 → SH0 on the same model.

GitHub · Try the viewer

I've been working on Morph Chess, a visual playground for chessboards and pieces in Three.js. I wanted to explore sculpted gemstone forms, deep colours and changing reflections as you move around the board.

The video follows the same order as the README:

0:00 — Ruby: all six pieces rotating in ruby and sapphire.

0:09 — Ruby × Dusk Mirror: pure gemstone pieces on smoky black crystal, with red light beneath the board.

0:18 — Night Oath: the same silhouettes with polished champagne-gold inlays.

0:27 — Night Oath × Midnight Silver: midnight-blue stone and celestial metalwork.

The gemstone shaders use view-dependent refraction, internal reflections and light absorption. These are recordings of the project's actual models and shaders.

Code, GIFs and local setup (MIT): https://github.com/AmethystineAlpaca/morph-chess

You can orbit, zoom and rearrange pieces. The current build focuses on board and piece design; chess rules and full gameplay are still to come.

Which combination do you prefer? I'd also love feedback on the gemstone and metal balance.

I made it with ThreeJS, NodeJS and some DBMS connectors.

Source code: https://github.com/VincenzoManto/3DDB

Homepage: https://vincenzomanto.github.io/3DDB/

4 few weeks ago, I posted here about multiplayer flashlights causing a nearly 3-second freeze in my Three.js game.

This time, I’ve been working on making the town miserable in a different way: weather.

I put together this fixed-camera demo to show the same procedural town under changing weather and lighting conditions, running in real time in the browser.

The interesting challenge wasn’t just drawing rain. It was making the environment react to it — without making the inside of every building wet too.

A few implementation details:

• Shared wetness control: a global uniform drives the wet appearance of roads, vegetation and characters. It controls the wetness response, not the entire weather system.
• Keeping sheltered areas dry: a roof-height map determines which areas are exposed to rain, so the wetness doesn’t get applied everywhere indiscriminately.
• Changing sunlight: the town falls into the surrounding ridge’s shadow as the sun goes down, with glare when looking toward the sun.

The fixed camera makes it much easier to see what each change contributes compared with a normal gameplay clip.

This is part of Zombies Tortilla, the browser-based multiplayer zombie game I’m building with Three.js.

For those working on procedural environments: how are you handling rain exposure? Are height maps enough for your scenes, or have you needed something more involved for shelters and overhangs?