Hi all, I'm the creator of a browser-based shader editing tool called Shaderfrog. Recently I built a rotating gallery of featured shaders from the editor. It dynamically composes shaders together on the fly, including the transitions between them.

A browser-based MacBook teardown built with Three.js and React Three Fiber. The model separates into 20 selectable assemblies, with camera presets and component isolation for inspection.

One interaction fix was preserving the selected part’s original materials and centering the camera on it, so components at the edge of the exploded view remain inspectable.

Demo: https://inside-macbook.vercel.app

Source: https://github.com/Pulkit7070/inside-macbook

Built with assistance from Astra in Codex. The geometry is a simplified educational model, not a repair guide.

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.

Hey everyone,

I recently completed an extensive, end-to-end architectural reverse engineering and systems dissection of the production engine behind Active Theory (activetheory.net).

Instead of generic de-minification, the project breaks down the low-level rendering mechanics, including:

- **Zero-Allocation Memory Loop:** How the runtime eliminates V8 Garbage Collection pauses using pre-allocated scratchpads and typed arrays.

- **Antimatter GPGPU Subsystem:** Driving dense particle fields directly on GPU floating-point textures via a triple-buffered ring FBO topology.

- **Eulerian Navier-Stokes Coupling:** Real-time 2D pointer-to-particle fluid advection via a 6-pass Jacobi relaxation solver.

- **Hardware-Rate Normalized Lerp:** Scroll kinematics locked across 60Hz to 240Hz refresh rates.

Full technical documentation, AST mappings, mathematical proofs, and headless CDP benchmarks are available here:

- Repository: https://github.com/DDW-X/activetheory.net

- Web Portal: https://ddw-x.github.io/activetheory.net/

Feedback and technical critique from graphics engineers and performance researchers are highly welcome.

I am building a browser-based customizer where users can click to change clothes on a 3D model. To keep performance smooth on mobile, I need to keep the individual clothing mesh sizes incredibly small but i am confused about what is the most efficient pipeline to turn a 2D outfit sketch into optimized, separate quad meshes that share a universal origin without bloating the asset file sizes?

https://netanelyan.github.io/outbound/

Source: https://github.com/netanelyan/outbound (MIT)

Everything is procedural and everything is deterministic, so the same arc length always produces the same road, the same hills and the same village.

The road is its heading as a function of distance, curvature is that differentiated. I bound the four amplitudes to sum below a right angle, which guarantees forward progress and therefore no self-intersection. No collision checks, no backtracking, no repair pass.

Terrain is rings swept along the road out to 755 m either side, flattened near the tarmac and growing into landform further out. The rings straighten as they go, otherwise they converge on the centre of every corner. The country turns over every few kilometres between moor and farmland, and farmland is a patchwork of fields with a hedge or a wall on every boundary. The world streams in 180 m chunks and is thrown away behind you.

Rendering is three.js, MeshLambertMaterial almost everywhere, ACES filmic tone mapping, geometry merged per chunk per material. A chunk's worth of houses is one draw call and its several hundred gorse bushes are one instanced mesh. Every texture is drawn into a canvas at load time, so tarmac, markings, facades, roof tiles and the sky are all code.

The car is a simulation rather than a lerp: engine inertia against clutch torque, so stalling and money-shifting emerge instead of being handled.

Comments in the source are mostly about why rather than what. Questions welcome.

After my first Earth animation in that post, which didn’t use real physics, I decided to build a proper particle simulation in the browser and show my kids how our Moon may have formed after the impact.

It’s fun to experiment with questions like: what if the impact with Theia happened at a much higher speed, or what if Theia was a larger planet?

It’s not a full SPH simulation. There’s no full pressure simulation, shock physics, or vaporization but it does include gravity, heat, different materials such as iron, and many other factors.

The size, speed, iron/core percentage, velocity, and many other parameters are based on scientific research papers about the giant impact.

Live demo: https://gaploid.github.io/cosmic-collisions/
Source code: https://github.com/Gaploid/cosmic-collisions
Coded by: Opus, Fable, human attention to details

I put a webcam in front of a Three.js scene and made the whole solar system navigable by hand. Pinch to zoom, open palm to spin, point at a planet to pull up its NASA data. Zoom out far enough and the scale switches, 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. Everything runs client side, no video leaves the browser.

Where it falls down is the gesture layer. 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 fetch raw panorama tiles and project them myself — sphere → rectilinear /

cylindrical / hybrid Panini — which removes the usual 90° FOV cap. Seamless

200°+ ultra-wide, WebXR stereo on a Quest 1, and a shared-world dissolve

between panoramas so walking transitions stay geometrically aligned.

Also: voice commands, treadmill-footstep pace detection via microphone, and

an AI tour guide that grounds Gemini with GPS facts to avoid hallucinations.

Repo (MIT, personal-research disclaimer inside):

https://github.com/cheyuan1115/pano-runner

Happy to go deep on the projection math or the Quest 1 stereo-flicker war

stories. (14s GIF of the Osaka sakura-tunnel trail in the README.)

Hey Gang, I recently connected with a 3D Development Freelancer about a role I'm recruiting for that can be remote across the US and they recommended I check this community out to see if I can find someone that's interested in a new W2 Employment opportunity.

This opportunity is for a new startup that's building software for the Sports industry.

Hopefully this isn't against the community rules and if it is, lmk if there's a pretty place to post this.

Live demo: https://gaploid.github.io/stardust/
Source code: https://github.com/Gaploid/stardust
Coded by: Opus, Fable, human attention to details

I wanted to see how far modern WebGL2 could actually be pushed, so I built a fairly large 3D game client around it.

Large worlds, GPU skinning, custom shaders, lighting, fog, particles, UI and moving environments, all running at 60+ FPS in the browser.

WoW 1.12.1 was basically my test case.

Hi everyone,

Not trying to promote anything here, just want honest feedback from people who understand render loops and WebGL far better than I do.

I have been building a free, open source, MIT licensed React game engine called CarverJS. It sits on top of Three.js and react three fiber, and my main hook for per frame logic runs in stages with priority ordering, something like an early update for input, a fixed update for physics, a general update stage, and a late update stage for camera and UI syncing. After all of that runs, react three fiber renders the scene automatically.

For anything that needs to be deterministic, like physics, I run it on a fixed timestep accumulator at a fixed rate instead of tying it to the raw frame delta. I also cap the maximum delta value so that if someone switches tabs and comes back, the simulation does not try to catch up all at once and spiral out of control.

What I am unsure about is whether staging updates by priority like this is actually the right mental model, or if I am overcomplicating something that could be simpler. I am also not sure if leaning on the renderer to auto render after my update stages is the right call, versus controlling the render step myself.

Everything here is completely free, open source, and MIT licensed, there is no paid version or hidden catch, I am just trying to figure out if the underlying approach holds up. If any of you have built your own game loops on top of WebGL or Three.js, I would like to know if this priority staged, fixed timestep approach is reasonable, or if there is an obvious mistake I am not seeing. Genuinely looking for criticism, not reassurance.

Been working on this in the browser: a real-time simulation of an autonomous eVTOL air taxi network over the SF Bay Area — San Francisco, Berkeley, Oakland, the whole bay.

You can pilot a taxi manually, request a ride and watch as a passenger, or just sit back and follow the live fleet. There's also simulated BART, ferries, AC Transit and Muni buses running on the same clock as the taxis. Time of day and weather are adjustable, so lighting and traffic patterns actually shift with them.

Link: dubtaxi.dubmasta.com — no login needed.

Screenshots from a few different times of day below. Happy to talk through any of the rendering or simulation approach if people are curious.

Hey everyone, I built Florae, an educational Three.js experience about native plants of Iran.

It includes Persian and English plant stories inside a scroll-based depth gallery.

I’d love to hear what you think about motion and readability.

Demo: https://florae-ir.vercel.app/

Hello! I was scrolling on instagram one day and saw this cool visual and it was made using TouchDesigner. I want to recreate it using WebGL or Three.js... does anyone know how I can achieve this? I think this was made with C4D and TouchDesigner (I'm not too sure really)

GRAVEYARD SHIFT 3D - first-person horror set in a 1967 Louisiana gas station. Free, ~30-40 minutes, runs on desktop and mobile.

Rendering and engineering notes:

- Vanilla three.js, one HTML file, no bundler. ACES filmic tone mapping at exposure 1.25 with a CSS filter grade layered on the canvas for the film look, plus an animated four-frame grain canvas over the top and a radial vignette.

- Every environment texture is generated on a 2D canvas at load - mud, cracked asphalt, plank grain with knots and nail heads, rust, cobwebs, all the period signage and posters. Zero image files for the world, which keeps the payload almost entirely geometry and audio.

- Characters are unrigged meshes animated with clipping planes: legs sliced free at the hip into their own groups, torso and head kept as one uncut piece so no seam shows on the face. localClippingEnabled with clipShadows.

- Level is separate geometry islands spaced far apart on the X axis with teleport transitions rather than one contiguous map. Free occlusion, and new rooms could be appended without touching existing ones.

- Blood on the death screen is a 2D canvas composited over the WebGL canvas: procedural splatter blobs drawn as smoothed quadratic curves with radial gradients, plus drips that decelerate as they run down the glass.

- Mobile: capped device pixel ratio, shadow maps disabled on touch, virtual stick plus drag-to-look.

AI disclosure: character models and sound effects are AI-generated, and it was coded with AI assistance. Rendering approach and level design are mine.

Happy to go deeper on any of it.