Show DEV: a VRM desktop companion built with Tauri + Three.js — and the three things that fought back

AniMate Waifu — Tue, 15 Sep 2026 06:25:06 +0000

I've been building AniMate Waifu — a desktop companion app that puts a 3D anime character on top of your desktop. It runs on Windows and macOS, and it's the kind of software that has to survive being left running while you do something else.

This is the intro post: what it does today, and the three problems that took the most attempts. I'll keep posting the ones I hit from here.

What it is

AniMate Waifu puts a character on your desktop as a transparent, always-on-top overlay. Not a wallpaper, not a browser tab — it sits in front of your windows while you work, and it can be set click-through so it never eats your clicks.

You bring the character: it imports VRM 0.x and VRM 1.0 files, including what VRoid Studio exports. On the desktop it tracks your cursor, reacts when you touch it, can be dragged and resized, has idle motion, and moves to whatever you're playing. VRMA dance files can be imported once and applied to any character in your library. A Workshop keeps characters, motions, dances and stages together with 3D previews. Text and voice conversation runs on a persona and TTS voice you set per character; chat history stays on your device, and chat needs a connection.

Free tier ships with built-in characters. A one-time $9.90 unlock covers your own avatars, dances, motions and stages.

Stack, since this is dev.to: Tauri + Three.js + @pixiv/three-vrm. The app is closed source; the GitHub repo is where issues and releases live.

The three things that fought back

1. Transparent, always-on-top and click-through are three requirements that fight each other.

Keeping the character above your windows was the easy part. Keeping it there without a title bar, without stealing focus, and while letting clicks fall through to whatever is underneath took more iterations than the rendering did. Click-through is the awkward one: the window still has to render and animate, but must opt out of hit-testing — and that's platform-specific behaviour, not a flag you set once.

2. VRM 0.x and 1.0 are not the same file with a bumped version number.

0.x uses MToon; 1.0 uses MToon10 and adds capsule colliders, per-joint SpringBone tuning and MatCap masking. If you have a .vrm and don't know which you're holding: open it in a text editor and search for VRMC_vrm. Present → 1.0. Only VRM → 0.x. Renaming doesn't convert anything, because the bone and shader definitions differ.

The practical consequence: a model a user downloads may simply not load, and the error you get rarely tells you why. PMX and FBX have to be converted to VRM first, which is a detour of its own.

3. "Lightweight" is a design constraint, not a feature you add later.

An overlay that is always on screen can't be the thing that heats up the laptop. That shaped decisions early: what runs per frame, what gets cached, what stays asleep until something actually happens. It's also why the macOS build targets Apple Silicon only — shipping a second, slower path for Intel Macs would have meant maintaining two performance profiles for a shrinking install base.

What I'll write about next

What actually breaks when users import their own models (it's usually not the model)
Keeping a 3D overlay light enough to leave running all day
The licensing side: which VRM models you can and can't show or ship

If you've built something that has to live on someone else's desktop — especially anything with overlay windows — I'd like to hear what bit you.

DEV Community: AniMate Waifu

Show DEV: a VRM desktop companion built with Tauri + Three.js — and the three things that fought back

What it is

The three things that fought back

What I'll write about next