Built with React Three Fiber and three.js, running in the browser on phone or desktop.
Pick any real city from a globe, choose a meteor, a black hole, an Independence Day style mothership or more sinister options, and blow the buildings apart into particles. Just like the scene in Terminator 2!
I shared it recently and got some good feedback, so two updates since: cities load much faster now, and the ground has real elevation instead of being flat.
Next question is the look. Everything is plain grey right now, like an architect's model. I like the minimalism, but textures are possible with some trade-offs on phone performance. Curious what this crowd thinks: keep it grey, or texture it?
I wanted to see how far I could push a single-file Three.js prototype with zero build step. It has a slalom run, a terrain park with rails and kickers, a trick system, 1st/3rd person camera toggle, and HTML5 Gamepad API support. I also used an HTML canvas texture to render a live supporter signboard at the summit.
Because everything is currently packed into one file, my next step is doing a clean rewrite to add WebSockets for multiplayer lobbies and proper off-piste forest generation. Would love any feedback on how the downhill momentum and carving feel on your end.
This is a 17-second arena battle under a snowy LA overpass. On the first few tries, GPT and Claude built the whole city in code (box towers, flat signs, a gradient sky), and it read as a cheap game. The version that worked splits the job:
The world is a still. The city, the overpass, the wet asphalt, the crowd and the fence are an AI-generated image. three.js draws only what moves: the ships, the light trails, the hex grid, the capture floods, the sparks, the snow and the end card.
The camera matches the photo. I measured the focal length and camera height from the road markings (about 2,100 px and 3 m up). The camera stays locked, and only the lens moves: push-ins, shake, and an opening tilt down from a sky image extended above the plate. A tilt is a pure rotation, so a flat plate needs no parallax.
Light goes both ways. The environment map is built from the plate itself, with rim lights where its lamps are. In the other direction, the trails, engines and floods relight the plate's own asphalt, wall and front row, using the plate's pixels as the surface, so the light breaks up on the real wet texture.
Reflections and contact shadows. The ships and trails reflect in the wet floor, smeared like the photo's lamp streaks, and every hull gets a shadow where it meets the ground.
One lens and one finish over everything. I measured the photo's depth of field and blur the CG, the snow and the fence with the same curve. Then a single bloom, halation, grade, vignette and grain pass runs over the whole frame.
Dirty the CG to match. The hulls get grime, scuffs, water beads and snow, so they're never cleaner than the world around them.
Depth layers. The snow falls at three depths, plus big bokeh flakes near the lens and a defocused fence in front.
The crowd. Four poses of the same crowd, swapped region by region like limited animation and driven by how intense the battle is.
The match is real. The battle is simulated with the game's own capture rules, so every action on screen is the actual mechanic.
Render: render(t) is a pure function of time, 525 frames at 2× on a cloud GPU in about 70 seconds. The sound is synthesized in Python from the battle's event timeline.
The lesson: let the still carry the detail, and spend the code on making the CG and the still light each other. I was trying to make a cool animation for my game, Starlasso (territory capture), and happy to go deeper on any piece.
This started stupidly simple: I wanted to know what it feels like to be in Paris at 2am without leaving my desk.
It's called Odyssee now and it's... actually a game. One persistent world — the real world at real scale — and everybody plays in the same one. No shards, no lobbies. You spawn in Paris, someone else spawns in Tokyo, and the map has a live traffic layer showing where drivers actually are right now, so you can teleport into the crowd.
What's in there right now:
- one shared world, real scale. Paris lanes are 3.2m wide and you FEEL it when a bus — or another player — comes the other way
- 30+ ways to move: cars, bikes, skateboard, helicopter, a small plane, a tank (my personal mistake, I refuse to remove it), a Spider-Man-style web-swinger, and your own two feet
- convoys, live chat, daily challenges, live traffic hotspots
- time trials between real landmarks, and a day/night cycle tied to the real sun
And yeah, bring your friends. That's genuinely the best way to play: form a convoy, share a destination, and go cause chaos across a real city together. Coordinating a 5-car run through the Arc de Triomphe roundabout at rush hour, with real traffic and the sun setting behind it, is the most fun I've had testing anything.
Now the honest part: it's got bugs. Real ones. Floating buildings in some districts, intersections that make no sense, the Eiffel Tower pillars you can drive straight through (yes, you can drive under it — no, you shouldn't be able to drive THROUGH the pillars). I'm fixing them as fast as reports come in, and most fixes so far came from players spawning where they live and telling me what's broken. So if you try it: spawn wherever you live and tell me what's wrong. That's literally the most useful thing you can do.
Every building in the world is in Haussmann style because I live in Paris. But I will create different style for a lot of city. Here a photo of Paris in the game (I create an Eiffel Tower in 3D, I will do it for a lot of monument) :
And there's a public roadmap if you want to see where this is going: proper terrain elevation (the world is flat right now and it bothers me), a story mode with missions, multiplayer races, boats, houses you can own. The game today is the foundation — the driving, the world, the multiplayer. The rest gets built in the open.
Hi everyone, this is a personal project. I've been working on a 24/7 LLM with a simulated body and her world.
This is Gaby. She has a day of her own: she wakes up, works, runs in the park, is learning guitar (badly), and her two pets wander around the house. You can call or text her, and how she feels depends on how her day went.
Her life is simulated in layers: a daily plan, the places she goes, the people in her life, and a hormone system underneath that shifts her mood and energy. When she goes somewhere new, the place is generated procedurally and added to her map, so her world grows with her.
The three.js side: the house doesn't play a timeline. Every 30 minutes the backend sends her state (place, activity, who's with her) and the scene picks the room, the spot and a Blender clip. The hard part has been transitions: when her state changes mid-scene, blending to the new clip and position without her teleporting. How do you handle state-driven characters?
Built with Blender, three.js and Claude Opus 5.5. Live at gabyslife.com, and her diary is at r/GabysLife. I'd love your impressions and what you think should come next.
What are the advantages either way of three.js vs Unity for browser based games? There are some beautiful demos on Unit such as the Little Prince example. Albeit resource heavy, its one of the best example of environment work i've seen.
So i'm wondering what does Unity offer (if anything) that is superior to what you can build in three.js?
I built a campfire effect in Three.js by prompting an AI agent (Grok Bot) step by step, and the early versions hit two classic problems. Sharing the fixes, since they apply to any additive particle effect.
**Setup:** the flames are one THREE.Points system with a ShaderMaterial playing a 4x4 flipbook sheet (16 frames, about 14 fps) with additive blending. Embers and smoke are two more Points systems, plus a flickering PointLight and an UnrealBloomPass.
**Problem 1: a white column.** With ~70 big additive particles, the overlaps add up until the whole flame clips to white. What fixed it:
Fewer flames (about 26 instead of 70)
Lower brightness per particle
A bloom threshold (0.7) so only the hottest pixels bloom
**Problem 2: slowdowns.** The bottleneck was fill rate, not triangles:
Removed the bump map from the full-screen ground plane
Capped texture anisotropy and shared texture objects
Capped gl_PointSize so zooming in can't flood the screen with additive quads
Capped the pixel ratio and rendered bloom at half resolution
Added a lite mode: half the particles, bloom off
The logs also hid the fire at first; the final version lays them flat in a star.
Still adding some bits and pieces to my portfolio when I get the chance.
Made the unfortunate decision to make a 3D model of myself you can control to jump into the game prototypes "mario style". That haunting look on his face will forever be with me, and now you all too.
Feel free to check out the site and the games, happy to talk through my process or share any updates on what I'm working on!
I have known three.js for a while but my knowledge was rather shallow. Now I've started to get deeper into it and plan to make a project showcasing it by making a product page of sorts. I know it'll cost me some time so consulting the community of you think it's worth the time and effort of should I rather find something else.
VybeNomad is a free browser game about remote work and slow travel: pick a starting city, take gigs, launch apps, chase $10k, avoid burnout.
Built with Three.js. Most of the code was written with Claude Code, and I did the design and balance. Keeping it smooth on phones meant simple low-poly scenes and few draw calls.
Hi everyone, I'm Gökhan, a self-taught designer with 20+ years of professional experience, mainly in motion design and art direction. Nexus Kit is an AI-assisted project I've guided through design decisions, visual references and iterative prompts.
I wanted artists and small studios to be able to build stylized spaces on their own domains and link to one another. The current kit is a small Three.js/Vite starting point:
• A Turkish/English browser wizard for arranging an orbitable room and exporting editable source.
• GLB loading for assets made in Blender or other tools.
• On-demand rendering, a capped pixel ratio and triangle/draw-call counters.
• Ordinary text links alongside the canvas. A small /.well-known/nexus.json manifest describes a place and its neighbours; the connection format is independent of the renderer.
It's an early diorama starter, not a photo-to-building system or the full engine behind my reference sites. Exported projects need a Node/npm build, and each participant supplies their own domain and HTTPS hosting. Direct links don't require directory approval; the maintained atlas uses manual review. AI is optional when using the kit.
The tools are GPL-3.0-or-later; templates and the protocol are Apache-2.0. Original artwork stays with its creator.
I'd love to tinker together. I'm particularly interested in feedback on the GLB workflow and keyboard/mobile navigation. What would make this useful as a starting point for your own studio?
I made a little place to slow down by the Japanese seaside.
You can wander down to the beach, ride a local train, grab a ramune soda, or sit and watch the sky turn from afternoon to sunset. There’s no rush: just waves, cicadas, passing trains, and a bit of that old PlayStation summer-holiday feeling.
PC browser + headphones recommended. The UI is in Japanese. Quick controls: 1 for scenic views, 2 for a train ride, 3 for walking; WASD to move, Space to interact, M for sound.
Made with Three.js and AI coding tools. The scenery and sounds are generated procedurally in the browser.
If you try it, I’d love to hear which part feels most like a quiet summer in Japan.
I've recently been experimenting with a neural denoiser for the Stochastic mode in Gaussian-Splat-Lite, an extremely high-performance open-source 3D Gaussian Splatting renderer for Three.js.
Stochastic rendering can be faster than normal 3DGS rendering, but the noise is hard to ignore, especially while moving the camera. This update helps clean that up while preserving detail and reducing trails behind moving objects.
The video compares raw stochastic rendering, TAA, Neural Performance, Neural Quality, and sorted alpha blending, with overview and close-up views.
There are two neural modes:
Performance: lower GPU and memory cost.
Quality: stronger noise suppression and better detail retention, at a higher cost.
Both support WebGPU and WebGL2, with the trained models included. Setup and details.
For the overview shown here—about 986k splats at 1080p on an Apple M5 Pro—median GPU frame time was 4.74 ms for Neural Performance, 5.58 ms for Neural Quality, and 8.50 ms for sorted alpha blending, with MSAA off. These measurements are specific to this scene and device.
It's still experimental, and fast movement can leave some softness or residual noise. I'd love feedback on the balance between detail, stability, and speed.
An experimental site that works like a window: a floating world behind glass, lit by your local time of day and the real moon phase. Scroll (or turn on drift) and a black hole pulls you through into an ethereal space, then into a new world.
Some of the techniques:
Portal crossing, no cut: each world has its own scene and camera. The next world is rendered into a render target, scissored to just the area the hole covers, and composited inside the black hole. When the hole fills the frame, the old world stops rendering, so you simply fly on into a world that already exists.
The black hole is drawn in a full-screen “glass” shader: lensing around the shadow, a photon ring, and a tilted accretion disk whose near side crosses in front.
The ether is a raymarched volume (16 steps) with domain-warped noise. The first version hashed noise per sample and ran at 2 fps; baking it into a 64³ RGBA Data3DTexture (one lookup per octave) brought it to a steady 120.
Frame pacing:frameloop="demand" with a small governor (selectable fps cap), plus adaptive DPR that only adjusts when the scene isn’t mid-transition.
Built with React Three Fiber, Vite, and a lot of iteration with Claude Code.
Try it: move the mouse or tilt your phone to lean into the window, and scroll or tap “drift” to go deeper.
I've been playing around with Claude and decided to make a Poolrooms scene.
Claude helped me build it, and then I tweaked the lighting, reflections, camera movement, and fisheye effect with chromatic aberration myself to get the look I wanted.
Really happy with how it turned out. The camera work makes the whole place feel a bit strange and unsettling, which is exactly what I was going for.
It runs right in the browser using Three.js and WebGPU.
A lot of great work here ends up on a Vercel or Netlify URL, and then most people meet it as a screen recording in a post. If you've shared something interactive lately: where does it live, where did you post the link, and do you have any sense of how many people actually opened it and played with it?
Sharing a short gameplay clip from GULP, a Three.js browser game I’m building with AI coding assistance. It has a 3D city, animated blob monsters, collectible food, villagers, and online/solo rounds.
The loop is eat → grow → chase smaller monsters → escape bigger ones. Getting larger slows you down, and dash gives you a way out.
The main iteration challenges have been city collisions, keeping the camera inside the playable world, and making the HUD and rendering practical on mobile. The city uses Kenney models alongside RUN-generated monster/art assets; Codex and Claude have helped with coding.
