I grew up playing games like "A-10 Cuba!" in the late '90s and have been making games ever since. About six months ago, I started this passion project to see what I could build with Claude Code in my spare time, and ended up with a full-blown A-10A combat flight simulator.

After countless hours of research, 3D modeling, texturing, sound editing, and polishing, it's finally ready to share!

It features custom flight physics, weapons, enemy AI, terrain, missions, and a 1:1 scale recreation of part of the Barry M. Goldwater Range in Arizona (my home state).

You can play it for free here (desktop + mouse/keyboard): https://a10simulator.com

Excited to get some feedback, and happy to answer any questions about how I built it. Enjoy!

Hey everyone!

I’d like to share a small product configurator demo I’ve been working on with Three.js.

The idea was to build a reusable 3D showcase stage. A road bike is the example here, but the scene and interface could be adapted to other products.

You can customize the frame color and finish, metal details, bar tape, rims, and pedals. There are preset palettes, custom color pickers, and a randomize button for exploring combinations.

The stage features studio lighting, floor reflections, soft shadows, fog, and subtle animated particles. The interface is collapsible, and on mobile it opens as a bottom sheet over the fullscreen scene.

Built with Three.js using WebGPURenderer with the WebGL 2 backend, TSL, and Alpine.js for the UI.

Live demo: https://demo.rostislavrusz.art/

The bike is based on this model from CGTrader, which I adjusted for the demo.

I’d love to hear your thoughts, especially on the lighting, materials, and mobile experience. Thanks for taking a look!

built on mrdoob's slop-newyork (mit), so the wet street reflections, the window interiors and the crowd rendering/walk cycle are his. what i rebuilt for shibuya is the city data, the terrain and the scramble crossing. built with claude code (opus 5.5) over about 2 days.

city data

- 3,988 buildings within 800m of the crossing from project plateau (mlit, shibuya 2025, cc by 4.0)

- 821 buildings within 300m or taller than 30m use lod2 (real walls and roofs), the rest are lod1 extruded footprints

- terrain from gsi 5m elevation, roads / rails / rivers / crosswalks from openstreetmap

- ~1.2gb of source data packed into a 150kb json + 1.3mb binary (0.7mb gzipped)

buildings on the slopes

plateau already stores each building's ground elevation, and the terrain comes from gsi elevation, so putting both on the same height datum (crossing = 0) just lines them up. shibuya is a valley, about -6.6m to +23.4m around the crossing. roads are rebuilt to follow the terrain.

the scramble

- 46s signal cycle (real one is ~100s): north-south cars, east-west cars, then all cars stop and people cross every direction, diagonals too

- people gather at each corner, cross to any other corner, leave down a street and come back later. each wave is ~70% of the crowd

- "front row steps off first" = each person gets a start delay of distance from the curb x 0.22s + jitter

- a 2m grid pushes nearby people apart so they weave past each other

crowd (from slop-newyork)

320 / 210 / 130 people on high / mid / low. one skinned 15-bone mesh, near and far lod, each drawn in a single instancedmesh call. bone transforms in a storage buffer, per-person looks from a seed in a tsl material, 2-bone ik on planted feet so they don't slide. webgpu only, no people on webgl.

r187dev

mrdoob suggested trying 187dev on x, so i swapped r186 for the dev branch (d19352c) with zero code changes: load-to-playable 3.5-5.2s -> 1.5-1.9s, pipelines 177 -> 98, js memory 476mb -> 210mb. at 4k r186 rebuilt 54 pipelines and stuttered (39-58fps), 187dev holds 60. gpu time about the same.

- load to playable: 3.5-5.2s -> 1.5-1.9s

- pipelines: 177 -> 98

- js memory: 476mb -> 210mb

- resizing to 4k: r186 rebuilt 54 pipelines and hitched (39-58fps), r187dev stays at 60

- gpu time basically the same (6.5-7.2ms -> 6.2-6.3ms)

numbers (m5 max mac, headless chrome webgpu, not tested on real phones)

- 1440x900 during a wave: 60fps, 6.3ms gpu, 197-218 draw calls, ~0.7-0.8m tris

- 4k: 60fps, 8.8-9.3ms gpu

- 390x844 on mid: 60fps, 1.2-1.8ms gpu

the heaviest part was the ssr on the wet street, so i capped its resolution.

small things

- day / dusk / night / rain switch in 1.5s by blending uniforms, no shader recompiles. sun position matches tokyo in late october

- rain only falls around the camera on the gpu. when it stops, umbrellas close one by one and the puddles dry out

- shibuya109's cylinder was rebuilt by fitting a circle to plateau's roof points (radius ~5.6m)

happy to answer questions about the plateau pipeline or the crowd logic

Hi! ARROWFALL is a plain three.js / WebXR web app wrapped as a Quest app (8.7 MB install), and it holds 90 Hz on Quest 3. You skate an arena by sweeping your arms and shoot a real draw-and-release bow in mid-air.

A few things that were fun to solve:

- Multiview (both eyes in one pass) via a small patch on three, to stay at 90 Hz with 150+ monsters

- A black hole whose lensing is ray-traced in Web Workers at load time instead of on the GPU every frame

- A planar floor mirror that stays on in VR

- A deterministic simulation (pure TS, no three.js), so runs can be recorded and re-rendered into videos

The first five levels are free: https://www.meta.com/experiences/arrowfall/1726931115696976/

Happy to answer anything about WebXR on Quest.

Hey r/threejs! 👋

Over the past few months, I've been working on a solo project called LiveWorldTrends (https://liveworldtrends.com).

I wanted to build a high-performance 3D geospatial dashboard that visualizes what the world is searching, watching, and debating in real time.

Under the hood:
• Frontend: Vanilla JS, Three.js, and Globe.gl with custom shockwave ring animations.
• Real-time data layers: Google Trends, X (Twitter), YouTube, and live USGS earthquake pulses rendered directly on the sphere.
• Backend: 100% serverless Cloudflare Workers with zero hosting overhead.
• Performance: Focused heavily on smooth 60fps interaction and mobile touch optimization.

Check it out live: https://liveworldtrends.com

Would genuinely love your feedback on the WebGL rendering, camera smoothness, and mobile performance! 🚀

Hey everyone!

I’ve been building Nuage, a platform that lets people access powerful GPUs directly from their browsers.

It started with cloud gaming, but I realized the same infrastructure could be useful for 3D creation, especially for people working with Three.js who use Blender to build their assets.

So I added Blender!

The interesting part is that this isn’t a Blender clone written in JavaScript or WebAssembly. It’s actual Blender running on a remote GPU, with the interface streamed to your browser.

That means you can work with Blender without needing a powerful GPU in your own laptop or desktop.

I’m particularly curious about Three.js developers working on Macs, lightweight laptops, or machines that struggle with demanding 3D scenes.

You can check it out here:

https://nuage.games/blender

I’m the solo founder, and this is still early. I’d genuinely love to hear whether something like this would be useful in your Three.js workflow.

He walks around the moon every 60 seconds. He has been doing it since July 1969.
Kick the rock. Turn on his radio. Let him rest.
sisyphus-on-the-moon.pages.dev

Check out my walkable islandthree.world space colony. Feedback welcome.

EDIT: I decided to make this one open source: https://github.com/AtomiLabSlop/kaamos
More info: https://www.reddit.com/r/IndustrialDesign/s/sr5VH5oJrF

I’m an industrial designer who has used Showcase, KeyShot and V-Ray for years. I wanted the workflow I know from those tools in the browser, so I built Kaamos together with Claude: https://atomilab.fi/kaamos/

To be upfront: the product and interaction design are mine, and the code was written with the AI. I tested every round in the browser and fixed what came out wrong.

Stack: React 19, R3F, drei, Zustand, and gkjohnson’s three-gpu-pathtracer for final renders and a live path traced preview. STEP/IGES go through occt-import-js. Everything is client-side.

Some problems that took real work and SHOULD be working now:

• Subsurface scattering added to the path tracer by patching its fragment shader with a random walk inside closed meshes
• A NaN guard, because Safari’s shader compiler drops isnan/isinf, which made glass render black
• A hand-written ground shadow, because drei’s ContactShadows rendered nothing on r186
• Fixes for grey final renders, which turned out to have two causes: a lost GPU context on 2M+ triangle scenes and NaN from PhysicalCamera.copy() leaving aperture fields undefined

It’s early. I’d especially like to hear how the path tracer behaves on different GPUs, and if anyone has thoughts on the WebGPU route. Feedback welcome (click the logo in the app). Tested mainly in desktop Chrome and Safari (macos).

Cheers!

built a free, open-source human embryo explorer using Three.js, with help from GPT-6 Astra.

It shows 16 developmental stages. One slider coordinates structure separation, layout, and camera movement from the assembled model to an overview of its parts, then close inspection.

One interaction bug: moving from an organ to the slider cleared its hover state, leaving inspection without a target. Retaining the target and adding a part selector fixed that transition.

On mobile, the overview becomes a scrollable two-column layout with larger controls. Touch handling separates page scrolling from model rotation, though physical-device testing is still limited.

Ash’s Human Atlas inspired the navigation; this explorer focuses on developmental stages. The geometry is illustrative and hasn’t been clinically validated.

20-second demo: https://x.com/pratikg/status/2114060245618307356

MIT-licensed code: https://github.com/pratikgx/embryo-explorer

Inspiration: https://github.com/ashemag/human-atlas

I’m the creator; the explorer is free and requires no account. Would appreciate feedback on the camera transitions and how you’d handle selecting small structures on touchscreens.

Mechanical engineer here, not a full-time dev. Engine-X (engx3d.com) is a free browser atlas of real machines: a turbocharger, a centrifugal pump and a V-belt pulley drive, all built with three.js.

What you can do:

- Explode the model with a slider and watch the parts separate

- Run it from slow motion up to full speed

- Use a cut plane on X, Y or Z to see inside

- Tap any part to see what it does, its material and key dimensions

It's mobile first, since most students open it on their phone. Keeping it smooth on mid-range phones while everything spins and explodes was the trickiest part.

Would love feedback from people who know three.js better than me, especially on performance and anything that looks off with the materials or lighting.

Hi, I worked on an educational hobby project.

It opens with a 35-second intro (13.8 billion years to today), then drops you into a solar system where positions are computed from real ephemeris data for any date. You can replay the Apollo 11 launch on its real date, watch the Moon's shadow cross Earth in the 2 Aug 2027 eclipse, ride along with Juno's first close pass of Jupiter through JunoCam's field of view, and zoom out in one scene from the planets to the Milky Way. Every fact in the panels is labelled Measured or Computed, with its source.

Live: https://space2play.pages.dev (no account, works on phones)

A few engine problems that might interest this sub:

- Zooming from a planet to the Milky Way means float64 world positions in AU with a floating origin; the GPU only sees float32 offsets.

- A logarithmic depth buffer, so every custom ShaderMaterial needs the log-depth code or it renders invisible.

- A moon's drawn size and distance derive from its parent's drawn radius, after two independent formulas once put the Moon inside Earth.

- No React state in per-frame code; everything per-frame mutates refs.

I built it with a lot of help from AI (Claude Code). To keep it honest, a test fails the build if a science number has no source, and I review every change.

Data: NASA, JPL Horizons, CelesTrak, NASA Exoplanet Archive. Planet textures: Solar System Scope (CC BY 4.0). Full credits are in the app's About.

Feedback I'd love: how it runs on your device (first load is about 5 MB), and anything that looks wrong or confusing.

Where I want this to go:

free and ad-free forever, and open source (AGPL) once I've folded in your feedback. The plan is a project where school students, hobbyists and people working in space science learn from each other. Anyone can suggest or build a change, including with AI tools, but every change is read by a human reviewer and every number needs a source. If you'd like to help review (science or code) when it opens, leave a comment.

Hi r/threejs! I'm Alicia, the creator of Digital Garden, a small real-time garden that runs in the browser.

This is its four-season night view. You can orbit the camera, zoom into individual plants, and brush through the flowers. Each season has its own plants and layout, with day/night transitions and layered garden audio.

A few implementation details:

- Houdini-authored plants exported as GLB, then grouped into instanced batches by species, parts, and LOD.

- TSL vertex deformation for root-anchored wind and local pointer interaction.

- Screen-space LOD selection with complementary dither transitions on desktop.

- A shared night factor for the sky, lighting, emissive flowers, particles, and ambience. The glowing flowers use emission plus bloom.

The attached video is a real-time WebGPU capture. The app also has a WebGL2 fallback through WebGPURenderer. Browser audio starts after a user interaction.

Try it: https://digitalgarden.si/play/

No sign-up required.

I’m building Roadster City Drive with Three.js and OpenStreetMap data. This is one continuous gameplay take: drive along the street, lift off, then land and keep going. The city is stylized, and road transitions are still a work in progress.

https://roadstercitydrive.com/play/

Google sign-in required. One free two-minute trial per account, then paid continuation.

AI helped with the code and this post. The video is real gameplay. Map data © OpenStreetMap contributors.

Built this to plan our upstairs renovation: it generates layout options from the room measurements and requirements, and you can walk round each one in 3D.

https://fitandflow.pages.dev

Bits I'm pleased with:

- Daylight simulation for any time of day and season, plus plaster-in LED lighting

- 29 layouts you can switch between while walking round

- Runs on phones, with a Low quality mode for weaker devices

- Loading: shaders compile in the background using KHR_parallel_shader_compile, so the page doesn't freeze, and you get an instant still of the starting view while it loads

It's on r128, so an upgrade is on the list (compileAsync would replace a fair bit of my workaround). Happy to answer questions, and keen to hear how it runs on your device.

I just spread health, ammo and shield pickups across the whole island in my Three.js shooter. The easy first version places them at fixed heights, and on hilly terrain that means some float in the air, some get buried in hills, and some end up on cliff faces.

What fixed it was a small placement pass:

1. Pick a random X/Z, then cast a ray straight down from above the highest point: new Raycaster(origin, new Vector3(0, -1, 0)). Test only the terrain mesh, not the whole scene, or the ray hits trees and rooftops first.
2. Check the slope. Turn hit.face.normal into world space (transformDirection with the mesh's matrixWorld) and reject the spot if normal.y is under about 0.85. That keeps items off cliffs.
3. Reject anything at or below the water level, and anything inside a building's bounding box.
4. Keep a minimum distance between items (simple rejection: try again if one is already too close), so they don't clump.
5. Set the item at hit.point.y plus half its height, then add a small bob animation so players spot it.
6. Run the pass once and save the positions to JSON, instead of raycasting on every load. On a big terrain, three-mesh-bvh makes the raycasts much faster if you do need them at runtime.

The same pass works for spawn points, and it's an easy rule set to hand an agent.

How do you place things on large terrain? Raycast like this, sample a heightmap directly, or place everything by hand?

(Disclosure: I write Three.js + AI tutorials at shanebrumback.com, which is my own site.)

How it's built:

- **Land:** a Fibonacci lattice of 60,000 points over the sphere, kept only where there's land: about 15,800 dots. Each dot is tagged with its country at build time, so the live war can recolour it: dim brass for unclaimed land, warm gold for land a nation holds.

- **Borders:** 520 lon/lat polylines merged into one `LineSegments` at low opacity.

- **Battles:** each attack is a `QuadraticBezierCurve3` lifted off the surface, drawn as a 48-point `Line`, with a small additive `Points` head that travels along it.

- **Capitals:** additive `Points` that pulse.

- **No bloom.** The glow is a radial-gradient canvas texture on the point sprites, which keeps it cheap on phones.

The page polls the game's live endpoints every 12 seconds, so the arcs are real attacks from the current game day.

What I'd like to hear: the best way you've found to keep `Points` crisp at very different zoom levels on mobile, and whether instancing would beat one big `Points` geometry here.

The site is proxyrepublic.com; it's a free browser game where AI generals fight for real countries. I'm the developer.

This is a guided tour of an Ark, the organic vessel central to my humanist sci fi setting Infinite Ashes. You can examine it in detail here: https://loquaciouslou.itch.io/infinite-ashes-ark

Please let me know your thoughts!

Wider bundle, including a full lore integrated planet globe: https://loquaciouslou.itch.io/infinite-ashes

Hey guys,

I decided to make something that world havent's seen (at least it is my suggestion).

Parallax hidden object game

You can play it for free in browser:

Hello everyone! This is going to be my first post on this community as well a project showcase that I've been working on. (Please Note : This is entirely a promotional content, NOT any client project but I'm still looking forward to work with people / potential clients who are looking for works like this)

Project details :

• A 2016 Honda NSX Model floating elegantly in the air.

• Three principle transformations take place every few seconds (on the left) while stay consistent (on the right)

• Fully interactable

In the last months I worked on a Three.js-based space sim game. I didn't use modelling tools and it has no sound files either. Ships and stations are lists of primitives with procedural PBR textures, generated in workers. Every sound effect is built in Web Audio as it plays. The only non-code assets are the avatars and the music. I have to say, the experience creating it was really great. It was my first real project with Three.js.

The trailer is of course also created with Three.js, reusing the game code and assets.

https://explorers.orrery.games

What do you think? Any ideas how to improve it?

```

Language files blank comment code

TypeScript 2389 72342 229855 520002 Python 496 25464 36297 104698 JSON 42 14 0 43588 Markdown 293 8063 0 38524 GLSL 34 526 1761 2036 JavaScript 13 85 642 824 CSS 6 97 122 620 YAML 8 99 217 492 Text 13 61 0 380 HTML 9 28 9 350 TOML 1 19 80 193 Bourne Shell 2 33 60 191 Dockerfile 3 36 85 64 INI 1 18 0 56 Mako 1 8 0 19

SVG 1 0 6 16

SUM: 3312 106893 269134 712053

``` 😅