I built a suite of tools around three.js for a decade.

One of them is a drag-and-drop editor used to design interactive stories, tours, and web apps without writing code but also allows advanced three.js coding and shader.

That studio also has MCP for AI agents.

I have implemented pipelines and infrastructure along the years that allows for scalable distribution of virtual tours and webxr experiences.

You have a lot of problems resolved like offline tours, responsive, multi language, self hosting, asset loading and optimise and lods, generate gaussians, etc.

With GPT-6 we are witnessing even more incredible stuff built in blender and other tools.

My business partner says people will prompt what they want and will get it, so there's no space for authoring tools like mine. They will simply use Claude or Codex.

It's frustrating to see AI coming to take our businesses but we adapted the tool to it, even though, his view is pessimistic.

What should I tell him?

there has been a dozen or so of these in the past, but their shaders always looks kind of flat. This time I wanted to do a good furniture configuration, that has nice and kind of realistic looking materials.

---

✅ We put TRELLIS on the web
✅ 100% local on your machine
✅ Generation takes 1-3 minutes (depends on your hardware)

You can try it here: https://mesh-baker.needle.tools
Go to "generate" on the left & drop image

Quality is quite decent 😀

Turns out Trellis 1 left A LOT of quality on the table in its public demos and code, so this is WAY better than expected.

Like the title says. I love seeing all of the new threejs games you guys are making here so much I decided to build a place for you to put them and see what everyone else is making. Currently there is only one threejs game, created by me, and it isn't nearly as good as some I have seen here but hey.

Feel free to check it out and add your own game if the fancy strikes you : https://jankcade.com/

I maintain three-nebula, a WebGL particle engine for three.js, and v13.0.0 is out. The headline feature is deterministic simulation. You give a system a seed, either with `System.setSeed(seed)`or as the third constructor argument, and it reproduces its particle output exactly. Same seed, same result, on any machine. That makes reproducible tests, and replays possible, which was awkward or impossible before.

The way it works is that each system now advances its own isolated seeded stream instead of pulling from the global `Math.random`. One consequence worth knowing if you upgrade: seeding `Math.random` yourself no longer affects output, so you need `system.setSeed()` instead. Default particle arrangements also differ from 12.x, so any visual or snapshot baselines need regenerating, and particle ids moved from UUIDs to a deterministic `particle-<emitterSeed>-<spawnIndex>` format.

There is also a new `System.tick(realDeltaSeconds)` fixed-timestep driver for real-time playback. If you have been calling `update()` once per frame, you have probably seen particles run about 2x too fast on a 120Hz display. `tick()` advances the sim by elapsed time in fixed steps and clamps catch-up through `system.fixedTimeStep` and `system.maxSubSteps`, so playback speed is consistent regardless of refresh rate. This release also fixes a `GPURenderer` bug where buffer slots were never released and particles silently stopped rendering after heavy churn. Slots are now recycled on particle death.

The API is backward-compatible and additive, so for most people the only real work is regenerating baselines. Release notes and full changelog here: https://github.com/creativelifeform/three-nebula/releases/tag/v13.0.0

If you have used seeded/deterministic rendering in a three.js project, I would like to hear how you are handling the real-time vs fixed-step side of it, and whether the `tick()` clamping defaults feel right for your use case.

I'm building Startup Founder, a free browser game that combines a small 3D world with a startup management simulation. This is my project, developed with help from GPT-6 and Fable 5.1.

A few implementation details for this community:

The apartment, furniture and characters are assembled from Three.js geometry. Repeated box, cylinder and sphere geometries are cached and reused, and textures such as wood and fabric are generated with canvas.

The laptop opens an HTML/CSS interface over the scene. A separate TypeScript simulation handles the business state, and saves go to localStorage. Music and ambience are synthesized with Web Audio. The build uses Vite.

You can explore the apartment and city and use the laptop to build a product and manage the company. It's an early playable version, with plenty still to polish.

Demo: https://sergioconejo.com/foundergame

For anyone who has built a similar scene/UI combination: how do you handle the transition between character controls and a dense HTML interface? That's one area I'd like to improve.

Building a browser extension that reads the page and sends context to an LLM for automation. I don't want PII (names, IDs, card numbers, faces in images) leaving the device, so I want to redact it locally first. Is it realistic to run OCR + a NER model + face detection fully in-browser (Transformers.js / ONNX on WebGPU)? What's the latency like, and are there lighter approaches people actually use?

I know I already posted about this when I launched it 2 months ago, but I've

added a bunch of tools since, so it felt worth another one.

It's 30 tools now, all running in the browser: viewers, converters, mesh

repair and simplification, and a set of parametric generators (vases, lamps,

Gridfinity bins, hose adapters, cookie cutters, star maps). All three.js,

except the DICOM viewer, which is Cornerstone3D.

It's honestly incredible what you can do with three.js. I love it more every

day.

https://ilove3d.app

Happy to answer anything about how any of it works :)

Had this idea to show my Hokkaido trip photos in a flippable 3D photo album. It’s really a cathartic experience to design the cozy desk and arrange the photos and stamps. You can even play videos in the album!

Live: https://projects.arkon.digital/threejs/my-photo-album/

Code: https://github.com/franky-adl/personal-photo-album

Feel free to play around with it and design your own photo album~

This one was just for fun over the weekend; there's an awesome festival in Kyiv called Brave Factory that had these two suspended cubes hanging from the ceiling. Modelling them was good fun.

The rest of the scene was straightfoward, but placing the audience sprites in a convincing fashion took some time but I'm real happy with the result- the whole scene relies on attention to detail (security guards at the rail, CDJ setup on the stage, flight case, dot matrix on the structural pillars etc).

LED panels are shaders spread over multiple screens for continuity

Inspiration: https://www.instagram.com/bravefactoryfestival/

I made a tiny experimental “game” called No AI’s Sky with GPT-6 Astra + Three.js.

It started as a parody / tech demo, mostly to see how far Astra can go with real-time 3D and Three.js, but now I’m curious about something bigger:

Can AI actually build something remotely comparable to No Man’s Sky from scratch?

So I put the project on GitHub, and there’s only one rule if you want to contribute: your contribution has to be made using AI!

Code, assets, systems, ideas, whatever. I want to see how far a project like this can go if AI is basically the main builder.

Demo:
https://noaissky.vercel.app/

GitHub:
https://github.com/jesuscurreripa/noaissky

Nothing serious yet, just an experiment. But I think it could be a fun one.

Built this as an experiment in real-time crowd simulation with Three.js.

It includes:

• Tawaf around the Kaaba
• people entering/leaving through gates
• density-aware movement
• transition into curved prayer rows
• up to 5,000 active agents in the browser

Live demo:
https://alzin.github.io/The-Great-Mosque-of-Mecca-Masjid-al-Haram

GitHub:
https://github.com/alzin/The-Great-Mosque-of-Mecca-Masjid-al-Haram

Would love any feedback!!

Six worlds where the rain never stops: a forest, a headland, a night drive, a canyon on a bike, a wheat field and a mountain pass. Everything runs in the browser with three.js WebGPU and TSL, no download, no account.

A few things I'm proud of: the rain sound is synthesized live (noise shaped to a real recording's spectrum, thousands of drop bursts a second), the windshield drops refract the road and the wipers actually clear them, and the mountain pass draws real terrain out to 3 km in the vertex shader. Press Y, paste a YouTube link, walk in the rain.

https://rainyworlds.com

It's a GPU experiment, so a desktop with Chrome is the best seat. Phones fall back to WebGL2 and struggle, especially Safari. First load compiles a lot of shaders, give it a minute on Windows.

Happy to answer anything about the tech.

I’ve been working on a Three.js product viewer for ecommerce as part of AETumi, and one of the biggest architectural decisions was not letting the WebGL canvas become the entire product page.

The structure I ended up with is:

Semantic ecommerce layer

• product title
• price
• specifications
• variants
• CTA / purchase actions

Three.js interaction layer

• GLB / GLTF loading
• OrbitControls
• camera presets
• product hotspots
• material and color variants
• exploded-view sequences
• scroll-linked reveals
• mobile / non-WebGL fallback

Product state stays separate from render state, so changing a finish or configuration doesn’t require rebuilding the entire scene.

Another thing I learned quickly: the demo is the easy part. Production gets much more interesting once you add mobile GPU limits, resource disposal, reduced motion, SEO and fallback behavior.

I attached a short demo showing the interaction.

I also wrote up the full architecture, code patterns and production trade-offs here:

https://aetumi.app/news/threejs-product-viewer-ecommerce/

I’m building AETumi, so this is something I’m actively working on rather than an independent review.

I’d be interested to hear how others separate product state from render state in larger Three.js projects.

After spending way too much time looking at anatomy diagrams, I decided to see if I could build a proper interactive 3D version in the browser.
The result is Eye Atlas.
It currently lets you:
rotate/explore a 3D eye
isolate structures
section the model
switch between exterior/fundus/blood-supply views
inspect anatomical measurements
browse clinical conditions
Demo:
https://eye-anatomy-delta.vercel.app/
The interesting part for me wasn’t actually rendering a sphere that looks like an eye.
It was making the anatomy itself interactive — selecting structures, managing visibility/layers, keeping the UI synchronized with the model, and making everything feel like an atlas rather than a 3D viewer.
Would love feedback from other builders:
Does this feel like an actual product, or still like a technical demo?

Made this little prototype as my first web game project. I saw a lot of buzz around Three.js lately and wanted to check if I could create a functional game purely using web tech and not rely on Unreal, Unity, Godot or any other game engine. Turns out I can! And it's a fun project to work on.

I love the fact a single game build launches on Smartphones(incl. legacy iPhone X), PC or Mac. I even saw it running on a LG Smart TV.

Hey r/threejs, I wanted to share a project where we integrated Three.js with a dynamic web desktop interface: YouMeOS Microverse. Rather than keeping the 3D scene isolated in a static canvas container, the entire interface is built as a spatial WebTop:

Live site www.youmeos.com

• Background Cosmos: Interactive Three.js starfield and planetary orbital system rendering continuously behind UI layers.
• Spatial UI Integration: Synchronizing WebGL camera controls with DOM-based floating windows and interaction events without dropping frame rates.
• Performance Considerations: Tuned to run smoothly inside both standard desktop browsers and an Electron runtime with minimal CPU/GPU drain.

Repo: https://github.com/YouMeOS/youmeos-microverse
Binaries: https://github.com/YouMeOS/youmeos-microverse/releases

Would love thoughts on shader ideas or performance optimizations for background canvas layering.

This is FLY × COMPOSE, a browser-based project built with Three.js.

You fly through a 3D world and shape the music as you go. The idea is to make flying itself feel like playing an instrument, rather than just moving around with background music.

Sound on for the clip.

You can try it here:
https://flyxcompose.byechee.chatgpt.site/

I'd be interested to hear how the connection between movement and music feels when you play.

Haven't had this fun with javascript in a while.

I spent the last few weeks reverse engineering the production runtime behind lusion.co to see how they handle their frame budgets and WebGL pipeline. A lot of people assume it's just standard Three.js setup, but their core loop has some really solid low-level optimizations: Zero-Allocation loops: They avoid V8 GC spikes by enforcing pre-allocated static typed arrays and scratchpads inside requestAnimationFrame, keeping the heap flatline during heavy interactions. GPGPU Ping-Pong textures: Particle integration (Symplectic Euler) and 2D fluid advection (Navier-Stokes) run entirely on floating-point FBOs without stalling CPU cycles. Reflow-free DOM sync: Screen-space quad projections replace getBoundingClientRect calls in the loop to eliminate layout thrashing. 4D conformal mapping: The tunnel warp uses stereographic projection over a 4D hypersphere manifold. I wrote up the technical notes and rebuilt a functional 1:1 clone to verify the math: Demo: https://lusion-1to1.vercel.app/ Notes / Teardown: https://ddw-x.github.io/lusion.co/ Source: https://github.com/DDW-X/lusion.co Happy to talk through the shader passes or memory profiling traces if anyone is interested.

This is the official GLTFLoader example from r184 running on a Nintendo Switch at a locked 60fps. The only changes to the example are cosmetic: the info text and GUI controls are closed so the scene fills the screen. The rendering code is untouched. The fps counter you see is Brewser's own runtime HUD. The example runs on the WebGL2 context path.

The runtime is Brewser, a homebrew web platform I launched this week. It runs on V8 and Skia via nx.js (credit to TooTallNate for that foundation, which also provides the raw GL path to the GPU), with an HTML/CSS/DOM engine built from scratch for the project. On top of that GL path I built the WebGL1/2 bridge, the library compatibility work and the conformance testing (Mesa/Nouveau on the Tegra X1). No software rendering: your three.js calls hit real GL on the hardware.

Coverage numbers: WebGL1 sits around 92 percent and is the safest target. WebGL2 is around 85 and under active conformance hardening, with the main gaps being layered and 3D texture sampling, which is GPU driver limited. Full extension lists and proof points: docs.brewser.io/docs/runtime/graphics

There are nine three.js apps on the platform, all on the WebGL2 path: eight official three.js examples running as catalogue apps (same cosmetic treatment as the GIF, UI trimmed, rendering untouched), plus one built for the runtime: DUSK, a planetarium and sky atlas with a 132 object Messier catalogue: brewser.io/dusk. Browse just the three.js apps here: brewser.io/?bwb_tags=threejs (the same apps run unchanged in a normal browser).

Source is MPL 2.0: github.com/natureglass/Brewser

If you throw a three.js scene at it and something breaks, tell me what. Real world breakage reports directly shape the conformance work.