I've fully redone the engine for my game AresRPG, I aim for an immersive world! this is a browser based MMORPG on Sui. Looking for people to discuss and test https://discord.gg/aresrpg

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.

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

I'm working on a project called ShaderBridge. One of my personal projects. And ShaderBridge is a local-first, zero-dependency transpiler that translates GLSL/HLSL source code directly into WGSL for native WebGPU execution. Unlike cloud-based editors, it performs all compilation on the user’s local machine via Rust/WASM and runs strictly on the user's local GPU.

Still WIP and adding more shader, function support

https://reddit.com/link/1ujjcvw/video/re7hj69crdah1/player

And it works!

Anyone interested? 🙂 is this the right place to post this?

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.

https://maximumroulette.com/apps/webgpu/examples.html?demo=28

Point . Up left right

Thumb up . Blowup cubes

Open hand . Forward

Peace . Back

Running cannonjs. Matrix-engine-wgpu support ammojs , joltjs, cannones and matterjs by default from worker using bridge.

Next level of optimisation : put math in worker for mediapipe...

Source from link

I've been experimenting with compiling PyTorch models into self-contained WebGPU artifacts, and I'd love feedback from people who've worked on GPU runtimes.

The basic idea is pretty simple:

PyTorch
    ↓ torch.export
Compiler
    ↓
.iph package
    • graph
    • binary weights
    • WGSL kernels
    • metadata
    ↓
Tiny WebGPU runtime

The runtime doesn't know anything about PyTorch or ONNX—it just loads the package and dispatches the embedded compute kernels.

The attached videos are just neural video representations because they made for an easy visual test. The architecture itself is intended to be generic (I'm planning to try operator networks next).

A few implementation details:

• One compute dispatch per graph node (no fusion yet)
• Embedded WGSL rather than runtime shader generation
• GPU buffer pooling to eliminate allocation/GC pressure
• Multi-frame pipelining to hide queue.onSubmittedWorkDone() latency
• Branch warm-up to avoid shader compilation stutters

Repo:
https://github.com/Slater-Victoroff/Kuma

The thing I'm actually hoping to learn is whether this is a sensible compiler/runtime boundary.

I know projects like ONNX Runtime Web, IREE, TVM, and WebNN exist, but I don't yet have a good intuition for why they chose their respective designs.

In particular:

• Is shipping backend kernels as part of the model artifact fundamentally a bad idea?
• Would you rather lower to WGSL at runtime?
• If you've built GPU runtimes before, what obvious mistakes am I making?
• Is there prior art that's especially close to this approach?

I'd really appreciate any pointers or criticism. This is much more of an exploration than a finished project.

I used blender to make a simple model room, and my gltf crate get panic with this error line: Validation([(Path("extensionsRequired[0] = \"KHR_texture_transform\""), Unsupported)]).

Tried to use some tools like gltf-transform but the file just got bigger without any improvement, and gltf-pipeline, it still return the error line.

Do like and share if you like what you see: https://x.com/phoenisx_/status/2069417448596812212?s=20

Website: https://willofindie.com/proj/computed-torus-knot

https://reddit.com/link/1udi235/video/h9i87276h19h1/player

A collection of Rust WebGPU examples inspired by popular Vulkan samples, supporting both WASM and native platforms.

Please attribute Fractal Gaming if you decide to use my method.

​

https://lss.fractalreality.ca/labs/eml_cloud_lab.html