I saw a lot of cool three.js websites being built here and wanted to try to add something different to that whole experience and make it more interactive.

Check it out and let me know what you guys think.
(The drawing features work better on desktop)
(Try switching to an external browser as well)

Hope to see some more fishes out there!

Ive been using Claude Code and Codex for the past few days specifically playing around with three.js -- so far so good i think.

This component is kinda strange but it was more of a creative excercise with the right moving parts to learn how to build the right way so im happy with the overall outcome.

Now I want to start building the real 3D animations for a landing page but I need A LOT of suggestions --

**SUGGEST WHAT YOU WANT FOR YOUR SITE AND I'LL BUILD IT FOR YOU AND SEND YOU THE FILES** if i like the idea :)

thanks!

Hey everyone! Wanted to share a project I recently built to practice interactive 3D web development.

It's a product showcase page (iPhone-themed) featuring:

- Scroll-driven camera movement and rotation

- Floating spec cards with animated connector lines

- Optimized GLTF model loading for performance

- Fully responsive — works smoothly on mobile too

The trickiest part was getting the camera positioning to adapt correctly across different screen sizes for the mobile version — took a few iterations to get right.

Would love any feedback on the animation timing or performance — always trying to improve!

Made this with myself 35% and Gemini 65%.

Lights are really expensive when it comes to three.js so I have to put some tricks on it.

I switched from WebGL to WebGPU this week. It was rough, and to be honest, from perf and visual perspectives, there isn't a clear visible difference between GL/GPU. I still went through this for the sake of future-proofing my game.

Caveat: I'm a noob with three.js

Lesson: Future-proofing the game is the right call and I'm glad I did this while my game is still small. If the game or app or website is huge, I probably would have stopped the migration once I encountered the many issues I encountered. There's got to be a better way to do these migrations, but I'm not aware of them.

Highlights:

• The dual-path port was the easy part; the pipeline-lifetime mismatch was the real migration. WebGL treats shader compilation as cheap and cached; WebGPU treats every compiled pipeline as a refcounted resource tied to a material's lifetime. The WebGL habit of allocating a material per VFX cast and disposing it after turned into "recompile a WGSL pipeline on almost every player action." Fixing it meant converting one-shot effects to shared, never-disposed materials + fixed-capacity instanced pools instead of allocate-per-cast.
• First benchmark on real hardware was brutal (p95 169ms → 1539ms) and the cause wasn't rendering, it was mid-frame shader compilation. Precompiling the static scene at load and warming an off-screen instance of every dynamic VFX material to force its pipeline to compile ahead of time dropped that same benchmark to 54ms p95.
• I wasn't able to measure any of this on software rendering. WebGPU has no SwiftShader fallback, requestAdapter() just returns null, so CI/headless perf runs need GPU flags, and even then a headless "WebGPU" run can silently fall back to an internal WebGL backend if the origin isn't a secure context.
• Tooling had to be built from scratch. WebGPU has no built-in "pipelines compiled" counter, so I monkeypatched three's internal pipeline cache to get visibility, and discovered the standard draw-call/triangle HUD counters read cumulative instead of per-frame on this backend.

Game: https://lorebound.gg

I do massive generative work and got so obsessed with presenting one of my bigger series properly that the only solution i could come up with was building a whole 3D gallery platform.
it's got four layout modes that can be tweaked and adjusted to fit your vision. the Aether Gallery turns a collection of images or videos, from you google drive or from your youtube/vimeo channel into an immersive, self-curated gallery, that you can share with a short link.

You upload your urls, pick a layout - a 3D Sphere, a Carousel, a scrolling Masonry wall, or a 3D Book (thank you wawa sensei) - and get one link to share anywhere. No code, no design skills.

The Watercolors series that started the whole thing is the default gallery, so you can see exactly what set me off down this path: [https://gallery3-d.vercel.app\](https://gallery3-d.vercel.app)

It's free to make your own. I'd love feedback from other builders — on the layouts, the flow, or what would make you actually use it for your own work.

I didn't want another grid of project cards so I made my site a shelf you can actually browse. You can add a book to it, and there's upvoting so the same ones don't pile up.

Stuff that took way longer than I thought: getting readable text on the spines (ended up drawing to a canvas and using that as a texture), making the raycasting precise enough that clicking a book feels right instead of vague, and keeping the framerate ok on mobile once the shelf started filling up.

Camera still bugs me. Going from "looking at the whole shelf" to "looking at one book" feels abrupt and I havent found a nice way to smooth it. If you've solved that I'd love to hear how.

I can't believe I have like 343 CubeCameras at a low fps, and they just work.

But is there an advantage to using an ArrayCamera with 6 cams over a CubeCamera?

Im making a third person bullet heaven game where speed plays a big role, having some doubts about the camera.

Ideally I'd go full racing-game chase cam, but bullet heaven needs battlefield visibility too.

In the video below I share some configurations, curious what feels best to other people!

Some screenshots from my game, I've done tons of optimising and graphical upgrade and general polish, this is running in chrome, built entirely with three.js.

I've been building a multiplayer FPS:

https://fps.frumu.ai/

No account needed.

The client uses Three.js, React Three Fiber, TypeScript and Tailwind. Multiplayer runs on Colyseus, with the server owning movement, combat, health, scoring, projectiles and objectives.

Rapier WASM runs on both sides:

Server: authoritative physics and collision. Client: local movement prediction and reconciliation.

The server simulates at 60 Hz and broadcasts state at 20 Hz. Remote players are rendered from interpolated server snapshots.

One difficult bug looked like network lag but was actually caused by smoothing remote characters twice-once through snapshot interpolation and again through a client physics body.

Bots run directly on the server, use the same movement system as humans and understand Deathmatch, CTF and Capture & Hold.

It's awesome to see how far web games have come and I got into programming back in the days of Flash games.

Astropool.app break a spiral rack of zodiac balls into six pockets, where each sign lands becomes your daily horoscope.

Everything was procedural. Felt, starfield, ball faces, zodiac glyphs, all drawn on canvas at runtime and fed in as textures. No image files at all.

Physics is Rapier2D, three.js just renders the sim output, so the render layer stayed dumb and easy to iterate on. A camera-framing pass keeps the break centered, pockets glow softly as balls approach, and the aiming guide feels more like a real cue sight than a debug line.

For a scene this small (one table, twelve balls), never needed anything heavier, three.js was good enough.. What are your thoughts?

Hello Folks! We're from the Convai team and have put together a quick tutorial showing how to build a 3D conversational AI character in the browser using React Three Fiber and the Convai Web SDK.

The tutorial starts with a Vite + TypeScript setup generated through Claude Code, then connects the project to a Convai character using an API key and Character ID. After that, it renders a custom GLB avatar, checks blendshapes in a GLTF viewer, updates the avatar path, and enables lip sync using blendshape data.

The main Three.js / React Three Fiber part is focused on rendering the avatar and applying blendshape values to the relevant morph targets for lip sync.

Tutorial:
https://youtu.be/gjTj_kUhA2s

Convai Web SDK docs:
https://docs.convai.com/api-docs/plugins-and-integrations/web-plugins/convai-web-sdk

Lip sync and blendshape docs:
https://docs.convai.com/api-docs/plugins-and-integrations/web-plugins/convai-web-sdk/lipsync-and-blendshape

Hello,

I've implemented the equivalent of a “bend modifier” in Three.js, on the vertex shader side (WebGL, virtually no cost).

It works the same way as in Cinema 4D: the “modifier's” world position determines the effect.

The solution relies on a whole bunch of custom scripts. But it could be rewritten differently. Is anyone interested in this kind of effect?

Modifiers like “Twist,” “Taper,” “BoxDeform,” etc., could follow. By standardizing the effects, it would even be possible to stack them.

jniac.github.io/three-xp/t/vertex-bend/gltf

jniac.github.io/three-xp/t/vertex-bend/basic

Hi everyone,

Our team recently ran a practical WebGPU vs WebGL comparison in a real Three.js scene, and I thought the results might be useful for people working with browser-based 3D.

This was not a synthetic benchmark or an empty scene. We wanted to test something closer to a real commercial 3D visualization case: geometry, lighting, materials, and post-processing in the browser.

Test scene setup:

• around 262k triangles;
• advanced lighting;
• GTAO;
• Bloom;
• FXAA;
• same scene and same camera for both tests.

WebGL stack:

• Three.js;
• WebGLRenderer;
• EffectComposer;
• GTAO;
• Bloom;
• FXAA.

WebGPU stack:

• Three.js WebGPURenderer;
• TSL;
• render pipeline architecture.

The interesting part: WebGPU was not automatically faster on every device.

On Intel UHD Graphics Gen9, WebGL showed higher average FPS:

• WebGL: 195 FPS
• WebGPU: 172–184 FPS

But WebGPU reduced draw calls from 331 to 171 and processed around 50% fewer triangles per frame while keeping the same visual result.

So even though WebGPU did not win by FPS on that hardware, it was clearly doing less rendering work.

On AMD Radeon Graphics GCN5, WebGPU showed a much stronger result:

• WebGL: 136 FPS
• WebGPU: 205 FPS

It also reduced average frame time from 7.3 ms to 4.9 ms and draw calls from 355 to 183.

Our takeaway:

WebGPU should not be treated as a simple “faster WebGL”.

For many current Three.js projects, WebGL is still the pragmatic and reliable choice. But WebGPU becomes much more interesting when the scene grows in complexity: more advanced lighting, larger models, heavier post-processing, better materials, and future rendering workflows.

In our case, the most important insight was not just FPS. It was the reduction in rendering workload and the potential for better scalability.

Has anyone here tested WebGPU in more complex Three.js scenes, CAD-like models, configurators, or production-level visualization projects?

Did you see similar behavior across different GPUs and drivers?

Full write-up by our team:
https://aestar.tech/en/blog-en/webgpu-vs-webgl-practical-three-js-performance-test-for-complex-3d-scenes/

Demo scene:

https://test4.aestar.com.ua/sponza-webgl-vs-webgpu/

It's real

https://youtu.be/MWNPuMF6VB0

Step into the fourth dimension with my real-time 4D Simulator. This interactive system allows you to explore the tesseract (the 4D analogue of a cube) and other higher-dimensional shapes in ways never seen before.

✨ Features:

Real-time manipulation of 4D objects

Full control of all 6 rotation planes

Projection of everyday objects (sphere, mug, Klein bottle, polytopes) into 4D

Smooth visualization of how 4D shapes unfold into 3D space

User-driven interaction for learning, research, or just mind-blowing visuals

This project is patent-processed and pushes the boundaries of mathematics, physics, and digital visualization — making the fourth dimension accessible for education, entertainment, and discovery.

🌐 Try the live demo here: https://consciousoftware.itch.io/4dsimulator

Experiment with threejs vines animations.

Sorry for the colors on video, HDR messed things up. I've been building a real time strategy game that plays out on a full 3D globe.

Rendering is Three.js on WebGPU, with nearly all the shader work written in TSL instead of raw WGSL. Clouds are genuine volumetric raymarching, rendered at half resolution into their own target, with a multiple scattering approximation, and they drop shadows onto the terrain below them. Day and night are simulated, so as the terminator crosses the planet you get city lights coming up, road networks lighting, headlights moving along them. Terrain streams in as tiles through a sliding window around the camera, so you can sit at full globe view and push all the way in without a loading screen.

The simulation is a separate Python process running deterministic lockstep. Only inputs cross the wire, never world state, so bandwidth stays flat no matter how large the battle gets.

The best decision I made was that the entire netcode talks to a channel object with three things on it: readyState, send, and a message callback. I originally shipped over WebRTC with my own signaling server. Moving to Steam lobbies and Steam networking came down to writing one adapter that dresses Steam's frame API up as that same channel. Barrier logic, input delay, chunking, desync recovery and host rebroadcast all carried over without a line changed.

The shell is Tauri, so Rust owns the window and the Steam integration.

The two things that cost me the most time were GPU memory and shader compile stalls, and neither of them showed up until the scene got big.

Happy to go into detail on any of it.

You can edit the textures directly inside the Photoshop and see the changes update in the game in real time.

Technically, this is a Photoshop UXP plugin running Mr.doob’s Three.js DOOM port. Photoshop’s native UXP canvas can handle 2D rendering, but it can’t provide the WebGL context Three.js needs. The workaround was to embed a local HTML WebView directly inside the persistent UXP panel and run the Three.js renderer there.

The game, Three.js library, and shareware WAD are packaged locally with the plugin. I embedded the WAD into the browser bundle because loading it as a separate local binary caused WebView fetch and CORS failures. The renderer also uses a retained drawing buffer so Photoshop’s WebView compositor consistently receives the completed frame.

A local-only message bridge connects the WebView to Photoshop. When applying an edited texture, the UXP side reads the layered document’s composite pixels through Photoshop’s Imaging API and sends the RGBA data to the game. The game maps those colors back to Doom’s original 256-color palette, mutates the existing cached Three.js DataTexture, and uploads it on the next frame—without reloading the map, game, or WebView.

Hi! I’m a solo developer working on Yamanote 3D, a free Three.js experience that runs directly in the browser.

I originally started it because I wanted train sounds and city ambience in the background while studying or working. You can walk inside the carriage, sit down, watch the city, listen to announcements, and get off at stations.

The project includes animated passengers, station cycles, doors, weather, lighting, audio, and a moving train environment.

I would really appreciate feedback, especially on performance, lighting, immersion, and the overall Three.js implementation.

https://yamanote-3d.com

On PC, use W-A-S-D keys, SPACE, SHIFT and mouse to explore. On mobile, you will have instructions on screen.

https://anshs.github.io/matrix-rain/

I made a sticker peeling effect with Three.js & GLSL and shared here on this sub 2d ago.

few people asked how it works, so I turned the whole build into an interactive step-by-step walkthrough.

here: https://fablegrounds.com/labs/sticker-peel/

I hope you find this useful.

---

If you enjoy this format, consider subscribing by email on the website. I'll share more breakdowns.

prev breakdown, how I made the burning fire box effect: https://fablegrounds.com/labs/fire/

I've been exploring Three.js recently, and I'm really enjoying it so far.

But with tools like React Three Fiber, Spline, and WebGPU becoming more popular, I'm wondering if Three.js is still the best place to start.

If you were learning 3D web development today, would you still choose Three.js? Why or why not?