r/webgpu

I've fully redone the engine for my game AresRPG, I aim for an immersive world! this is a browser based MMORPG on Sui

Paper Shaders (the WebGL shader library from paper.design, 1.7M npm downloads/month) dropped their restrictive license this week — it's now plain Apache-2.0, do whatever you like.

I'd been porting them to Vue 3 for nxui, so with the license cleared: all 29 shaders are now available as copy-paste Vue components — mesh gradient, liquid metal, god rays, dithering, metaballs, neuro noise, etc. Typed props, live playgrounds, installable via the shadcn-vue CLI. Works with Nuxt 4 out of the box (SSR-safe mounts).

Demos: https://nxui.geoql.in/docs/paper-shaders/paper-mesh-gradient

Repo (MIT, 210+ components total): https://github.com/vinayakkulkarni/nxui

Feedback welcome — especially on the WebGL/SSR handling.

I ported Apple’s SHARP model to ONNX and now works in the browser with WebGPU.

No install required, the weights download to your browser and you can start using it immediately

Happy Splatting!

⭐ Demo: https://sharp-onnx-webgpu.vercel.app/

⭐ Code: https://github.com/pristinaai/Sharp-Onnx-webgpu/tree/main

⭐ Weights: https://huggingface.co/sentiantai/sharp-onnx-webgpu-weights/tree/main

Hey Reddit!

I’ve been working on charton, a general-purpose visualization library for the web. In my previous iteration, I got basic interactive sine waves running via the GPU, but the architecture was still hurting from heavy heap allocations. After refactoring the JS/WASM boundary into a stateful, zero-allocation setup, I finally managed to render a 50,000-point Lorenz Attractor dynamically at a locked 60 FPS using WGPU.

Here is a quick look at how the data updates are handled now:

src/lib.rs:

pub async fn update_and_render(&mut self, xs: &[f64], ys: &[f64], colors: &[f64]) -> Result<(), JsValue> {
    self.dataset.update_column_f64("x", xs)?; // In-place memcpy without allocation
    Chart::build(self.dataset.clone())?.mark_point().render_to_canvas(&self.canvas_id).await?
}

index.html:

const app = new LiveChartApp("chart-canvas", TOTAL_POINTS);
// Inside the requestAnimationFrame loop:
await app.update_and_render(xs, ys, colors);

I'm currently stress-testing this on a budget laptop setup: a 13th Gen Intel Core i5-13420H (2.10 GHz) with integrated Intel UHD Graphics (128 MB). My GPU utilization hovers around 70%, but because WASM runs single-threaded here, one CPU core is completely maxed out feeding the render pipeline. Since charton is meant to be a general-purpose visualization library, I can't rely on equation-specific math hacks. Do you have any recommendations for generic data-streaming patterns or memory layouts across the WASM boundary to relieve the CPU?

Moving forward, I'm planning to use this engine to create equation-driven short videos and data art animations. I’d love to hear your thoughts—what kind of interesting use cases, large datasets, or simulation scenarios would you love to see a high-performance library like this tackle next?

Really pushing the limits of my GPU.

Fan of flight of the navigator but reproducing the ship painful.

Persistent sessions

WASM Extension API

Cloud, SFTP/FTP and SMB

Tags, Fuzzy search and filter

Miller colums

Open ZIPs as folders

Back in August 2011, Evan Wallace (who later co-founded Figma and wrote esbuild) released WebGL Water - the raytraced pool with real-time caustics that pretty much every web-graphics enthusiast remembers. ~15 years on, I figured it deserved a WebGPU version, so I ported the whole thing.

Live demo (WebGPU, falls back to WebGL2): https://willeastcott.github.io/webgpu-water-playcanvas/

Source: https://github.com/willeastcott/webgpu-water-playcanvas

The 2011 original: https://madebyevan.com/webgl-water/

The bit that's interesting for this sub: rather than transpiling GLSL → WGSL at runtime, every shader is authored in both languages side by side (LLMs are great and managing both versions and keeping them in sync). On WebGPU it runs native WGSL - no transpiler, no WASM - and still falls back to WebGL2 with the original GLSL.

It's a faithful port of the original rendering + sim:

• GPU heightfield water sim on ping-pong float render targets (RGBA32F, half-float fallback)
• Real-time caustics via the differential-area method (the projected-mesh trick from Evan's writeup)
• Raytraced reflection + refraction off the pool and a draggable, buoyant sphere
• Analytic ambient occlusion, soft blob shadow, sky cubemap
• Built on the PlayCanvas engine (just the npm package - standalone Vite app)

I also added scroll-to-zoom and made click-drag paint a continuous ripple trail instead of a row of separate drops.

Disclosure: I work on PlayCanvas. This is just a fun open-source port, though - all the original genius is Evan's.

PlayCanvas is a free, open-source (MIT) real-time 3D engine that runs in the browser on both WebGL2 and WebGPU. We just shipped 2.20 — here's what's new.

Gaussian Splatting (the big one this release):

• Real-time relighting of splats
• Soft shadows
• Depth of field
• Clipping planes
• Billions of splats via streaming + LOD
• Shader effects (dissolve, rings)
• Gaussian Splatting in VR (with LOD)

WebXR on WebGPU 👇
WebXR (VR/AR) now runs on the WebGPU backend — not just WebGL2. So you can build immersive experiences on the modern graphics API, including the new Gaussian Splatting features in VR. That combo is still pretty rare in the wild — most WebXR today is WebGL-only.

Also new:

• Procedural sky
• Clustered light cookies
• Physics: joints + ragdolls
• Draco mesh decoding in Node (via worker_threads)

Links:

• Release notes: https://github.com/playcanvas/engine/releases/tag/v2.20.0
• Try every example live in your browser: https://playcanvas.com/examples
• Repo: https://github.com/playcanvas/engine
• npm install playcanvas

Quick montage of the new examples attached — happy to answer anything about what we're releasing today!

I've been experimenting with a compiler/runtime project that I'm not entirely sure is a good idea, so I'd love some feedback from people who've worked on deployment systems.

The idea is to compile an exported PyTorch model into a self-contained package that contains:

• graph
• binary weights
• backend kernels (currently WGSL)
• runtime metadata

A lightweight runtime loads that package and executes it directly in the browser with WebGPU. No Python, no server inference, and no dependency on a heavyweight runtime.

Right now the attached demos are just neural video representations because they were easy to test, but the motivation is actually operator networks and scientific ML, where I like the idea of distributing a single portable artifact.

The repo is here:
https://github.com/Slater-Victoroff/Kuma

I'm mostly looking for architectural feedback.

Some questions I'm wrestling with:

• Is embedding backend kernels in the artifact a terrible idea?
• Is this solving a real deployment problem or just reinventing ONNX Runtime?
• Are there existing systems I should study that take a similar approach?
• If you were designing a deployment format today, what would you change?

I'd especially appreciate thoughts from people who've worked on ONNX, IREE, TVM, ExecuTorch, MLIR, or similar compiler/runtime projects.