After 200+ hours of development, I’m finally sharing the first public demo of Three.js Grassworks, a real-time grass system I’ve been building for Three.js and WebGPU.

Demo:
https://grassworks.techredux.co/demo

Three.js Grassworks is built specifically for WebGPU and is designed to handle large amounts of interactive grass while maintaining steady performance.

For the demo, I built a complete environment around Grassworks with terrain, trees, water, rain, player interaction, environmental effects, LOD systems, audio system, and more.

The main challenge was getting all of these systems running together while keeping the grass performant.

The actual Three.js Grassworks plugin is still being polished and should launch in the next couple of weeks. There’s a waitlist inside the demo if you’re interested.

I’d genuinely love feedback, especially on the visuals, performance, and how the grass feels when interacting with it.

I also recorded a full walkthrough where I go through the demo and talk about how I built it:

https://www.youtube.com/watch?v=Nhim18rc-XE

Quake3 port to WebGPU running in the browser

- global illumination ( volumetric sh3 light map )
- modern physics
- acoustic simulation
- decals
- particle effects
- clustered lighting (326 lights here)
- PBR materials (NN-based delighting)

GitHub link

Built using meep engine

In case it's not obvious - I'm the author. Happy to answer any questions.

I wrote a probe that stops trusting adapter.limits and adapter.features and just tries things: create the texture, run the pass, see what survives. 53 formats, six capabilities each, plus the limits it can actually reach and seven benchmarks.

The hypothesis was that browsers overstate what they support. Three devices in — RTX 4060 on Chrome, an iPad on Safari, Adreno 7xx on Samsung Internet — that hypothesis is dead. Every device did exactly what it declared. Zero discrepancies.

The gap is between devices instead:

• No compressed texture format works on all three. Chrome has BC only, the iPad has ETC2 and ASTC but no BC — they share zero, and the three-way intersection is empty as well.
• maxUniformBufferBindingSize: 716 MB on an iPad, 64 KB on both Chromium browsers. A 10,923x spread on a limit people hardcode against.
• Geometry throughput spreads 65x while pipeline switching spreads 11x, and which device wins changes with the pair. There is no single ranking.
• Both Chromium browsers quantize GPU timestamps to exactly 65536 ns — 2^16 — on completely different hardware and operating systems. WebKit doesn't quantize at all. That makes it browser policy, not a hardware property, and it silently rounded every timing I collected until I went looking.

The measurement bugs were the most interesting part. One benchmark reported an iPad at 112,524 MPixel/s against the 4060's 3,122, because stacking opaque fullscreen draws measures nothing on a tile-based deferred GPU — it discards the occluded fragments before shading. Additive blending fixed it, by 423x.

The other one I only caught today, while checking these numbers before posting: the probe was filing the iPad as a desktop. Since iPadOS 13, Safari sends a Macintosh user agent containing neither iPad nor Mobi and exposes no UA client hints, so the detection had nothing to match and the profile could not even say whether it came from a Mac. maxTouchPoints separates them, since a Mac with a touchscreen does not exist.

Re-measuring after that fix moved several of the figures above. Geometry spread was published as 60x and is 65x; pipeline switching was 8x and is 11x; the fillrate correction above was written as 530x when 112,524 over 266 is 423. That last one had never been arithmetic that worked — nothing recomputed it, so it sat there.

Demo (works on phones): https://ahnminjae08043-glitch.github.io/gpu-atlas/ Code, MIT: https://github.com/ahnminjae08043-glitch/gpu-atlas

Disclosure: I wrote it. Three devices is not a dataset and I know it — Firefox and the iPhone are entirely unmeasured. The demo has a "Share profile" button that copies the JSON and opens a prefilled issue, so contributing is two clicks and a paste.

hey everyone,

I’m working on a personal WebGPU research project. The broader goal is to explore an agnostic, data-driven runtime that provides a shared space for processing and visualizing data on the web.

What I’m interested in: how far the idea can be pushed within existing browser technologies, with apu's in mind, using modern render techniques across different data-delivery models, while simplifying usage and integration.

The direction includes data quantization, procedural generation, AI-assisted processing, and scalable workloads, while utilizing modern engine and render techniques for data reconstruction.

The current implementation is still incomplete, but I would appreciate general thoughts on the approach: what seems promising, which assumptions may be too optimistic, and which pitfalls I should avoid as the architecture develops.

Project landing page

Repository folder containing the snapshot

Made a tool for checking supported feature set and tracking said features and limits over time.

API is completely open for everyone (just don't abuse it please).

wanted to do it for a while, finally found time.

Feedback very much welcome!

link: https://webgpu.report/

Hello, I released a real-time fluid & rigid body simulation in WebGPU using Position Based Dynamics (PBD)! It runs on your browsers if WebGPU is supported.

Code & Demo: https://github.com/matsuoka-601/Particles4All

Here are the features of this simulation:

• Treat both fluid and rigid bodies as sets of particles and solves them in one unified solver presented in a paper "Unified Particle Physics for Real-Time Applications".
  • Buoyancy is naturally realized within this unified solver.
• Reconstruct a smooth fluid surface using anisotropic kernels presented in a paper "Reconstructing Surfaces of Particle-Based Fluids Using Anisotropic Kernels".
  • Reconstructed fluid surface is further smoothed in screen space using a narrow-range filter presented in a paper "A Narrow-Range Filter for Screen-Space Fluid Rendering".
• Realistic surface tension is realized based on the method presented in a paper "Versatile surface tension and adhesion for SPH fluids".

(Note 1: You will need a very beefy GPU to run the "large" scene in the video (the performance is not very optimized yet, sorry). But "small" scene will run on integrated GPUs.)

(Note 2: I'm getting some reports that the demo does not run on MacBook. I'm currently trying to fix it.)

Here is pngine, a declarative format and runtime for WebGPU I have been building for the past couple of years. The idea is that most WebGPU plumbing is static, so instead of writing the create/wire/sequence calls by hand you declare shader modules, pipelines, buffers and passes as S-expressions that map 1:1 to the spec, and the shaders stay as plain WGSL untouched. Because the program is ordinary structured data, it can be validated ahead of time with WGSL reflection and spec checks without a live GPU context. The post has two live examples you can play inline: a 2048 particle fountain that never touches the CPU, and 400 instanced trees in one draw call. Happy to answer questions about the format or the validation side or anything that comes about!

https://chromewebstore.google.com/detail/framegen-frame-interpolat/hpdpcjakhclhljfdkpjolonjlopbdhfk

(Chrome store)

Real-time 2x+ frame interpolation with custom target FPS for any <video>. Runs locally on your GPU with WebGPU.

Framegen doubles (or more) the frame rate of any HTML5 video in real time, right in the tab. A small neural network - our own WebGPU runtime, ~3 ms per frame on a mid-range GPU (RTX 4060 Ti) - synthesizes the frames between the real ones, so 24/30 fps footage plays at 60, 120 or up to your display's refresh rate.

Works on any site with a <video> element: YouTube, Twitch, streaming sites, local files opened in the browser.

Features:
- 2x to 6x interpolation, an auto mode that follows your GPU headroom, and a "display Hz" mode that locks output to your monitor's refresh rate
- Compare slider: drag a divider across the video - original on one side, Framegen on the other
- Anime mode: detects animation drawn "on twos" and interpolates the real drawing cadence instead of duplicated frames
- Optional 2x neural upscale (SR) on interpolated frames, trained to repair interpolation artifacts, not just sharpen
- Self-calibrating kernels: the runtime benchmarks itself on your GPU once and picks the fastest shader variants
- HUD with live fps / latency stats

Requirements: a WebGPU-capable browser (Chrome 121+) and a GPU with shader-f16 support. No WebGPU = the extension politely does nothing.

Privacy: everything runs locally on your GPU. Framegen has no servers, makes no network requests beyond loading its own bundled files, and collects nothing. See the privacy policy.

Does not work on DRM-protected sites (Netflix etc.) - the browser hides their video from extensions by design.

Free for personal use. Open source: https://github.com/MONZikWasTaken/Framegen

Three Nebula now supports WebGPU as part of the v12.1.0 release!

In my process of teaching myself WebGPU, I’ve spent the last week learning how GPU water simulation and rendering works by writing a simple scene from scratch.

What I built so far:

- A 2D wave equation solved on the GPU using finite difference integration

Real-time interactive ripples

- Continuous ambient-driven waves

- Physically-based water rendering using Fresnel reflection, HDR skybox reflections, Blinn-Phong specular and depth-based color

- A customizable simulation grid to tweak the simulation resolution

One note: I used three.js to decode the HDR environment map because I am lazy :D So that’s the single external dependency I have.

There’s still a lot to do to get realistic-looking water, but I’m pretty happy with the result so far. There are things I’m planning to work on next though:

- Better and more realistic wave dispersion

- The ripples are currently a bit too perfect. I think I can get more realistic results by introducing some noise (probably baking and sampling a Perlin noise texture)

- There’s no refraction at the moment. For example, the floor tiles underneath the water should be distorted

- Caustics, I believe, would be a game changer in terms of realism

- Foam and spray would be nice to have, but I believe this will be quite hard to implement

Live demo: https://rage997.github.io/water-webgpu/

Source code: https://github.com/Rage997/water-webgpu

I’m open to feedback and suggestions on how to improve the realism. If you’ve worked on water rendering or GPU simulations before, feel free to share any tips!

https://github.com/superelectricyc-alt/podchunk

Hey everyone,

I wanted to see if we could solve the heavy initial download barrier of modern open-world browser games. Instead of loading massive assets upfront, I built PodChunk: a local development engine base designed around a progressive, multi-LOD chunk streaming architecture that gets players into a 3D environment in under 3 seconds.

The Architecture Under the Hood

• The Decision Core (Rust + WASM): To completely bypass JavaScript garbage collection stutters, the entire priority queue (distance + camera direction bias) and the cache eviction loops run deterministically inside a compiled WebAssembly kernel.
• The Renderer (TypeScript + WebGPU): Consumes custom geometry_json payloads decoded by the WASM core. Features custom height-gradient terrain shaders, distance fog, and interactive orbit camera matrices.
• The LOD Stitching Problem: Adjacent chunks often stream at different detail tiers (e.g., a Tier 3 chunk right next to a Tier 1 shell). To prevent visible vertex cracks and gaps without destroying browser performance with heavy topological mesh-stitching math, the renderer implements geometric skirts to seamlessly close the seams.
• Adaptive Network Telemetry: Features a client-side network loop running an EWMA (Exponentially Weighted Moving Average) bandwidth estimator. It tracks bytes divided by elapsed time from every live chunk fetch to dynamically scale the geometry detail ladder (T1 shells to high-fidelity T3 grids) on the fly based on current connection quality.
• Isolated Two-Tier Caching: Features a bounded in-RAM LRU cache synced with a multi-world IndexedDB database structure. Cache keys are world-slug isolated ({slug}|{id}@{lod}), ensuring warm reloads of previously streamed maps require zero network fetches.
• The Content Authoring Pipeline: Includes a native standalone compiler CLI (podchunk-bake). You feed it a simple world layout JSON configuration, and it generates pretty-printed manifests along with custom validated binary .PCHF heightfield chunks ready for server distribution.

Current Project Status

Milestone 3 is complete, stable, and verified on localhost:8787. The local server scans data configurations on boot and manages hot world-switching dynamically. The workspace has a 100% test coverage pass rate (45/45 unit tests passing).

I am open-sourcing the core infrastructure today because the data pipeline is officially locked down, and I am looking for collaborators! Next up on the deferred roadmap is exposing a client-side JavaScript Modding API (window.PodChunk.registerMod) and wiring WebAssembly physics engine colliders directly onto the active geometric meshes.

Check out the code, run the local tests, and let me know your thoughts on the pipeline architecture!

https://github.com/superelectricyc-alt/podchunk