MikuMikuDance still lives mostly on the desktop: PMX models, VMD motion, skirt physics, camera work. We built AnimaStage Lite — an open-source browser studio so you can load assets, preview motion, add FX, and export vertical Shorts without installing MMD.
🔗 Repository: https://github.com/FBNonaMe/animastage-lite
🌐 Live demo: https://animastage-lite.app/
🎬 Open the studio: https://animastage-lite.app/app
Why the browser?
Short-form creators need:
- 9:16 framing and 1080×1920 export
- Fast PMX + VMD iteration
- Stable WebGL on everyday laptops
AnimaStage Lite is not a full MMD clone — it’s a focused stage: load, animate, light, record.
Stack
| Layer | Tech |
|---|---|
| UI | React 19 + TypeScript |
| 3D | Three.js + React Three Fiber |
| Build | Vite 6 |
| Physics | Bullet (Ammo.js) |
| HQ video | WebCodecs + mp4-muxer |
| Live video | MediaRecorder |
All core features run client-side.
What it does
- Drag & drop PMX/PMD, VMD, textures, HDR
- Timeline + dopesheet + Bézier curves + VMD export
- Bullet physics — skirt, hair, accessories
- RTX Lite — bloom, DOF, weather, style presets
- MP4 HQ (frame-by-frame) and Live recording
- Clean capture — no gizmos in the final video
- 9:16 Lite — lighter render path to reduce WebGL context loss
Optional: MediaPipe mocap, Gemini AI keys, Local/WebRTC collab.
Try it
Online: https://animastage-lite.app/app — drop your PMX + VMD.
Locally:
bash
git clone https://github.com/FBNonaMe/animastage-lite.git
cd animastage-lite
npm install
npm run dev
https://animastage-lite.app/ — landing
http://localhost:3000/app — studio (local)
Optional AI: copy .env.example → .env and set VITE_GEMINI_API_KEY.
Open source
Star ⭐ the repo, open issues, send PRs: https://github.com/FBNonaMe/animastage-lite
MMD models are not bundled — use only content you have rights to publish.
What would you use this for — Shorts, VTuber previews, or learning Three.js? Comments welcome.
---
Top comments (4)
A browser-based MMD studio is an ambitious three.js build - MMD (MikuMikuDance) brings its own hairy problems: parsing PMX/PMD model formats, VMD motion data, physics (the bone/joint sim via a bullet-style engine compiled to WASM), and morphs, all running at framerate in a browser. The fact that three.js has MMDLoader/MMDAnimationHelper helps, but the perf tightrope (skinned mesh + physics + IK every frame without dropping below 60fps) is the real engineering, especially once you're editing in-browser rather than just playing back. Respect for taking on a format most people only consume.
The thing I appreciate generally about builds like this: doing it in the browser (no install, shareable by URL) is a real distribution advantage, and pushing the heavy work client-side keeps it $0-server too. That "use the platform's full capability instead of reaching for native/server" instinct is one I value - it's adjacent to how I think about Moonshift, the thing I work on (a multi-agent pipeline that takes a prompt to a deployed SaaS), favoring the leanest path to a shippable thing. Multi-model routing keeps a build ~$3 flat, first run free no card. Genuinely cool project. What's the perf bottleneck - the physics sim, or skinned-mesh rendering with morphs? Curious where the frame budget actually goes once editing's involved.
Thanks Harjot — really appreciate the deep dive 🙌
You’re spot on about the tricky parts: PMX/PMD parsing, VMD evaluation, morphs + skinning every frame, and running a Bullet-style physics sim in WASM while still targeting ~60 FPS during editing.
On the bottleneck question — it depends on what’s enabled, but in practice we see something like this:
1. Physics (CPU / WASM spike)
With PMX physics on (hair, skirts), the fixed-step sim + syncing bones back to the skeleton is usually the heaviest CPU cost.
We run animation → IK → physics → final skeleton pass, and gate physics if the frame budget is already blown to keep editing responsive.
2. Animation + IK (steady CPU)
Timeline + IK/grants run every frame — not as heavy as physics on typical rigs, but always present, especially during scrubbing.
3. Rendering + morphs (GPU)
When physics is off or light, the bottleneck shifts to GPU: skinned meshes, morph targets, and post-FX (especially in 9:16 export mode).
Short version:
– Physics ON → CPU/WASM (physics) is usually the bottleneck
– Physics OFF → GPU (mesh + morphs + effects) takes over
Happy to compare notes — your “push work to the right layer” idea fits perfectly here (browser = GPU + WASM, not a render farm) 👀
Love it. Honestly the bit I respect most is shipping a real editor for a format people usually only consume, in the browser, at framerate. The physics + skinned-mesh + morphs frame budget is a proper engineering problem and you clearly went after the hard part instead of the demo. Following your stuff now. If you ever want to spin up a quick companion web tool around it without fighting the boilerplate, that's the kind of thing I built Moonshift for, but mostly: keep going, this is genuinely cool work.
Thanks a lot — really appreciate that.
That’s exactly the direction we’re thinking about: turning this into a real tool, not just a demo.
The balance between performance, usability, and not overengineering is something we’re actively figuring out right now.
Would be great to stay in touch — especially if you experiment with similar pipelines.