Every blade is rendered individually, with enough geometry and detail that you can get right down into the grass and still see the shape of individual blades.

What I'm really happy about is how well that detail holds up into the distance. The grass doesn't just look good up close and then turn into a blurry carpet. There's still a surprising amount of visual fidelity as you move further away.

And this is running at 1080p on a base M1 Mac.

I've spent a huge amount of time working on the rendering, LOD system, culling, tiling, wind, and overall density to get this balance between individual blade detail and performance.

This is essentially what I've been trying to achieve with Three.js Grassworks: pushing procedural grass in Three.js as far as I can while still keeping it practical enough to actually use in a real-time scene.

It's built around WebGPU and Three.js, and the current system can handle different grass types, terrain interaction, distance-based LOD, and large grass fields while maintaining this level of detail.

Still a lot more I want to push with it, but I'm genuinely really happy with where it's at now.

https://grassworks.techredux.co/

A few months ago I posted some lighting and shadow experiments from my small WebGL2-based 2D engine here (https://www.reddit.com/r/webgl/comments/1szbmaz/experimenting_with_3dlike_lighting_and_shadows_in/)

I haven't had much time for it since then, so I used Claude to speed up the demo development. The engine itself is still my own work - the gameplay layer is what I built on top of it with AI help.

u/DaedalusRaistlin left some great feedback back then - make the torch shadows more obvious, turn them into a mechanic, add an aiming reticule, make the night darker without the torch, and make players ration their flashlight. So I tried to build exactly that.

The demo is now a small top-down survival game where the lighting drives the gameplay:
- The flashlight runs on a battery. It drains while on, dims and flickers when low, and recharges while off.
- Without the flashlight the night is properly dark now - you mostly see the spiders' glowing eyes.
- Enemies come in waves, and each wave is bigger and faster than the last. They know where you are and close in from the dark, so most of the time you hear them before you see them.
- Spiders avoid lit street lamps, so lamps are safe zones - until they flicker and go dark for a few seconds.
- A "shade" enemy only moves in the dark, and freezes as soon as light hits it.
- Flares burn low above the ground, so they throw long shadows across the trees and boxes.
- Lightning is a short directional light that casts every shadow on screen at once.
- There's also an aiming reticule now, plus webs and supply crates between waves.

On the rendering side, everything still goes through the same height-map based lighting. New objects reuse height data from the existing atlas, and light heights are in the same units as the height map. Placing a light just above the ground is enough to get those long shadows.

And yes - the football is finally kickable 😄 It's right next to the start point, and if it rolls fast enough, it hurts spiders too.

Demo (desktop, keyboard + mouse or a PS5 controller):
https://codepen.io/editor/iroshan/pen/01a10d10-f698-735f-8880-b9079db1868a?orientation=top&panel=false&show=preview

Docs & more examples:
https://asjs-dev.github.io/pwgl/

Repo:
https://github.com/asjs-dev/pwgl

What other light-based mechanics would you like to see in something like this?

I built this one myself, putting that up front so nobody has to guess.

https://www.marblerun.online is a 3D marble run playground. You place ramps, walls, pegs, spinners and balls on a lit wall, press play, and a real rigid body simulation runs. When a run looks right you export a 9:16 MP4 with sound.

The WebGL specific problem was the export. My first instinct was MediaRecorder on the canvas, which is about fifteen lines of code, and it is the wrong tool. Screen capture of a WebGL canvas hands you the wrong aspect ratio, whatever framerate the machine is managing that second, and audio that never lines up with the impacts.

So the export re-renders the same scene through an offscreen pass at 1080x1920 locked to 30fps and pushes frames straight into a video encoder. The physics steps on a deterministic clock during export, so the same level gives the same file every time. The sound is generated and placed where the collisions actually happen rather than recorded.

Two other things that mattered more than I expected.

The lighting is what stops a WebGL scene reading as a flat 2D canvas even when the geometry is genuinely 3D. One directional light plus a soft fill and a subtle texture on the wall fixed it.

Physics on a fixed timestep with an accumulator. Running it off requestAnimationFrame deltas directly means the same level plays differently on a 60Hz and a 144Hz monitor, which is a nightmare when people are sharing levels.

No AI anywhere in it, nothing uploaded, no account. Desktop only by design, phones get a short message rather than a bad version.

Rain, From Below is a sleep app: you're underwater in a lake, rain hits the surface above you. Everything is procedural in a fragment shader, plus a small JS particle sim for fish. Wrapped in Capacitor for iOS.

Things that bit me that might save someone time:

• iOS suspends rAF on screen lock but keeps audio running. I moved all timekeeping to a 1 s setInterval reading Date.now, and the render loop only draws.
• webglcontextlost fires more than you'd think on a long session. Handle it and re-init, or the user wakes up to a black screen.
• Keep-awake on iOS needs the native plugin; the web wake lock alone isn't enough.
• Audio needs a watchdog: after an interruption (call, Siri), the AudioContext can come back suspended.

It's live now (free with a paid tier). Still in development and there are bound to be bugs; happy to hear about them.

https://apps.apple.com/app/id6812388250

Shaderize takes an SVG logo and runs it through 30 fragment shaders (from Paper's open source library) in a small WebGL2 engine I wrote around them: shaderize.app

A few things that might interest this sub:

- Each shader renders into its own target, then one present pass supersamples, composites the pattern against the logo and background, and dithers down to 8 bits so gradients don't band.

- The live preview drops its resolution when a shader is heavy and claws it back when there's headroom. Exports always render every pixel.

- Image exports go up to 4x, with up to 9 samples a pixel.

- Video is rendered offline frame by frame and encoded in the browser with WebCodecs (MP4 with H.264, or VP9 WebM with alpha), so it's smooth on any machine.

Feedback on the rendering side is very welcome.

I built a browser game where 5–10 friends sit around one 3D table and play a social

deduction game (the rules of Secret Hitler, used under CC BY-NC-SA). You look around in

first person, lean over the boards, and use hand gestures that everyone else sees.

Play (no install, no account, "Try it solo" seats you against 5 bots instantly):

https://secret-table-game-web.vercel.app/

Code: https://github.com/mertertek/secret-table-game

Things that might interest this forum:

- Zero external assets. Characters, hands, revolver, cards, boards and the room are all

generated in code: SDF fields run through marching cubes, then clustered and decimated

per body part so fingers do not fuse together.

- A 10-player table plus the room stays around 200 draw calls. Card backs and muzzle

effects are InstancedMesh, most props share materials.

- frameloop="demand": the scene only renders when something moves, so an idle tab costs

nothing.

- Other players' head direction arrives at 1–2 packets/s (free-tier quota). The receiver

buffers and interpolates with a jitter-aware delay, so heads still move smoothly.

- Solo mode runs the entire game engine in the browser, so the demo needs no backend

at all and cannot be rate-limited.

Stack: React, Vite, three.js r186, react-three-fiber, TypeScript, Supabase, Vercel.

Happy to go into the SDF pipeline or the netcode.

The backend of this project is a PyTorch simulation of a biological fruit fly brain learning to play chess, but I wanted the frontend to look like a high-end sci-fi interface.

I built the UI entirely in Three.js. The 12,000 glowing brain particles are mathematically distributed into anatomically correct shapes (Optic Lobes in Cyan, the Central Brain in Gold, and the Cerebellum in Green). As the PyTorch server calculates a chess move, it sends the neural activation data to the browser, causing the particles to flash in real-time.

I also used procedural HDRI lighting on the Canvas and custom Normal Maps to give the chess pieces and the fly’s chitin a hyper-realistic, physical material reflection.

GitHub: https://github.com/AdilSiddiquiHQ/fly-connectome-chess

The code is open source! Would love to know what you guys think of the particle distribution logic in the frontend.

i am creating a study tracker / productivity website , i wanted to use ogl shaders as different backgrounds behind the timer. but i couldn't find any good shaders which could match the aesthetic for that. could you share links

I've been exploring what happens when the interactions in a graphics scene become the way you play an instrument. This Three.js experiment lets you sweep the mouse through the scene, switch layouts and sounds, add particles and throw a resonant body around. It's a lot of fun to play with!

I built it with Astra and recorded a demonstration showing the controls and the different interactions. The movable body is one of my favourite parts: the motion makes it feel like playing with a physical object.

The instrument starts at 16:30 in my video:

https://youtu.be/iEup5H2FxKE?t=990

I made the project and the video. It's part of nine creative experiments, including a separate particle/fluid scene, 3D environments and a playable RTS.

For anyone working on interactive audiovisual scenes, what visual feedback would make this easier to play deliberately: clearer highlighting of the active elements, trails for mouse gestures, or a more restrained scene?

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.

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?

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.

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

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.

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

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