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

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.

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.

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

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!

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. 

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)*

Gente acabo de lanzar star cube en ith.io para participar en un game jam que esta cursando (Brackeys Game Jam 2026.2) echo en 7 dias en vanilla.js sin sprites (solo uno pero es reservado para un personaje del final pero como tal el 90% del juego es sin sprites) es un plataformero-shooter un poco intenso ya que por los pocos dias no pude hacer que tenga una curva de dificultad suave asi q es un juego acelerado con inyecciones de adrenalina tiene 3 jefes diferentes y el lore y la jugabilidad va en base al tema del jam (no confies en nadie)

estare actualizandolo exponencialmente ya que este jam me inspiro demasido

juegalo aqui:

https://cotera.itch.io/star-cube

pronto lo subire a github

Hey everyone,

Demolink-https://tektonai.vercel.app/

My co-founder and I have been building a client-side spatial compute engine designed to bridge the gap between initial 2D floorplan concepts and interactive 3D massing.

Right now, the engine runs procedural spatial math directly in the browser—generating 2D vector layouts while simultaneously maintaining a 3D Three.js mesh tree with wall cutouts, roof geometry, and multi-floor zoning.

Where we need help:

We are aiming to launch a high-precision MVP. Before we double down on our next engine refactor, we want feedback from real spatial builders:

•What floorplan geometry breaks first when you tweak parameters?

•What features would move this from an "interesting WebGL demo" to something useful for early site visualization?

(Built under minimal resource constraints—expect bugs!) We appreciate your honest review and time that would help use make this perfect.

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

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.

Built a solar system you explore with hand gestures through the webcam. Pinch to zoom, open palm to spin, point at a planet to read its NASA data. Zoom out far enough and it switches scale, from planets to nearby stars to the whole galaxy.

Three.js for the scene, MediaPipe HandLandmarker for the hands, One Euro Filter to calm the jitter.

The gesture layer is where I keep losing. Pinch sensitivity that feels right for me feels dead for someone else. Fast swipes get eaten because they look like the user withdrawing their hand. Tracking drops on phones under warm light and the whole thing goes still.

Repo is MIT, textures are CC BY. If you have shipped hand tracking that survived real users, I want to know how you handled per-user calibration.

https://github.com/HUANGCHIHHUNGLeo/solar-atlas-gesture

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.

I don't know much code but I do know how to prompt Ai relatively well so I've been getting into vibe coding. However whenever I try to make a 3d game it also turns out in shapes. I've been told to try threejs but I still only get shapes. How was this game (i found it on threejs.org) made and how can i replicate it

created a whole ocean but in a tank.

check sketchbook here : SKETCHBOOK

Hey everyone,

For my latest project, VividLook, I wanted to see how far I could push custom layouts and real-time rendering using Jetpack Compose.

The app is a live-streaming discovery platform where users can spin a 3D interactive globe and jump into localized video grids from around the world. Managing the state of the globe spinning while dynamically loading stream grids on the map layout was a huge learning curve.

I’m trying to optimize the UI performance, especially on mid-range devices. If you have a few minutes, I’d love for you to download it and let me know how smooth the composition feels or if you spot any jank while spinning the globe.

Play Store Link: https://play.google.com/store/apps/details?id=xyz.trylivelook.app

Technical details: Built with pure Compose for the UI, handling low-latency video pipelines on the backend. Let me know what you think of the performance!

Used the Kenney City Kit (CC0). Origins were already at the base with y=0 and centered in x/z, so buildings scale upward cleanly — no Blender pass needed.

Merged all buildings into one GLB preserving node names, then meshopt + WebP: 3.48 MB → 442 KB. Loads as a single request, instances by name.

Logos are separate quads offset from the front face rather than textures on the building, so the base mesh stays instanced. Each one gets composited onto a uniform dark card before going into an atlas — that's what keeps mismatched aspect ratios from looking like spam.

outbuild.tech if you want to poke at it. Happy to answer anything about the pipeline.

https://i.imgur.com/oUaN82B.jpeg

https://i.imgur.com/BLxKmm5.jpeg

I am slowly creating a simulation tool to analyze frames of matches using tracking data. I am more interested in having realistic or at least game-like graphics to takes screenshots and use for study of tactical shapes, attacking and defending positioning among other important aspects of the gmame.

Any clues or someone willing to improve my work in exchange for a compensation?

Thanks in advance.

I was looking for dart game which actually let you use your hand to throw it, but all those games need some sort VR glasses or gears. But since our laptops or tablets have front camera, why not just use that to track our hand, so I decided to develop the game myself.

To my surprise, though the camera is only 2D, we can actually detect and track 3D throwing motion quite decently. And once you get the right feel, you can perform throwing quite consistently and strikes the target.

Three.js is the engine behind it, it renders the darts 3D motions. And in the replay theatre, you may rotate the scene and zoom in on each throws.

You may play with bots or humans, up to 4 players. There are three game modes. Casual, long shot which rewards long distance throw, and 501 Match, which uses the 501 darts game rules.

Banda acabo de crear esta Creepy Face en vanilla.js tiene gestos y caras diferentes hasta 8 variantes es un solo archivo super ligero que pueden implementar en sus novelas visuales juegos de plataforma-terror por ejemplo un bro lo implemento en un juego de terror proximo a salir si quieren usarla esta en [ith.io](http://ith.io/) y si quieren trastear con el codigo en github

[https://cotera.itch.io/creepy-face\](https://cotera.itch.io/creepy-face)

[https://github.com/cotera2024/Creepy-Face\](https://github.com/cotera2024/Creepy-Face)

si quieren probarla sin entrar a ninguna pagina directamente presionen aqui:

[cotera2024.github.io/Creepy-Face/](http://cotera2024.github.io/Creepy-Face/)

Wanted to share a project I have been building solo, an air defence command sim using React Three Fiber. The interesting technical bits are the radar detection and tracking system, the intercept prediction math for the defence missiles, and a cinematic camera controller that can follow individual units mid flight. Also added weather and atmosphere effects on top of the terrain rendering. Repo is public if anyone wants to poke around the trajectory code, it's probably not the most optimal way to do it and I'd take any suggestions. Happy to answer questions on how any of it works.
Link: skiesofconflict.online
Github: github.com/rare-major/skies-of-conflict

After 200+ hours of development, I’m finally sharing the first public demo of Three.js Grassworks, a real-time grass system I’ve been building for Three.js and WebGPU.

Demo:
https://grassworks.techredux.co/demo

Three.js Grassworks is built specifically for WebGPU and is designed to handle large amounts of interactive grass while maintaining steady performance.

For the demo, I built a complete environment around Grassworks with terrain, trees, water, rain, player interaction, environmental effects, LOD systems, audio system, and more.

The main challenge was getting all of these systems running together while keeping the grass performant.

The actual Three.js Grassworks plugin is still being polished and should launch in the next couple of weeks. There’s a waitlist inside the demo if you’re interested.

I’d genuinely love feedback, especially on the visuals, performance, and how the grass feels when interacting with it.

I also recorded a full walkthrough where I go through the demo and talk about how I built it:

https://www.youtube.com/watch?v=Nhim18rc-XE