DEV Community: AniMate Waifu

Keeping a 3D overlay light enough to leave running all day

AniMate Waifu — Mon, 28 Sep 2026 14:49:27 +0000

This is the third post in a series about building AniMate Waifu, a desktop companion that puts a VRM character on top of your desktop. Post one covered the three problems that fought back the hardest; post two was about why an imported model usually isn't the thing that breaks. This one is about the constraint that shaped most of the rendering code: an overlay that lives on someone's desktop all day has to be cheap enough that they never have to think about it.

A desktop pet is not a game. A game gets your full attention for an hour; a desktop companion shares your screen with everything else you do, for as long as you keep it open. The character sits in a corner while you read, write, or wait for a build. That means idle is not an edge case — idle is the default state, and idle is what has to be cheap.

Cap the loop first

The simplest decision had the biggest effect: the render loop doesn't run uncapped. The default target is 30 fps, with 15 / 30 / 60 selectable. Nothing about a character that occupies a corner of your screen needs 120 fps — above roughly 30, the extra frames are electricity, not smoothness.

Idle should cost less than active

On top of the cap, the app watches for interaction. After 30 seconds with no activity it drops to 15 fps; the next interaction restores the normal rate immediately. The exact numbers matter less than the signal: "the user hasn't touched it in a while" is information you already have for free, and acting on it is the difference between an overlay people keep running and one they quit.

One pacing bug worth passing on

The throttle itself had a subtle failure. requestAnimationFrame fires at your display's refresh rate, and the naive pattern — skip the frame if not enough time has elapsed, otherwise set lastTime = now — drifts on displays that don't divide cleanly. On a 59.94 Hz panel the fractional remainder accumulates until the throttle starts dropping every other render, and the character stutters for no visible reason. The fix is one line: carry the remainder forward (lastTime = lastTime + interval) instead of resetting it to now. Small, but it's exactly the kind of thing that shows up as "feels janky on some machines" and nowhere else.

Throttling is contextual, not global

The idle rule applies to the overlay — not to every surface in the app. The Workshop, where you preview characters, dances and stages, opts out of the throttle entirely while it is on screen, because judging a dance at 15 fps is useless. One shared frame controller, different policies per surface.

Verify it on your own machine

If you run any desktop pet — ours or someone else's — open Task Manager or Activity Monitor, leave it alone for half a minute, and watch: idle usage should be visibly lower than active usage. If a pet burns the same CPU doing nothing as it does dancing, it is rendering every frame for no reason.

And if ours is the one misbehaving on your machine, the four steps to find the real fix on our site are the user-facing version of this post — no code required.

Issues and releases live on the GitHub repo.

Next in the series

One promised topic left: the licensing side — which VRM models you can and can't show or ship, and why "it was on the internet" isn't a licence. If you've tuned an always-on app for power, I'd like to hear what worked.

It's usually not the model: what actually breaks when users import their own VRM avatars

AniMate Waifu — Mon, 21 Sep 2026 06:59:58 +0000

Last week I posted about AniMate Waifu — a desktop companion that puts a VRM character on your desktop — and the three things that fought back while building it. This is the follow-up I promised: what actually breaks when users import their own models.

Short version: it's usually not the model.

Once your app accepts user-supplied files, you inherit every way a file can be wrong. Ours imports VRM 0.x and VRM 1.0 — files arrive from VRoid Studio, from Blender, and from conversion pipelines out of PMX and FBX. After enough "my model is broken" reports, a pattern shows up fast, and the pattern is not broken geometry.

Four checks before blaming the model

None of these involve the file, which is exactly why they're worth running first:

Is the app current? Format support widens with releases. An import that fails on an old build may be a bug that's already fixed.
Is the feature unlocked? In our app, custom import is the paid feature. Better to surface that before a user spends an evening debugging their model against a paywall.
Did the download complete? A truncated .vrm is the single most common "corrupt file" report — and it's a download problem, not a model problem. Compare the file size against the source.
Is it actually a .vrm file? Not .pmx, not .fbx, not a Live2D .model3.json, not a folder of textures. One file, ending in .vrm.

The rename trap

VRM is a profile on top of glTF 2.0, and renaming doesn't convert anything. A .pmx or .fbx renamed to .vrm still has the wrong bones and shaders inside. Plain glTF out of Blender renamed to .vrm is the same story — the extension alone doesn't make a file VRM, which is why the Blender path goes through the VRM add-on: it maps the humanoid bones and writes the VRM extension block.

Thirty-second check: rename a real .vrm to .glb and a glTF viewer will parse it (materials will look wrong — that's MToon, and that's fine). Rename a .pmx to .vrm and nothing will parse it at all.

What the symptoms are actually telling you

When the file genuinely is a VRM and it still misbehaves, the symptom usually names the cause:

Symptom	Usual cause
Imports, then stands frozen	Humanoid bone mapping missing or non-standard — the mesh loads, the rig doesn't
Black, glowing, flat or invisible materials	Version mismatch: 0.x uses MToon, 1.0 uses MToon10 — a file exported as one version with materials authored for the other
No facial expressions	Blendshapes missing, or a 0.x/1.0 naming difference
Hair and skirt rigid	SpringBone physics stripped on export
Very slow	Polygon, material and physics weight — an overlay that renders all day punishes what a game engine forgives
Wrong size or facing the wrong way	Not a defect: models arrive at wildly different scales, so scale is the first knob, not a bug report

The second row is the sneaky one: the file is internally consistent — it was just exported as one version with materials authored for the other.

Export settings beat modelling

If there's one takeaway, it's this: export configuration causes more import failures than the modelling does.

Exporting from VRoid Studio: confirm the humanoid rig, include expressions, keep SpringBone physics — and let VRoid reduce polygon and material counts on export, because at desk scale nobody sees the difference and the GPU notices. One more version note: current VRoid Studio dress-up exports are VRM 1.0 only, so this trap is getting more common, not less.

What we changed app-side

Two things, after enough of these reports. Parse at preview, before anything is committed — a bad file surfaces there with its reason, not after it's already in the library. And never open with "your file is broken": a meaningful share of those reports turn out to be something on our side. We keep the current version of the checklist in our VRM import guide, and issues and releases live in the GitHub repo.

From last post's list, two candidates remain: the licensing side — which VRM models you can actually show and ship — and keeping a 3D overlay light enough to leave running all day.

If you've shipped an import pipeline, 3D or otherwise: what's the failure mode your users keep finding?

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.