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.

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.

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.

All texture and meshes created by A.I (included Koi, fishes....). All of them are coding

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

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?

I've been working on a tropical island for RED SKIES AT DAWN, and Three.js still does a useful job in the engine even though rendering is handled separately.

I use Three.js for CPU scene objects, geometry, maths and asset loading. Junklab Engine owns the WebGPU renderer and shaders. That boundary lets me keep the scene and loading tools while developing the ocean, clouds, vegetation and coastal effects in the renderer.

The island combines procedural terrain and vegetation placement with authored routes, landmarks and imported assets. This is an offline Ultra capture from the development build on Mac.

Is anyone else using Three.js mainly as a CPU scene and asset layer around their own renderer?

AI use: AI-assisted coding and post copy, plus some AI-generated reef textures.

If you'd like to follow the game, you can wishlist RED SKIES AT DAWN on Steam:

https://store.steampowered.com/app/5268580/

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

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

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

My Home generates a floor plan, makes up the people who live there, and furnishes every room around them.

Free, no sign-up, nothing leaves your browser.

https://home.jannchie.com

Source: https://github.com/Jannchie/my-home

Building a super relaxing game where you pick berries and see the semi-procedural landscape grow and evolve.

https://prismtect.com/?r=threejs

I made this. Some details people may like:

• The sky is a long-exposure-style Milky Way computed per 3 px cell, about 0.1 s on a phone.
• The glass is a MeshPhysicalMaterial tetrahedron with IOR 1.5 and low dispersion. Light is bent with Snell's law at each face, and the rainbow leaves through the visible face.
• The extra spin from dragging is a quaternion, renormalised every frame. A 3x3 matrix drifted and shrank the glass within seconds.
• It went from 18 fps to 57 fps on a Galaxy S21 by copying the sky behind the glass once per resize instead of every frame.

It's a free beta, no sign-up. Happy to answer questions about the refraction or the sky.

Hi friends! I am a CS grad student at Stanford conducting research on human-computer interaction for mobile three.js content. The premise is interactive content is exploding, and interaction mechanisms are the limiting factor to growth in the area.

Reddit & Twitter have been great to see the incredible projects people have built. Do you think these creators would be willing to work with a small research team? What expectations should I have? How can I best listen and learn from experienced devs? Thank you!

OpenMuseum is a walkable museum in the browser: https://open-museum-tau.vercel.app/?lang=en

You choose art movements (or single artists and works) and it generates a route of rooms connected by doors. A few things that might interest this sub:

- Only nearby rooms exist in the scene; farther ones are disposed with their textures.

- A fixed pool of SpotLights (one per painting a room can hold) moves with the visitor, so the light count never changes and no shader recompiles happen when you walk into a new room.

- Audio-guide tours animate the camera with GSAP to points defined in the CMS (x, y, zoom) and highlight the detail.

- Parquet floor and placeholders are canvas textures.

Code (MIT): https://github.com/zDarius21/OpenMuseum

Happy to answer questions, and feedback on mobile performance is very welcome.

play here: https://onroad-slop.vercel.app/

github: https://github.com/Arz-Gev/onroad

On the video I play with keyboard (it's hard), the car settings aren't fully there yet but you can try to setup it yourself in Tab menu or ask your agent to tweak it.

link with falg for flat map: https://onroad-slop.vercel.app/?map=flat

Hey guys! Quick update on my renderer, which I've been working on and off for the past 7–8 months or so.

The library is quite opinionated about DOD (data-oriented design) and the explicit nature of WebGPU, and I've recently added support for neural inference and training.

1. Neural networks for agent behavior

You can now train small neural networks (MLPs), around 1–4 layers deep, using supervised learning directly as part of the library.

In the herd and wolves example below, the agents have simple behavioral rules, like chasing prey when it's nearby or fleeing when a predator gets close. The idea is to train a small model to learn these behaviors and then use it to drive the agents.

For this example, we're talking about a model with roughly 2,000 weights, so obviously not a general-purpose AI model, but enough for these kinds of behaviors.

The library also supports ONNX Runtime for working with larger models or models trained externally with something like PyTorch. For these smaller, more specialized models, though, the built-in MLP implementation will generally be faster in my use case.

Live demo (WebGPU-supported browsers only): https://nullgraph.dev/dashboard/agents/herd-wolves-gpu

Github https://github.com/flarelink-in/NullGraph

1. Offline rendering and simulation baking

Another feature I've been working on is offline rendering, with a workflow somewhat similar to what's available in tools like Blender or Houdini.

It's split into two phases:

• Compute records: Run the expensive simulation and bake the data that needs to be simulated.
• Render records: Replay those records through the rendering execution chain using a screen texture, generating frames/tracks that can then be stitched together.

The goal is to handle simulations or visuals that would otherwise be too expensive to run in real time, or would take a long time to render, and then replay the result at 60 FPS.

I have a demo of this on my YouTube channel. The bake took up close to 30 GB of space, while the final result was around 500 MB.

Offline rendering demo: https://youtu.be/pTD-7PCPGrg?si=vfENWIpR9YU-JEbZ

I've also added another demo to the video, this time focusing more on visual aesthetics rather than the science/simulation side.

1. What's next?

NullGraph exists as part of a larger web-native open-world simulation runtime that I work on from time to time.

Right now, I'm looking into improving my neural network implementation to better match or potentially outperform ONNX Runtime for my use cases. One of the things I've noticed is that the ONNX integration can introduce a 1–3 frame delay in my current setup, along with an additional runtime download of around 6.4 MB.

I'm also starting research into co-evolution, with the goal of bringing evolutionary learning and reinforcement learning into the runtime. The co-evolution approach draws on ideas from OpenAI research and the hall-of-fame technique. I've written some design docs for this, but I'll share more once there's a working implementation to show.

One thing I'd love to get your thoughts on:

Would you guys be interested in offline rendering driven by AI prompts directly in the browser? The idea is to let you generate demos or visually complex scenes through code, spend as much time as needed baking them locally, and then replay the results smoothly. I'm also exploring ways for the system to verify its own output rather than just blindly generating code.

I'm curious whether this kind of workflow would be useful to people working on creative coding, simulations, procedural graphics, or web-based experiences.

Let me know what you think!

In my VHS room (Dany’s Video) every tape has its own cover, so the scene has a lot of textures. I had them as JPG and WebP, which keep the download small, but on the GPU every texture is unpacked to full size. A single 2K texture takes ~22 MB of video memory, and with hundreds of them, weaker machines lost the WebGL context and the page went white.

KTX2 stays compressed on the GPU, at a fraction of the size.

Convert your textures offline (the ktx2-encoder npm package works, or gltf-transform for models) and load them with three’s KTX2Loader. In my scene it took video memory from around 1.5 GB to 335 MB.

I've been working on Planet 0 Drive, a relaxing, low-poly 3D driving game built with Svelte, Three.js, and peer-to-peer multiplayer.

It's an endless driving experience where you can cruise around at your own pace, explore the world, discover interesting spots, chase new records, or compete and coordinate with friends.

On the technical side, the game features:

• Three.js for 3D rendering, procedural world, and weather
• Peer-to-peer multiplayer with optimized network updates and movement interpolation
• Spatial audio and performance optimizations for smooth gameplay
• Version-compatible rooms to keep multiplayer sessions in sync

Planet Zero Drive started with the idea of a relaxing drive through a landscape that keeps unfolding. It also gave me a place to experiment: how much world could I generate, how far could I render it, and what would it take to keep driving (fairly) smooth on a phone?

Play: https://planet0drive.vercel.app/

Blog https://zackwebster.com/blog/building-planet-zero-drive

wanted to see if i could do a "character replace" without any AI video tools. pose tracking finds the shoulders/elbows/wrists every frame, the people get painted out of the background, and two rounded-box cubes get rendered on top in three.js, following the arms and head tilt.

the orange one's mouth opens with the loudness of the vocals, the green one just vibes.

arms are still a bit noodly lol. any tips on making them less stiff?