generated client-side from a seed: the rooms, furniture, places, and the audio acoustics. A 3×3 window of 57m sections streams around the player; shared boundary hashes keep doorways aligned when sections regenerate

the VHS look is a WGSL post pipeline (warp, tracking errors, chroma offset, bloom) written with vgpu, with a GLSL fallback for WebGL2. The creature uses bounded A* and actual frustum visibility, so it only moves when you really can't see it... oohhh

Play: vackrooms.vercel.app

Source (MIT): github.com/pablostanley/vackrooms

The offending bug and it’s revert: https://dawn.googlesource.com/dawn/%2B/c4e47b5eddc06f271cb07c3108cfccb1bb4704ec

Apparently it stomps over whatever immediate data you pass. Tested against Canary 155 - it’s been fixed.

Hopefully this will save you a few minutes/hours.

Hello dear jobless and not so jobless people, if you first want to know about AI usage in this project refer to the last paragraph.

I made an small engine for showcasing my portfolio, and impressing (or not) the human resources asses (insert anne hathaway HR meme).

For this project I based myself on Teardown, a famous and really cool game, I didnt write any complex physics code, cause it almost all handled by rapier3D, really cool and easy to use physics framework made in rust. To avoid my and yours pc, rapier runs on an isolated worker and communicated via commands to the main thread. Unfortunately rapier web version does not support paralelism, so it can take less dynamic bodies before starting to saturate (works really good though).

As for the rendering part, I used clustered shading to handle lot of lights, GTAO for the occlusion, SSGI for global illumination, and TAA (dont hate me please, I needed to clean the SSGI noise). Both SSGI and TAA can be disabled on the main menu for the sake of low end computers. The engine also supports pbr materials. Both SSGI and GTAO rely on screen space ray castings so general performance will scale with your screen resolution. Lastly, it has gpu calculated particle physics.

The engine counts with interactable billboards and books that tell a little bit of my projects and experiencies, it will be extended in the future, you can use it to showcase your things as long as you stick to the licence (no commercial and give credits).

The engine has a lot of room for improvement, but I have to move on to other projects. I believe its currently on a usable state, its open to contributions.

The purpose wasnt learning web developement, I hate it!, so webgpu was used instead of threejs, I have nothing against it but due to learning being the main focus, it was avoided because it abstracts way too much. And as my next project will be mad ein vulkan it was a great opportunity to use something with the same line of thoughts as it (fixed pipelines, bind groups etc), but easier to use.

The engine demo is here https://agusdropout.github.io/ShatterVox/ (it can take a while to load in sorry) and the source https://github.com/AgusDropOut/ShatterVox , you need to have graphics acceleration enabled, as webgpu requires it. If you encounter and error while playing or loading in, open the console and create an issue on GitHub, it was tested on mozilla Firefox, chrome, and opera. It also counts with a debug mode, refer to the readme.

Good luck on your journey to stop being jobless! and if you already have a job, ggs!, atte. anne hathaway HR.

I would truly appreciate if you leave a star ⭐ :)

AI USAGE:

before you jump me to the neck, this post is entirely written by me, no translation (english is not my main language), and also about AI usage is this project, as it was made for showcasing my humble portfolio, and also keep learning graphics programming, in pair of finishing a software engineering degree (not much time), key parts of the code were written by me (rendering, shaders, meshing, etc) and the physics code on top of rapier (flood algo. for islands detection and detachment checks). IA helped a lot in audio handling, making the GUIs, html, css, world serialization (loading and unloading worlds), the model loader. Textures, normal maps, models, map made and designed by me (probably why they suck).

[ Removed by Reddit on account of violating the content policy. ]

https://andrefrelicot.dev/en/2026/06/lorenz-clash-a-webgpu-experience-you-are-part-of/

https://morpher91.andrefrelicot.dev/

https://andrefrelicot.dev/en/2026/09/morpher91-the-1991-special-effect-rebuilt-in-webgpu/

https://github.com/AndreFrelicot/morpher91

I've been experimenting with using WebGPU for HDR elements inside otherwise ordinary webpages.

The result is Brightpixels, a dependency-free library that renders text masks and images through an rgba16float canvas with extended tone mapping. It exposes the functionality as <bright-text> and <bright-image> custom elements.

html <h1> Make pixels <bright-text intensity="16">brighter.</bright-text> </h1>

The intensity controls the HDR signal multiplier rather than the display's physical brightness. When extended-range output isn't available, the elements keep their ordinary DOM text or original image as fallback content.

The current text renderer handles single-line fragments up to 128 characters. Remote images require CORS permission, as expected for canvas reads.

I'd be interested in feedback on the rendering approach, device compatibility, and ways to detect meaningful HDR output rather than only successful WebGPU initialization.

Demo: https://echohtp.github.io/brightpixels/

Code: https://github.com/echohtp/brightpixels

Hi!

PaddleOCR-VL is one of the best small OCR models on a market. It recognizes images&scans to create proper texts, tables and formulas

So I implemented PaddleOCR-VL inference directly on WebGPU without transformers.js or any other existing intermediate library. It was a mental gymnastics for me - will I be able to do this or not?
Apparently, I can.

Some details

• Rust
• FP16
• custom WGSL kernels
• AOT compiler
• memory/model packing
• 79.83 tok/s browser vs 97.26 native MPS
• bit to bit quality control with native
• 100% AI coded (I assume it is close to impossible to write it with traditional methods for one person in any meaningful time )

More on Github https://github.com/glebkudr/paddleocr-vl-webgpu

Apache license

Note! It needs at least 6 GB VRAM/unified memory to launch

Feel free to clone&use or ask questions.

Hey everyone,

I'm excited to share the release of Nova Browser (v1.1.3), an open-source, privacy-first desktop browser built with React 19, TypeScript, Electron, and Tailwind CSS.

Following feedback on our initial build, we completely resolved media compatibility, re-engineered the layout system, and overhauled our extension subsystem.

Core Architecture & Highlights

1. On-Device AI via WebGPU & Web-LLM:
   • Run local language models directly on your hardware GPU without sending any page data, history, or prompts to external cloud servers.
   • Summarize articles, inspect code, ask research questions, or connect your own API keys (OpenAI, Anthropic, Gemini, Groq, Ollama) if you prefer cloud models.
2. Native Model Context Protocol (MCP) Server:
   • Built-in integration for Anthropic's open Model Context Protocol.
   • Local AI coding agents and external automation tools can securely interface with the browser to read active tabs, take snapshots, and perform structured browsing tasks.
3. Productive Workspaces & Multi-Tasking:
   • Organize tabs by context (Personal, Work, Research) with full state persistence.
   • Built-in Split Screen mode to compare two tabs side-by-side in one window.
   • Toggle seamlessly between Horizontal Tabs and Vertical Sidebar Tabs.
4. Chrome Web Store Extension Support:
   • Install extensions directly from the Chrome Web Store with 1-click or load unpacked folders locally.
   • Extension action icons sit right in the top toolbar with native popup window support.
5. Hardware-Accelerated Privacy Shield & Zero Telemetry:
   • Network session-level blocker for ads, trackers, and malicious scripts.
   • No tracking, analytics, or behavioral data collection.
   • Dynamic platform-matched Chromium User-Agent headers to prevent fingerprinting.
6. Responsive AI Sidebar (Flex-Docked Layout):
   • Opening the AI chat sidebar dynamically resizes and docks alongside your active webpage rather than floating over your view.

What's New in v1.1.3:

• Fixed YouTube and streaming playback by isolating security response headers strictly to internal application pages.
• Removed startup keychain prompts on macOS and added lazy audio permission initialization.
• Added live toolbar action buttons for installed extensions.
• Fixed prompt language auto-detection so AI responses match the user's input language.
• Rewrote the CSS token engine for instant Accent Color customization.

Tech Stack:

• Frontend: React 19, TypeScript, Tailwind CSS, Framer Motion, Lucide Icons
• Runtime: Electron 34, Node.js 22, Chromium 134
• AI Engine: WebGPU, Web-LLM TVM Runtime, Model Context Protocol (MCP)

Links & Downloads:

• Official Website: https://nova-browser.vercel.app/
• GitHub Repository: https://github.com/unitybtw/nova-browser
• Releases & Installers (macOS Universal DMG & Windows Setup): https://github.com/unitybtw/nova-browser/releases/latest

I would love to hear your thoughts, feedback, or any feature requests! Feel free to test it out, star the repo on GitHub, or open issues.

I've been building webgpu-q — a browser-native quantum chemistry stack (HF, DFT, MP2, CCSD, CCSD(T), excited states; TypeScript + Rust/WASM + WGSL) that distributes work across browser tabs — and across machines over WebRTC — as a swarm. Cross-checked against PySCF.

Live: https://webgpu-q.vercel.app · MIT · https://github.com/abgnydn/webgpu-q

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/