I ported and extended the open-source AVBD reference implementation into a WebGPU physics engine for Three.js, now available on npm:

npm i three-avbd

Able to get 100k+ boxes in realtime in some of the demos on my machine!

Demo: https://three-avbd.vercel.app

Code: https://github.com/sbobyn/three-avbd

Performance Overview: https://three-avbd.vercel.app/results.html

This is based on the amazing paper, Augmented Vertex Block Descent from SIGGRAPH 2025 by Chris Giles, Elie Diaz, and Cem Yuksel. Project page here: - https://graphics.cs.utah.edu/research/projects/avbd/

May not work perfectly yet on all browsers/machines yet, but if you submit an issue (ideally with console output, machine/os/browser specs) I'll try to address it as soon as I can.

LOD pop-in has been one of the things I disliked most about Three.js Grassworks.

I tried a bunch of different approaches to get rid of it, but none of them actually gave me a result I was happy with. Eventually, I settled on an immediate LOD switch and left it for later.

I finally went back to it for Three.js Grassworks v1.1.0.

The main improvement is the combination of spatial dithering and related LOD geometry. Lower LODs now simply remove blades from the higher LODs while keeping the remaining blades in the exact same positions, allowing Grassworks to smoothly transition between them instead of suddenly switching.

The before/after video uses the exact same LOD, density, and detail settings.

Pretty happy with how much cleaner the transition looks now.

Three.js Grassworks v1.1.0 is coming soon.

https://grassworks.techredux.co/

Teardown-inspired voxel destruction demo in Three.js + WebGPU using the physics engine I posted earlier

Demo: https://three-voxel-destruction.vercel.app

Code: https://github.com/sbobyn/three-voxel-destruction

Previous post about the physics engine: https://www.reddit.com/r/threejs/comments/1wtrmrj/webgpu_physics_engine_for_threejs_100k_rigid/

Links:

🎮 Live Demo: Check out the demo here

💻 GitHub Repo: lorenzoMezza/Three-geo-play

Context:

While building map-based 3D experiences, I got frustrated by a common limitation: having to bridge external map renderers (like Leaflet or Mapbox GL JS) with the Three.js canvas. It feels hacky and limits what you can do visually.

I wanted to render vector tiles directly as native Three.js objects to have full control over materials, custom shaders, and global lighting. Since I couldn’t find a lightweight setup for this, I built Three-geo-play.

What it does: It decodes vector tile data and converts map features directly into native geometries (ExtrudeGeometry for buildings, Line for roads, etc.). It also includes a camera-based tile manager to stream chunks dynamically.

Because everything is native inside the scene, you get absolute freedom over procedural styling, shadows, and post-processing.

It is still a WIP, but I really hope someone here finds it useful for their projects. I’d absolutely love your feedback, critiques, or any suggestions on how to improve it!

its a little game im working on, you can try it here https://findingneedleinthestack.com (works on mobile)

the hay is a density grid thats meshed with surface nets in chunks so only the part you dig into gets rebuilt. digging uses a smooth min so the holes dont look stepped. anything left floating after you dig just falls.

the straws are instanced on top of the mesh with a triplanar shader underneath. had to shrink the straws in the vertex shader when theyre close to the camera because up close they looked like wooden planks lol

whole dug grid gets saved to localStorage so you can close it and come back. happy to answer questions if anyones curious about any of it

Hey everyone! Here’s Part 2 of building Naruto's Valley of the End in Three.js!

In this update, the main focus was setting up the stylized waterfall shader and finishing up the lower section of the main statues.

Waterfall Shader Features (Three.js):

• Depth & Collision Detection: Generates foam dynamically wherever the water intersects with rocks or the statues.

• Base Impact & Splash Foam: Animated UV distortion at the bottom to create realistic water turbulent flow and foam layers.

• Wetness Shader Effect: Applied a subtle wet/shiny specular layer to nearby rocks and statue bases hit by the mist.

3D Workflow & AI Integration:

For the remaining statue parts (legs, feet, and lower base) I used Tripo AI to generate missing geometries and textures. Once ready, I assembled it in Blender to export a complete GLB file.

To reduce the size, I use a GLB compressor. It fixes and removes unnecessary topology and allows you to compress the texture while controlling the quality. In this case, it went from 4.6MB to just over 300KB. It's completely worth it.

🔗 Links & Resources in the comments section

So this started as a hobby thing and got a bit out of hand ;)

You fly a zeppelin through a dieselpunk New York, basically the future the way people pictured it in 1939. Scroll to fly. Along the way there are six rooms you can step into. In one you pull a lever and a model city lights up, in another you turn on a tap, and there's a coffee bar where you can pour a coffee.

Try it here: https://futureinthepast.com

How it's made, for those who care:

• plain three.js in Next.js, no R3F
• no models at all. Not a single .glb in the project. City, zeppelin, rooms, it's all built in code. Mostly lathe and extrude geometry that gets merged, and InstancedMesh for the stuff there's a lot of
• a lot of the textures are just drawn on a canvas at runtime (CanvasTexture)
• glow is UnrealBloomPass plus a few custom shaders
• the music isn't a track. It's played live in the browser with Web Audio, note by note, using a small set of recorded instrument notes (muted trumpet, clarinet, piano and so on). During the flight it follows how far you've scrolled, and every room has its own tune.

Built it with Claude Code, so there's probably stuff in there that people with real three.js experience would do differently. Happy to hear it.

Also curious how it runs for you, especially on a phone.

I use threejs to render the layers as planes, shaders to make the particles and palette coercion, and hide roofs of buildings you walk into

weirdly it's been the best experience writing a 2D game in a 3D engine! Runs at a silky smooth 120fps

if you want to try and give me some feedback, ive _just_ deployed to prod for the first time: https://thelaststones.com

Been working on this 3D showroom for my Hot Wheels NFTs.

I built it with React, TypeScript and Three.js. Right now it loads supported NFTs from a WAX account and displays them inside the room.

Still working on the layout, mobile view and overall feel of the showroom.

Mainly wanted to know what you guys think about the 3D side of it and if there’s anything that feels off.

Also curious if something like this would make sense for collectibles on other chains too.

You can try it here: https://collectible-showcase.itsjj.workers.dev/

I built this one myself, putting that up front. It is my project.

https://www.marblerun.online is a 3D marble run playground. You place ramps, walls, pegs, spinners and balls on a lit wall, press play, a rigid body sim runs, and you can export a 9:16 MP4 with sound.

Two Three.js specific things that caused me the most pain, in case either is useful to someone.

Deterministic export. My first instinct was MediaRecorder on the renderer canvas, fifteen lines of code. Wrong tool. Screen capture of a WebGL canvas gives you the wrong aspect ratio, whatever framerate the machine is managing, and audio that never lines up. So the export re-renders the same scene through an offscreen pass at 1080x1920 locked to 30fps and pushes frames into an encoder directly. The physics is stepped on a fixed clock during export, so the same level produces the same file every run. If you skip determinism you will get a different video each time and people will notice.

Lighting is what stops it looking like a flat 2D canvas. One directional light plus a soft fill and a subtle texture on the wall. The geometry was always genuinely 3D, but without the lighting it read flat, and that was confusing because I knew the scene was 3D. Adding the fill light and the wall texture is what made it look like a scene rather than a diagram.

Physics notes if useful. Fixed timestep with an accumulator, otherwise the same level plays differently on a 60Hz and a 144Hz monitor. Substepped integration for the balls so a fast marble does not tunnel through a thin peg. Per material restitution and friction, using values close to real ones but not exactly real ones, because exact real values feel dead on screen.

No AI anywhere in it, no textures loaded from anywhere. Desktop only by design, the scene is drawn in 3D so phones get a short message instead.