I built a CO laser game in the browser, with WebGPU and ASMR

KYU LEE — Tue, 20 Oct 2026 00:47:00 +0000

One tiny mole. A steady hand. A surprisingly difficult game.

I’m building CO₂ Laser Practice, a browser game about removing virtual moles while preserving the surrounding skin. It grew out of experience with dermatology and cosmetic laser procedures—and a fascination with the quiet concentration of working on one small spot.

Play CO₂ Laser Practice in your desktop browser →

Actual gameplay. Small movements make a difference.

A small task with room to get better

The basic action is simple: aim, fire, and watch the surface change. The challenge is deciding when to stop, where to move next, and how to finish without removing too much healthy tissue.

Different lesion shapes, sizes, and depths give you different problems to solve. Practice mode lets you try another approach on the same patient. Clinic mode gives that practice a longer arc: meet new patients, improve your results, and build your clinic’s standard fee.

The tools are also the soundtrack

I wanted the sound to support concentration. Air suction provides a steady background, while the laser has a softer electronic trill. Gauze adds subtle fabric contact, and the adjustable lamp has moving-joint sounds.

Each tool responds to what you do. The aim is an ASMR-like atmosphere where you can hear the work, rather than a loud effect repeating over every action.

Another treatment area, with the same focus on careful control.

Watch a short clip

Turn the sound on for a quick look at the game’s pace and atmosphere.

Watch the Short on YouTube →

A few things under the hood

Rust + WebAssembly: the simulation runs in the browser.
wgpu / WebGPU: interactive 3D skin, lesions, and changing treatment surfaces.
Web Audio: separate, responsive sound layers for the four tools.
PWA: play without installing, with optional installation and progress saved on the device.

One of the trickier parts has been balancing detailed surface feedback with a game that feels fair and responsive. Recent work has focused on clearer skin and lesion structure, smoother material boundaries, and handling GPU delays without letting a held laser keep working behind a stale frame.

Try it and tell me how it feels

Use a desktop PC with a mouse and keyboard. A current Chrome or Edge browser with graphics acceleration is recommended.

Hold the left mouse button to aim; use Spacebar to fire.
Use the mouse wheel to zoom and the right mouse button to move the view.
Press H for the full controls.

Open the game → · About the game

I’d especially like feedback on the tool controls, sound balance, and whether each patient makes you want to try a cleaner finish. Which would you focus on first: precision, speed, or the sound?

CO₂ Laser Practice is a game inspired by clinical experience. It is not a medical device or a substitute for clinical training.

I Put My Laptop's Idle NPU to Work with Fan-Aware Soundscapes in Rust

KYU LEE — Tue, 20 Oct 2026 00:46:46 +0000

My Intel Core Ultra 7 laptop has an NPU, but in my everyday work it rarely had anything to do. Leaving it idle felt wasteful, so I started looking for a useful local experiment.

That became Fan Composer: a small, open-source Windows app that listens to laptop fan noise and adds a quiet soundscape around it.

The question is simple: could a steady fan sound feel less annoying if it became part of a musical background?

This is not active noise cancellation. It adds sound; it does not remove the fan noise or lower its sound pressure.

Three ways to listen

Harmonic: a continuous drone and overtones guided by a stable fan pitch estimate.
Nature: synthesized wind and wave-like textures, without recorded nature samples.
Generative: a seeded musical motif with an ambient background and slow changes.

All three are synthesized locally. There are no cloud music APIs or downloaded music samples.

A short sound preview

Watch or download the 45-second sound preview.

Open the preview video (MP4)

0:00 Harmonic · 0:15 Nature · 0:30 Generative. These are offline renders from the actual Rust synthesis engine, paired with a static screenshot of the stopped app. Preview gain is raised by about 12 dB for audibility. This is not a recording of live microphone analysis or NPU inference.

Automatic volume is the core feature

You set a maximum volume, and the app gradually adjusts playback as the estimated fan/background level changes. Automatic volume is always on; there is no extra switch to manage.

There is a catch: the microphone can also hear the app's own sound. Simply following microphone loudness could make playback chase itself. Fan Composer uses its output signal as a spectral reference and holds or reduces amplification when the estimate is uncertain.

This remains an experimental background estimate. Other steady sounds and room changes can affect it; it is not an acoustic echo canceller or a reliable fan-versus-speech classifier.

What the NPU actually does

The NPU runs a small music-policy model through OpenVINO, once per second. It adjusts parameters such as brightness, note density, motion, and reverb. Rust on the CPU handles FFT analysis, volume control, and audio synthesis.

The app tries NPU first, then OpenVINO CPU, then CPU rules. It checks successful inference and the actual execution device, rather than assuming that an enumerated NPU is doing the work. The current backend is visible in the interface.

The bundled model imitates a rule-based policy. I am not claiming that it makes better music or saves power compared with the CPU; those comparisons still need proper measurements.

Try it on Windows

Download the Windows x64 release and extract the entire ZIP.
Run fan-composer.exe and choose your speaker.
Choose a mode, set a comfortable maximum volume, and press Start.
Allow the initial 3.5-second quiet measurement, then listen. Stop is always available.

Nothing plays automatically at launch. Microphone audio stays in memory and is not recorded or uploaded. Settings and explicit feedback stay local.

For Rust developers, the stack is iced + CPAL/WASAPI + rustfft, with the OpenVINO C API for the music policy. Build on Windows with the Rust MSVC toolchain and C++ Build Tools:

git clone https://github.com/zendoclab/fan-composer.git
cd fan-composer
cargo build --release --locked
cargo test --release --locked

The build guide also covers packaging the model and NPU runtime. A source build without that runtime still works through CPU rules.

What is established so far?

Version 0.3.0 passed 26 automated tests, including synthetic analysis, synthesis safety, and automatic-volume checks. Real NPU inference and a short, silent Windows audio I/O run were also verified. These checks do not establish long-session stability or improved listening comfort.

My next question is whether adaptive sound is actually more comfortable than fan noise alone or a fixed ambient track, at comparable overall loudness. Listener feedback and controlled comparisons are welcome.

Source, documentation, and downloads: GitHub
Methods and engineering results: Zenodo preprint

Built by Kyu Lee, cording.ai. Source code and the locally generated policy model are MIT-licensed.

DEV Community: KYU LEE