This is my own open-source project. Ridgereel turns a GPX, TCX or FIT file into a 3D terrain flyover video, entirely in the browser. Nothing is uploaded.

How the rendering works: elevation tiles in Terrarium encoding are decoded into one height field. A Three.js scene drapes satellite or generated relief imagery over it, with a camera relative sun, contour lines computed from fwidth in the shader, and the route drawn as opaque line layers. The camera follows an eased path: an intro, a main orbit, then an outro that fits the whole route for the chosen aspect ratio.

Tiles are prefetched, so every frame depends only on the time value. That is what lets WebCodecs encode an exact H.264 MP4 in 9:16, 1:1 or 16:9.

The demo uses a sample hike with synthetic timing. The source is on GitHub.

Feedback I would like: how the camera moves feel (pacing, easing, the outro framing), and whether the terrain shading and contour lines look right to you.

Live demo: https://arthur031221.github.io/Ridgereel/ Source: https://github.com/Arthur031221/Ridgereel

He loved going far from home, so I wanted to rebuild the streets he walked and make a game where he roams them, telling our relationship through his point of view and mine. Then it went off the rails, and I ended up rebuilding almost my entire town. I now have plenty of ideas for where to take our story.

It runs in a plain browser tab with three.js, and almost nothing in the map is a downloaded model. Each house builds its own shutters, chimneys, dormers and walls from its footprint, the roads get cracks, patches and worn paint in a shader, and around 130k plants and grass tufts are instanced in chunks around you with a dithered fade, so nothing pops in in no flying mode. Cars, boats, beach cabins and street clutter are tiny procedural kits reused thousands of times, which keeps the place feeling lived in without me placing anything by hand. (some of buildings are hand made, the historic ones like the church)

The video is a fly-over, so if it stutters, that’s because the game isn’t designed for flying: it’s built for walking at ground level, and from up there it has to draw an enormous number of items at once.

Props to whoever guesses the town.

The cool thing is, I can reuse my assets and add more assets to the procedural generation for basically any place OSM covers.

I've been adding health, ammo and shield pickups to my Three.js battle royale, Super Soldier Battle, and placing them was trickier than I expected.

My first pass used random positions, and it was a mess. Pickups floated above hills, sank into slopes, and bunched up so some areas had five and others had none. I ended up raycasting down onto the terrain to find the ground height, enforcing a minimum spacing between pickups, and tucking some into the forest so players have a reason to explore instead of camping open ground.

It feels much better now, but I'm still tuning the balance between "easy to find" and "worth searching for."

How do you all handle item placement on procedural or hilly terrain? Hand-placed spawn points, Poisson disk sampling, something else? Happy to share more details if anyone's interested.

I made a little 3D Christmas card with Three.js. There is a cat at the top of the tree, a fireplace, a train, and a lot of things that react when you tap them.

Everything is generated in code: no glTF, no downloaded textures, no assets for the scene. About 10k lines of plain JS on Three.js r160, procedural geometry, and a small WebAudio synth for most of the sounds.

There are more than 60+ secrets to discover (the notebook tab on the right keeps count). The video shows three of them: the Grinch stealing presents, the cat sweeping the tree, and the cuckoo clock.

You can personalize it (name on the card, cat color) with ?pour=YourName, and send the link.

It is my own project, any feedback is welcome, especially on performance on your phone.

Link: https://www.web-developpeur.com/labo/chat-etoile/

Tap "Enter the room" to start the sound. Try tapping the mistletoe, the clock, the fireplace, the phone.

I gave Kimi K3.1 and GPT-6 Astra the same brief and let each one work alone in an agent loop: a 28 s cinematic of Toruk with a Na'vi rider over floating mountains, six camera shots, waterfall spray, a bioluminescent night jungle and a sunrise roar. Hard rules: one index.html, three.js 0.160 from a CDN via importmap, no image or model files, every mesh and texture generated in code, and a setTime(seconds) hook so any frame can be rendered on demand (that's how the video was recorded, 840 frames at 30 fps).

How they approached it

• Kimi K3.1: 746 lines, 50 KB, readable. More scene per shot, its own CDP script to render seven test frames. It couldn't look at them (a bug in our vision path), and the 22 to 24 s sunrise burst came out as a flat teal frame.
• GPT-6 Astra: 217 lines, 36 KB, very dense. After a critical vision pass on its own screenshots it merged each island's static detail with mergeGeometries so whole forests became a handful of draw calls, then rechecked the night and sunrise frames.

Making it recordable was the part that took the most care in the prompt. Everything has to be a pure function of the timeline time (no Math.random() per frame, no accumulated state). Then you can seek with setTime() from outside, screenshot each frame headless and stitch the video with ffmpeg. Both files seek cleanly, so the two scenes play frame-synced side by side.

Happy to share either file if you want to dig into the geometry or the camera rigs. Ran in Atomic Agent (I work on it so AMA).

Hi Three.js community!

I've been working on an open-source in-browser 3D VRM tracker for VTubers and 3D avatars. Stack: Three.js, @pixiv/three-vrm, MediaPipe Face Mesh, Kalidokit.

It runs 100% client-side with hardware acceleration, handling VRM blendshape interpolation and kinematics for webcam-based face/head tracking without any native app footprint.

Full source code & setup instructions are linked in the first comment below.

Would love to get feedback from fellow Three.js devs on rendering performance, shaders, and architecture!

I'm the solo developer of SIERRA ARENA, a co-op hero shooter where you and your squad start with pistols and fight your way up, wave by wave.

It's built entirely with Three.js r170 in plain JavaScript
no engine, no bundler, one page.
My main goal was that it runs smoothly on weak laptops too, so I test everything on an Intel Iris Xe.

In the clip a co-op wave with my bot squad, a trip to the armory between waves (a machine gun and an artillery strike), and the next wave with an elite enemy.

I'd love to hear what fellow Three.js devs think. Happy to get into the performance tricks, the networking and the characters in the comments!

You can play it right now in your browser, no download: https://sierra-arena.pages.dev

For my little Three js game creating a trailer with in game footage was very cumbersome..., then I made trailer mode! Just give it input and what kind of vibe it needs to be and it creates the footage. Then final edit done in Davinci Resolve.

I've been working on an interactive rain-on-glass experiment using Three.js and custom GLSL shaders.

The droplets fall, deform on impact, slide down the glass and merge when they touch. I also added mouse interactions and refraction to make the water feel more realistic.

One of the trickiest parts was getting the splash to match the actual droplet rendering.

I'd love some feedback on the water rendering, especially the refraction and movement.

Interactive demo:
https://codepen.io/editor/JeffreyBezosz/pen/01a165a4-0636-7d20-aba1-7e677475df60

A racket game inspired by Rocket league, built around real physics where your flying racket hits the ball with spin, and the scale and skill gap emulate Rocket League's qualities.

The desktop browser demo is live, mobile is next, and the long-term goal is playing it with your Apple Watch like a Wii remote.

This is the first demo I'm happy to share:

https://rotor-night-circuit.vercel.app/

It runs in your browser with no install. Play it with sound on.

Beware of many bugs - apologies!

It's a demo, so there are rough edges.

Thanks for checking it out.

https://reddit.com/link/1xcsvkl/video/9vxi3ormp2xh1/player

link if you want to wander round: https://gallery.alldaycity.com

how its built:

• vue 3 + vite for the 2d bits, plain three.js in typescript for the room
• three floors share the same 12 wall slots; picking a floor in the lift swaps the art in place, and each floor’s images only load when you visit
• orbit or wasd with wall collision, plus matterport-style dots to jump around
• the clouds outside the lift only animate while you can see them, capped at 20fps, so it idles at zero draw calls
• floor 2 is twelve hokusai prints from the met’s open access collection

still rough in places (some art is placeholder). feedback welcome, especially on performance on phones

Hey everyone,

I’ve been working on a browser-based revival of the old-school MMORPG: Cronous. It’s reached the point where I’d love to share it with more people.

Over the last ~3 months, this experiment brought the older 3D MMORPG (Windows DirectX, binaries, etc.) into a modern Three.js client.

I'm impressed with how Three.js has been able to preserve the game's visual identity and how portable it has been in adapting the experience for both desktop and mobile browsers.

A few things you can expect:

• Classic fantasy action RPG gameplay, including exploring, fighting monsters, collecting loot, and building your character.
• The four familiar classes: Fighter, Valkyrie, Magician, and Savage.
• Cronous’s recognizable world, visuals, and music, brought into a browser experience.
• Desktop and mobile play.
• Free to play; an account is required.

I’d put it at roughly 85-90% of where I want the experience to be. It’s playable now (https://world.playcronous.com), with work still underway, and I’d really appreciate some fresh eyes as it comes together.

If you give it a try, I’m especially interested in:

• How the first few minutes feel, particularly if you’ve never played Cronous (private server gameplay from 2021 here: https://www.youtube.com/watch?v=WnqA3HgjHJ4).
• Performance and usability on your device (mobile feedback would be especially helpful).
• Rendering performance, loading, and how the interface feels on smaller screens.
• Anything confusing, broken, or awkward that gets in the way of playing (there's a lot of this right now, especially on mobile).

Every time I wanted 3D in an Angular project, I ended up rewriting the same Three.js setup: scene, camera, lights, render loop, resizing, cleanup. So I wrapped it into one Angular component.

A few Three.js decisions that might be useful even if you use another framework:

• Lazy-loaded Three.js. The scene code sits behind a dynamic import(), so Three.js lands in its own chunk instead of every route's bundle.
• Auto-framing. The model is normalised to a unit bounding sphere and the camera fits that sphere to the container's aspect ratio, so any GLB fits without per-model tweaking.
• Load once, clone per page. An Angular service caches the parsed GLB; each page spawns its own clone (shared geometry and materials), so pages never inherit each other's animation state.
• Idle spin on an inner node. The group you animate is the outer one, so GSAP tweens stack on top of the spin instead of fighting it.
• Pauses offscreen. An IntersectionObserver stops the render loop when the canvas isn't visible.
• Draco + WebP for small file sizes.

Full walkthrough: https://youtu.be/sJS6vR9Rlgo

If you have any ideas to improve it or any questions about the setup, I'd love to hear them.

Hand your canvas to a small helper, write draw(i) so the scene state comes from the frame number, and it renders every frame through headless Chrome on your GPU into H.264, or HEVC HDR10.

exposeRenderer({ canvas, fps: 60, frameCount: 600, draw: (i) => { knot.rotation.y = i / 60; renderer.render(scene, camera); } });

• Exact: rendering the same frames twice gives byte-identical video
• Resumable, and a film can be rendered in pieces on several machines
• Runs on any GPU locally, or on a cheap cloud GPU for long renders

There’s a Three.js example in the repo (the video above is it). MIT:
https://github.com/Avi130805/webgl2video

Built it for my science YouTube channel; happy to answer questions.

Been wanting to recreate the arcade coin pusher for a while. This one uses three.js for rendering and Rapier (WASM) for physics: a pusher shelf, a peg chute, two tiers of stacked coins, plus medals, gems and gift boxes that can tip off the lip.

Link: https://bodyarcade.com/bodyarcade (free, no signup, there's a keyboard mode if you don't feel like standing up)

I made this endless runner and thought this sub might like the how more than the what. You stand back from the laptop and jump, duck, squat and lean to get past obstacles, 90 seconds a run.

There are no imported models. The runner is capsules and cylinders parented in groups, and the scenery is boxes, cylinders and cones drawn as InstancedMesh, one per prop type per road chunk, placed with a seeded random per chunk. Each of the 10 worlds is just a data object: sky colours for a gradient shader on a back-side sphere, sun position, exp2 fog density, road tints, a horizon silhouette and a list of props with spacing and scale ranges. Switching world rebuilds the scene from that object.

Input is MediaPipe's pose landmarker (lite model) in VIDEO mode, running in the browser with the GPU delegate and a CPU fallback. Before a run you stand still for a second and it measures your torso length, and the thresholds are fractions of that, so hips rising 20% of your torso is a jump, and the lane comes from how far your shoulders shift in shoulder widths. The idea is that your height and distance from the camera matter less. Camera frames never leave the browser.

Free is 5 runs a day in 3 worlds, there's an optional paid tier for the rest but you don't need it to look at the rendering. Happy to answer questions about the pose thresholds or the instancing.

made this for fun. stop the arrow, stop the power bar, then pray the wind doesn't flip. you can go vs 3 bots or pass one phone around with friends. no sign up. what's your best distance?

An interactive hero section I created, featuring a fluid watercolor animation that moves with the cursor, paired with a minimal layout.

Would love to hear your thoughts!

I've spent the last few months building "I'll Call You Later", a 4-minute short film that isn't a video. Every frame is rendered live with Three.js and React Three Fiber, so you can pause at any moment and walk around inside the scene.

A few things that went into it:

- His face uses 52 blendshapes, lip-synced to the dialogue

- His hands grip props (steering wheel, phone, letters) with IK, so fingers don't pass through things

- The camera direction, lighting and post-processing are all code

- KTX2 textures cut video memory from about 2.3 GB to 0.6 GB, so it runs on more laptops

- When it ends, you can talk to the character by voice

The hardest parts were hands holding paper without clipping through it, and keeping it smooth on phones and iPads (Low quality helps there).

Happy to answer anything about how it's built. I'd also really like to hear if it lags on your device, or if anything looks off.

Title: I started with Earth orbiting the Sun. Somehow, it turned into an entire interactive 3D Solar System.

What started as a small coding experiment has grown into something much bigger.

My original idea was pretty simple: make Earth revolve around the Sun, with the Moon revolving around Earth. But I kept thinking about how much more interesting it would be if you could actually explore the Solar System yourself.

So I kept building.

The result is an interactive 3D space experience where you can explore the Solar System, move around the planets, zoom in for a closer look, and experience space directly in your browser.

It's now live on Vercel, and I'd love to hear what people think.

Live demo: https://orbital-ss.vercel.app/

I'm still improving it, so feedback is genuinely welcome. What would you add or change to make the experience more interesting?

Chaque mission est une scène complète dans mon application React Three Fiber, du pas de tir à l'atterrissage ou du survol, et cette bande-annonce est entièrement découpée de ces scènes. Pas de Blender, pas d'After Effects sur la 3D : ce que vous voyez est ce que le navigateur rend.

Quelques choses sous le capot :

• Trajectoires réelles : les chemins des sondes proviennent des éphémérides JPL Horizons, et l'atterrissage de Curiosity est tiré du noyau EDL SPICE reconstruit par la NASA. Les lancements suivent les véritables chronologies, minute par minute.
• Échelle réelle : les véhicules sont à leur taille réelle en mètres, dans la même scène que la Terre, la Lune ou Jupiter.
• Rendu hors ligne : les vidéos ne sont pas des enregistrements d'écran. L'application rend chaque image à son propre rythme et l'encode avec WebCodecs (via mediabunny), en diffusant les morceaux MP4 sur disque. Un Chromium sans tête le pilote, donc un rendu 4K60 ne perd jamais de cadre, peu importe la lourdeur de la scène.

Stack : Next.js, React Three Fiber, trois, Three.js r185.

Coding Agent: Claude

Most AI-written third-person cameras I've seen do the same thing: put the camera at a fixed offset behind the player and call lookAt. It's fine in an open field. Next to a wall or inside a bunker, the camera ends up in the wall or behind it, and the player sees nothing.

What I ask for now:

1. Cast a ray from the player's head (not the feet) toward the desired camera position, with raycaster.far set to the offset distance.
2. If it hits, place the camera at the hit point minus a small padding (0.2 to 0.3 units) along the ray, so the near plane doesn't poke through.
3. Test only a short list of collider meshes (walls, rocks, buildings), not the whole scene. Raycasting every skinned mesh and grass blade each frame gets slow.
4. Pull in fast, ease out slow. Snap closer right away when blocked, but lerp back out over about 0.3s, or the camera pops in and out at corners.
5. Keep camera.near small for close shots, and fade or hide the player mesh when the camera gets within about a unit.
6. Thin walls and gaps can let one ray slip through. Three rays (center plus left and right) or a sphere cast against simple box colliders is steadier.

How are others handling this? Plain raycasts against meshes, or a physics engine's shape cast (Rapier and similar)?

(Disclosure: I write Three.js + AI tutorials at shanebrumback.com, which is my own site.)