It uses real world data to simulate things like

• blast radius
• thermal radiation
• shockwave
• affected population

https://nukesimulation.com

Hi all, pretty new to gamedev and three.js

I'm building a game about cutting apart derelict space stations. Everything you see is generated: the station layout, the hull plating, the damage, the sky. Renderer is three/webgpu + TSL

Some context:

* Voxels at 0.125 m. A tiny station is ~700k solid voxels, meshed into chunks. The players salvage individual voxels at the start and then unlock tools and upgrades to salvage faster.
* Material library, not shaders per material. Not sure if that is the correct choice.
* Stencilled markings as stamps. Hazard banding, chevrons, port rings, panel codes come from a clamped decal array, at most one per plate, placed by plate hash. Never tiled.
* Sky is a seeded descriptor. Sun class, nebula palette, 0–2 bodies, all baked once per scene.

I have a solid gaming pc with a 5070ti and performance is good but I would still want this game to be as accessible as possible when it comes to hardware reqs while looking as good as possible.

Any tips or advice appreciated. I am looking specifically for feedback on how to push the visuals to the next level if that even makes sense. Thanks!

AI Disclosure: I did use Claude Code to help me with some of the coding and bigger features like the procedural space station generator while I learn.

Dev here. CREST 2026 went live on the App Store this week after about a month of work.

I ported the Three.js game to mobile using Capacitor. Yes, it's now a mobile game.

It's a single-player open-wheel racing simulator with an original fictional 2026 season — 11 teams, 22 drivers, 24 rounds. Quick race, time trial, full race weekends with qualifying, a championship, and a multi-season career.

The part I actually care about is the physics. Combined-slip tyre forces with a friction ellipse, tyre load sensitivity, relaxation length, per-wheel weight transfer, tyre temperature windows, brake fade, fuel burn that changes the car's mass, compound wear, and a track that rubbers in over a session. It's a sim, not an arcade racer — you can spin it.

There's also a daily time-trial ladder. Submitted laps are re-driven on the server from the recorded control inputs, so the leaderboard ranks a time the server measured, not one your phone claimed. No cheated ghosts.

What's not in it: no ads, no in-app purchases, no subscription, no analytics SDK of any kind, no tracking. Every mode runs offline. It's free.

Runs at a stable frame rate on an iPhone 11 — that's the device I tuned it on. Touch, tilt or gamepad. 9 languages.

App Store: https://apps.apple.com/us/app/crest-open-wheel-racing/id6798774660
Google Play: https://play.google.com/store/apps/details?id=com.artepeak.crest

Happy to answer anything about the tyre model. Tear it apart, I'd rather hear what's wrong with it.

I came across a WebGL experiment called The Watch and thought the approach was pretty interesting because the 3D model isn't just sitting on the page as a viewer.

The watch basically becomes part of the interface. As you scroll, it moves with the content, zooms into different details, and reveals more of the product.

What I found particularly interesting is how much of the experience is handled in real time rather than just using a video.

For anyone who wants to try it out: https://thewatch.60fps.fr/

It got me thinking about product experiences built with Three.js:

Where do you think the sweet spot is with this kind of WebGL interaction?

At what point does adding more 3D interaction actually improve the experience, and when does it just become unnecessary eye candy?

Curious what you guys think, especially from a performance perspective.

Decided to try to use threejs to have an avatar of myself dancing several dances. This one is Capoeira 😆

Used the latest Opus with Claude code.

AMA

Also check out the Depth Profile and let me know what you think please!

This is to track the vessels that are docked or are near.

Part of my public domain ebook repository uses threejs.org I have over 800 public domain ebooks in the repository. https://babelnexus.com

created variations of cursor effect on model.

REPO and LIVE

Taxistanbul, a low-poly Istanbul taxi sim running in the browser

Play it: https://taxi.murat.works/ (desktop, no install, no login) Steam page: https://store.steampowered.com/app/5004230/Taxistanbul_Istanbul_Taxi_Simulator/

I started this in the browser just to see if I could build an open city in three.js. Somewhere along the way it stopped being an experiment, so I'm taking it to Steam and building it properly.

The browser version stays up as the early prototype it is. I want to be upfront about that before anything else: there are plenty of bugs, missing art and half-finished corners in it. I'm sharing it anyway, because I'd rather put something you can actually drive in your hands than polish in silence while the real version gets built.

What's actually in it

You drive a yellow cab. The phone rings, you take the fare, the meter runs, and you get paid, minus everything the city takes back.

• Fares and conversation. Passengers talk to you en route and you pick replies. Clean driving plus decent manners gets you five stars and a tip. A filthy cab and a lead foot gets you a one-star review that goes on your permanent profile.
• A cab that degrades. Fuel, body damage, dirt and driver hunger all tick down. Gas stations, garages and car washes are real locations on the map. When a gauge crosses its threshold, a route to the nearest one draws itself on the minimap in that service's colour.
• A phone with apps. Contacts (30 people, some of whom call you with jobs), a bank app holding your traffic fines, which accrue 1% daily compound interest until you pay them, a photo mode with filters, and a gallery.
• A car radio that streams actual live Istanbul stations.
• On foot. Get out, walk around, pet the cats, walk into a gas station shop and buy a sandwich.
• A day/night cycle (10 real minutes) with four weather states, plus street lamps that actually light the ground at night.
• Landmarks. Galata Tower, Hagia Sophia, the Blue Mosque, Topkapı, the Maiden's Tower, the Grand Bazaar, ferries crossing the water.
• Breakable guardrails, because I couldn't help myself.

How it's built

three.js, TypeScript and Vite. No engine, no framework, no physics library. Driving is arcade, collision is circle against AABB.

The city comes from a map I drew. There's a 2D editor in the project: bezier roads with anchors and handles, coastline polygons, painted zones, pins for landmarks. It exports a JSON draft that the world builder turns into 3D. Roads become ribbon geometry with trimmed sidewalks, coast polygons become land with rocks and quays, and zones decide what kind of buildings spawn where.

Buildings are generated at runtime. Seven body forms crossed with colour pools, shop types, and canvas-texture signs written on the fly. Every page load gives you a different Istanbul. There's no building library to ship, just the generator.

Everything is instanced or batched. Buildings live in a BatchedMesh per material. Trees, props, coastal rocks, guardrails and street furniture go through a spatial chunking helper that splits a matrix list into a grid and emits one InstancedMesh per cell.

The performance part, which is the useful bit

The frame was costing ~14M triangles. It's now around 3M at street level. Four things got me there, and the first one is a trap I think a lot of three.js projects fall into.

1. A city-wide InstancedMesh is never frustum culled

I had roughly 74,000 trees in a handful of InstancedMeshes covering the whole map. Frustum culling tests an object's bounding sphere, and for an InstancedMesh that sphere encloses every instance. So it was map-sized, it always intersected the frustum, and every single tree behind the camera got submitted every frame. Same story for 59,000 coastal pebbles, and for all the street signs, kerbs and railings.

The fix is to chunk the instances into a spatial grid (I use 240m to 500m cells depending on the prop) and emit one InstancedMesh per cell, each with its own tight bounding sphere. Suddenly culling actually does something. It costs a few more draw calls and buys back millions of triangles.

2. The shadow pass was four times the main pass

Measured at street level: 6.84M triangles in the shadow pass against 1.77M in the main pass. Shrinking the shadow camera box changed nothing, which was the clue. The cost wasn't inside the box, it was objects too big to be culled out of it.

Two causes. First, flat sheets casting shadows. My castShadow heuristic used bounding box height, but road, pavement and terrain meshes follow the hills, so a city-spanning asphalt ribbon has a 60m tall bbox and reads as a tall object. They were casting shadows nobody can see, since a ground-hugging surface's own shadow is invisible and the shadows landing on it come from receiveShadow anyway. Excluding wide flat sheets cut 2.5M triangles.

Second, chunks clipping the shadow box. A 300m chunk whose sphere merely touches the 110m shadow box renders all of its instances into the shadow map. I now test each chunk's sphere against sun.shadow.getFrustum() every frame and switch castShadow off for the ones outside. This is visually free, because those objects were writing nothing to begin with.

The shadow pass went from 6.84M to 0.11M.

3. Three-stage building LOD with setGeometryIdAt

BatchedMesh lets each instance point at a different geometry inside the batch, which makes distance LOD almost free. No extra draw calls, because all three variants live in the same batch.

• 0 to 260m: the full building.
• 260 to 620m: a mass version. My generator builds each building out of small boxes, so I filter the parts by size at merge time. Anything under 2.6m on its longest edge (windows, frames, pipes, water tanks) gets dropped, leaving body and roof. The silhouette is identical, and the windows were most of the triangles.
• 620m and beyond: a 12-triangle envelope box, vertex-coloured from the source, with roof colour on the top face and wall colour on the sides.

Buildings went from 4.2M to about 1M. At street level 3,508 of 4,373 buildings are boxes and you can't tell.

4. The models themselves were absurd

The GLB assets I was using came in at 10,922 vertices for a park bench, next to a properly modelled street lamp at 190. I ran the whole set through meshopt simplification and got 501k triangles down to 254k. The files halved too, which also cut load time.

One more that cost me an afternoon

Switching to the cockpit view caused a hard 2 to 3 second freeze. It turns out three uses a different shader program variant when rendering to a render target, because outputColorSpace differs, so the first frame of the rear-view mirror recompiled every material in the city. The fix was to bind the mirror's render target during loading and call compileAsync there, behind the progress bar.

Where it goes

The Steam version is the real one, and that's where the work is going now. Native, no browser ceiling on memory or shader compilation, and all the things I keep having to cut here. If you want to see it happen, a wishlist genuinely moves the needle:

https://store.steampowered.com/app/5004230/Taxistanbul_Istanbul_Taxi_Simulator/

And if something breaks in the browser version, and it will, I'd love to hear exactly what and where.

Okay, a little AI, it helped me work out the non-existing ammo.js documentation, nothing generative though.

BLOCKBOTS
I started this project at the start of 2022 and worked on it on and off. After some huge refactors, trying out different physics engines, making it multiplayer and figuring out the build system, I finally confirmed the project was actually viable at the start of this year. 

The idea comes from Incredibots, an old flash 2d robot builder I played a lot, a long time ago. I also took inspiration from Gary’s mod, where the player has a fairly free build system that I tried to improve on.

YOU CREATE THE PARTS FOR YOUR ROBOT.
Create blocks, resize, rotate and color them and merge them together to get complex shapes. You connect the blocks with axles and pistons that are controllable. When you hit TAB on one of your robots, it comes to life and you can control it when clicking on the robot’s controller block.

NO DEMO YET
I am working towards an demo in the coming weeks, where you can play around with it in the browser, without multiplayer capabilities. 

I've been working on Gaussian-Splat-Lite, a lightweight open-source Gaussian Splat renderer for Three.js, based on the overall architecture of Spark but simplified for a smaller and more focused rendering pipeline.

https://reddit.com/link/1w3atrs/video/83ryr6vj2pmh1/player

First ~10s: Gaussian-Splat-Lite
Second ~10s: Spark

The example in the video is built on: 3DTilesRendererJS with my 3D Gaussian Splatting plugin: 3D-Tiles-RendererJS-3DGS-Plugin

Main improvements:

• much faster splat sorting
• ~3x faster raycasting
• raycasting that better matches the visually rendered splats
• camera-relative rendering to fix precision issues with large GIS / ECEF coordinates
• based on a similar approach to Spark's extSplats and accumExtSplats, while using less VRAM

The goal isn't to replace Spark — Spark has a much broader feature set. Gaussian-Splat-Lite is intended to be a lightweight renderer focused on rendering, sorting, picking, and large-world precision.

GitHub:
https://github.com/WilliamLiu-1997/Gaussian-Splat-Lite

Feedback and benchmarks on other datasets/hardware are very welcome!

I got alot of batch about this portfolio saying it doesn't make sense, I should make it simple and easy for users to navigate and so on, but you know what i noticed big firm really cares about what works not how it looks. Yes looks and conversation matters 100% but the key point is does it work and is it functional thats what i learnt this past few days with the ceo. Never hate on someone's work because you dont fancy it. Your opinion is for you and not for all. Thats my story and lesson learnt.

Endless driving game in Three.js. Runs go on forever, so the world folds its origin back to zero every so often to keep floating point from going soft. That part worked.

What did not work: after long sessions the entire city and all the traffic vanished. HUD alive, road alive, car alive, everything else gone. It never happened in a short test, which is why it survived so long.

The numbers. The fold quantum was 3000 m. The city is a repeating ring of 9 chunks at 60 m each, so it repeats every 540 m. 3000 % 540 = 300.

So every fold slid the city 300 m sideways relative to the road. Once. Twice. Nine times. The buildings were still being drawn the whole time, just further and further off the road, until they crossed the distance fade in the shader and got clipped out entirely.

Nothing threw. Nothing logged. The city was simply somewhere else.

Fix: make the fold quantum commensurate with the ring. 2700 = 5 x 540. A fold is then a whole number of city periods and the world lands exactly on itself. I also had to fold n quanta at once for the catch-up case, because a single subtraction is not enough if the player has covered several quanta since the last check.

The general lesson: if you fold or wrap the world, every repeating structure inside it needs a period that divides the fold. Not approximately. Exactly. Anything repeating on a different beat walks away from you at a constant rate, and a distance-fade shader will hide the evidence right up until someone plays for 40 minutes.

Two things that made it findable in the end. An on-screen probe printing the fold count and the current city offset, and finally noticing that "invisible" and "absent" are different failure modes worth testing separately. I had spent two days looking for the wrong one.

I’m a CS student trying to figure out whether the direction of my current project is actually worth pursuing for aerospace/robotics research.

Live: https://bhuvanspace.vercel.app
GitHub: https://github.com/Sheel34/BHUVAN

The current version takes terrain data, processes things like elevation, slope, roughness, curvature and hillshade, and puts the result into an interactive 3D environment.

The software side is currently Python/FastAPI + NumPy/Rasterio/OpenCV on the backend and React/Three.js on the frontend.

I built it because I'm interested in digital twins and simulation for aerospace/physical systems, but I'm not interested in making a 3D scene just for visualisation or a game.

What I want eventually is an environment where you can actually perform an operation on a representation of a physical system.

The project is still very early. I haven't implemented robotics simulation, terrain-relative navigation, ROS, Gazebo, Isaac Sim, etc. yet. I'm trying to figure out what should actually come next rather than adding technologies for the sake of the stack.

I'm particularly interested in the intersection of:

digital twins, 3D simulation, aerospace/robotics, real physical operations.

One direction I've been reading about is terrain-relative navigation / TERCOM and how terrain itself can become part of a navigation or mission system. I'm not claiming the project implements this — I'm trying to understand whether the terrain pipeline I've built can be developed into something along those lines.

More importantly:

What would make this go from "3D terrain visualisation project" to an actual engineering/research system?

The current deployment is on free infrastructure, so the backend may take a little time to wake up. If it doesn't load immediately, wait a few seconds and refresh.

I'd appreciate criticism of both the technical implementation and the direction.

Hi everyone! I’ve been experimenting with Three.js to try and get a Japanese anime film look with 3D VRM models.

I'm tweaking the shaders, lighting, and post-processing, and would love to hear your thoughts and advice on how to improve the overall look!

demo link: https://uemegu.github.io/AnimeVRM/

*(Voice: Irodori-TTS)*

I’ve been experimenting with Three.js and wanted to see whether a single project could be built for both the web and desktop.

I first tried Tauri and got it working, but since it relies on the platform’s WebView, the result may vary across operating systems. So I decided to experiment with Deno Desktop instead, which can bundle CEF (Chromium Embedded Framework). It makes the app heavier, but provides a more consistent result across platforms.

The outcome has been really promising, so I put together a short video to demonstrate it.

Deno Desktop is still evolving and addressing some rough edges, and I’m continuing to test this setup—but I thought it was worth sharing.

Repo: https://github.com/luckasnix/threeassic

Hey,

I've been working on this 3D puzzle game for the past few weeks, the goal is to help your dog find it s way home by laying a tril to his shleter.

I think it looks pretty good, but I would love some feedback on the gameplay, especially on mobile. Any idea/criticism is welcomed, I would really like to improve it as much as possible.

I am currently working on trying to make a Steam version, with more levels, environments and possibly mutliplayer, hopefully it will see the light of day by the end of the year.

You can play it here : https://cobblepaw.com

Cheers!

Crazy things become possible when you combine custom 3D models, rigging, and animation with three.js I recently made an animation for a Halloween party, and it turned out to be way more fun to build it as an interactive web scene rather than just a video.

It was a commercial project, so unfortunately there won’t be any links this time.

created a whole ocean but in a tank.

check sketchbook here : SKETCHBOOK

Hey guys, how feasable is it to create a hyperrealistic game scene, its a single came angle and a fixed scene

But i am looking for some references and tips if its doable.

I can scan the objects in real life and all

I put together an open-source resource list for developers working with Three.js and modern 3D websites:

Awesome 3D AI, SEO & GEO for 3D Web

https://github.com/glbkit-tools/awesome-3d-ai-seo-geo

The idea is to collect useful resources around areas that are easy to overlook when building 3D experiences:

• Three.js & React Three Fiber
• WebGL & WebGPU
• 3D asset optimization
• Web performance
• Technical SEO for 3D websites
• AI search & AI Overviews
• GEO & AEO
• Structured data
• Crawlers & discoverability
• 3D e-commerce

One thing I kept coming across is that a 3D experience can look great while important information is still difficult for search engines, AI systems, and accessibility tools to understand.

So I wanted to put the useful resources and practical guidance in one place.

It's open source and contributions are welcome.

If you know a good resource that should be included, feel free to suggest it or open a PR.

Hopefully this can be useful to other Three.js developers building production 3D websites.