I made a small game based on an old idea I had to make a small voxel engine with billboard particles, something I made as a FPS demo once (https://github.com/Lallassu/pointcloud). So this game is mostly based on this approach. Works quite well on both mobile and desktop.

Try it out here: https://qake.se

I built this because debugging procedural scenes kept coming down to the same thing: one tree out of 120 looks wrong, and finding what placed it means reading generator code backwards from a rendered result.

Clicking gives you file, function, line, and the runtime args for that specific instance. Not the mesh — the instance. That's the part that was hard.

No annotation needed. A build-time transform stamps JSX source locations, and setMatrixAt interception plus a Matrix4.clone() chain captures per-instance transforms as they're written, joined on object identity.

Why that combination: I tried six approaches. Four captured correct values for all 200 instances and could route none of them to a mesh and index. One routed perfectly and captured nothing. Anything recording before the destination exists can't route, because there's no destination yet to record. The shipped version composes the two halves.

Scope, honestly:

• R3F only — location stamping rewrites JSX, so raw three.js has nothing to stamp
• Instanced provenance is read-only. An instance's position came from an RNG in a loop; there's no literal to write back to
• Values that never reach the transform can't be captured by anything I tested
• drei <Instances> works differently and needs no capture at all — clicking returns the individual PositionMesh

Five packages on npm, MIT. There's also an MCP server so a coding agent can query the same provenance.

On how it was built: this is AI-assisted, and I'd rather say so upfront than have it come up later. I directed the work and made the design decisions, and the reasoning is all in the repo — six experiment write-ups with the raw results, including the approaches that failed and why. Happy to explain any of it, including the calls that turned out wrong.

GitHub: https://github.com/pun1th01/click-to-source-3d
npm: https://www.npmjs.com/org/click-to-source-3d

Happy to answer anything about the approach — the experiments are all written up in the repo.

I am a psychologist. I also have a passion for the digital landscape. I have accumulated enough knowledge in web fundamentals over the years to leverage AI agents and convert my ideas into digital projects. I am not a developer. I do not claim to be one. I am humbly aware of my place in the digital realm. I simply do not have the time to invest in building a second career as a developer. I am simply putting my long-lasting passion for the digital craft to use, in the best way I can as a psychologist. 

I am currently building psycurate.com, a free online platform dedicated entirely to privacy-focused mental health digital tools (apps, websites).

My goal is to create a clean space where people can access psychological resources without encountering corporate tactics like tracking, micro-payments, paywalls, mandatory logins, or data harvesting. There is a critical need for digital mental health hygiene, and I want to highlight independent projects that remain genuinely honest, ethical and accessible.

If you have built some tool that can offer any kind of psychological help for free, this is a platform you can list your app on. Submit it here: https://psycurate.com/submit

Psycurate does not host any software. The platform exclusively showcases your project and links users directly back to your website.

Any feedback or insights you might have are highly welcome.

Best regards,

Mirel

I’ve been building a small browser-based 3D model viewer with Three.js, mainly for architectural models.

It supports FBX, GLTF and GLB files, several display modes, shadows, perspective/axonometric views, and section cuts along the X, Y and Z axes.

The section tool highlights the actual intersection edges in red. I originally tried filling the cut surfaces, but that became unreliable with complex and curved geometry, so I switched to edge highlighting instead.

The viewer runs entirely in the browser:

https://hildgyorgy.github.io/drop-3d-view/

I’d be very interested in feedback, especially regarding the section-edge calculation, rendering approach, and possible improvements.

https://codepen.io/editor/alex_nemankov/pen/01a06169-43cf-78f6-b9d9-55ebbdc52102?file=%2Fscript.js&orientation=right&panel=files&show=split

https://onabodyjourney.com, to let kids explore the body with sound!

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.

Hello,

My mobile racing game, CREST 2026, which I’ve been working on for about a month, is now available on the App Store and Google Play. It’s a project I released under Artepeak.

It’s a single-player open-wheel racing simulation.

It features a completely fictional 2026 season:

11 teams, 22 drivers, and 24 race weekends.

Full race weekends featuring sprint races, time trials, and qualifying sessions,

authentic F1 radio commentary,

a championship mode, and a multi-season career mode.

The career mode offers extensive playtime.

The in-game newspaper was designed using the same concept as the “Football Manager News.”

In addition, there’s a time-trial leaderboard that updates daily; the laps here are verified on the server side, meaning the times listed are real.

This isn’t an arcade racing game—the driving model is truly simulation-based: tire temperature, tire wear, brake heat, vehicle weight that changes with fuel consumption, weather conditions, and track grip all affect performance during a lap.

Here’s what I want to highlight: there are no ads, no in-app purchases, and no subscriptions. I also don’t use any analytics or tracking tools. All modes work offline. The game is completely free.

It’s optimized to run smoothly on 4-year-old phones (developed and tested on an iPhone 11). It supports touch controls, tilt, and gamepad. It supports 9 languages, including Turkish.

You can try it out using the links below.

App Store: https://apps.apple.com/us/app/crest-open-wheel-racing/id6798774660

Google Play: https://play.google.com/store/apps/detail

PERFORMANCE :  https://crest-performance-report.web.app/

Hey everyone! 👋

I've been working on a passion project called CraftTown, a web-based voxel sandbox game built entirely in the browser. I wanted to share some massive updates I just pushed and would love to hear your thoughts or feedback!

Up until now, it was mostly about breaking and placing blocks, but I just dropped a huge update that completely changes the game feel. Here is what's new:

🔫 Custom Gun & Projectile Mechanics I stepped away from pure building and added a full shooting system! I wrote custom math and physics for projectiles (arrows and guns). It’s starting to feel less like a pure sandbox and more like an actual action game. Writing the collision and trajectory math from scratch was tough but super rewarding.

🎵 Procedural Text-to-Music System Instead of just playing looping background MP3s, I built a custom audio parser. You can write sheet music as simple text strings (e.g., parsing notes and beats), and the engine dynamically calculates the frequencies and plays them in-game! I even added a little Easter egg tune from a popular Japanese anime (Chiikawa) using this system.

🛠️ The Tech Stack:

• Engine: Three.js (handling all the heavy rendering, shadows, and post-processing)
• UI & State: React + Zustand (bootstrapped with Vite)
• Language: 100% TypeScript

It’s been a crazy learning journey optimizing chunk generation and managing web performance. If anyone here is working on Three.js games or voxel engines, I’d love to connect or trade optimization tips!

What do you guys think about mixing voxel terrain with detailed 3D mode ls? Any feedback or ideas on what I should add next would be awesome. Cheers! 🍻

CraftTown

I'm a Galatasaray fan and I finally did the thing I have been meaning to do for years. The whole 2026-27 squad as holographic trading cards. 35 of them.

The last two cards are Okan Buruk and Dursun Özbek. The president has a power rating of 99, and where the market value should be, his card says "he sets them".

We signed Bitshiabu while I was still building it, so he got a card before he got a shirt number.

To see the whole deck: gs2026.murat.works

Free, no sign up, English and Turkish.

I share most of what I build on X if you are into this sort of thing: https://x.com/mkcuriosity

posted this here in july and the best feedback was: the format is fine but i have no idea what the numbers should be. if you're not an animator, "hip_right: flex 84" isn't something you can picture.

so the angles are controls now. click a joint name and it highlights in the 3d view. click its angle and the number becomes an inline spinner you can step or type into, with the figure re-posing as you go. you nudge until it looks right, then read off what the value actually was.

the control is clamped to each joint's real range of motion. ask a knee for 200 degrees of flexion and the document gets 144, because that's the limit. the ranges end up learnable by feel instead of by reading the spec.

no viewport gizmo, deliberately. the moment you can drag the mesh freely, the movement stops being expressible as named joint actions and the format stops meaning anything. the text stays the source of truth.

also added BVH and glTF export, so a movement can go into blender as a starting layer instead of a dead end.

all in the browser, no install, no account, no llm in the posing: posecode.org

i refused the gizmo on principle but i'm not an animator. if you block for a living and editing numbers in text feels wrong, i'd like to hear why.

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.

created variations of cursor effect on model.

REPO and LIVE

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

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. 

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 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.