SysMocap: video-driven motion capture for VTuber and AR avatars

What SysMocap solves, and who it is actually for

Markerless motion capture usually means either buying hardware or assembling a research stack. SysMocap takes a third route: a desktop application that reads a video source, extracts body motion, and drives a 3D virtual character in real time. The README describes it as a cross-platform real-time video-driven motion capture and 3D virtual character rendering system for VTuber, Live, AR and VR. The audience is implied by that list. A VTuber who already owns a VRM avatar and wants full-body motion in a stream is the primary user. The topics on the repository add augmented-reality applications and mocap.

The README claims full-body, half-body, half-body with hands, and facial capture, and shows a system architecture diagram. It does not publish latency figures, frame rates, or a minimum camera specification, so anyone whose stream depends on a hard timing budget has to measure that themselves. Treat the feature list as scope, not as a performance promise.

How the capture pipeline is put together

The repository layout shows the split. main.js is the Electron entry point, src/ holds the application code, webserv/ is a web server, utils/ contains shared code including language.js for translations, and models/ ships bundled assets. The package.json comment spells out the dependency strategy: build-only packages are bundled into dist/assets or copied to dist/node_modules by vite-plugin-static-copy, and runtime dependencies stay in dependencies because they are required by the un-bundled main.js and webserv, or served from /node_modules to the web client.

That served-from-/node_modules detail is the interesting part. The web client imports three, @pixiv/three-vrm, kalidokit and socket.io directly from node_modules rather than from a bundle. So the renderer and the pose-solving library run in a browser context inside Electron, with Three.js drawing the character and @pixiv/three-vrm loading VRM avatars. Socket.io is the transport for mocap data, which matches the README notice that HTTP and HTTPS share the same port in Mocap Data Forward.

Mocap forwarding is what makes the AR and VR claims concrete. The README states that the WebXR API is supported on Mocap Forwarding, and that it is HTTPS only. A headset or a second browser page can therefore consume the same motion stream the local viewer shows.

Installing SysMocap and getting a first avatar moving

The README points to the releases page for prebuilt packages. Windows ships as a portable 7z archive you extract and run as SysMocap.exe, or as an MSI installer, in both x64 and arm64 builds for 64-bit Windows 10 and 11. macOS ships as a DMG in x64 and arm64 variants, with the arm64 build for Apple Silicon and the x64 build for Intel Macs and Hackintosh devices on macOS 10.15 or later.

On macOS the README warns about two Gatekeeper obstacles. You need to set Gatekeeper to Anywhere in System Settings using the command below, and if the app reports that it is damaged and cannot be opened, you clear the quarantine attribute on the installed app.

sudo spctl --master-disable
sudo xattr -r -d com.apple.quarantine /Applications/SysMocap.app

Running from source needs the latest Node.js. The README gives this sequence, and note that npm start runs a Vite build before launching Electron, so the first start is slower than later ones.

git clone https://github.com/xianfei/SysMocap.git
cd SysMocap
npm i
npm start

Once the window is open, the README says you import a 3D model by dragging it in, and that VRoid Studio is a recommended way to create a VRM avatar. For the character to animate without manual work, the model must contain a specific set of skeleton nodes. The README lists Hips as the main node carrying both position and rotation, with rotation only for the others: Neck, Chest, Spine, RightUpperArm, RightLowerArm, LeftUpperArm, LeftLowerArm, LeftUpperLeg, LeftLowerLeg, RightUpperLeg, RightLowerLeg. If your model does not match, the README says you rebind the nodes manually. The model viewer includes a bones and dressing controller for that purpose. Auto skeleton detection is documented for VRM 0.x, VRM 1.0 and Mixamo-format FBX files.

The skeleton binding requirement is the real adoption cost

Automatic detection covers VRM and Mixamo FBX, which is a wide net, but it is not universal. Any other rig falls into manual mapping, and the README does not describe how long that takes or what happens when a rig has extra joints between the listed nodes. This is the point where a project that looks like drag-and-drop becomes real work.

There is a second constraint worth reading twice. The Hips node carries position as well as rotation, while every other listed node carries rotation only. That means root translation comes entirely from Hips. If your rig drives root motion from a different node, or expects the character to move through the scene by another mechanism, you will be reconciling that yourself. The README does not document retargeting behaviour beyond this list.

The README also does not document rollback, undo, or how to recover a saved binding. If you spend an hour mapping a custom rig, the documentation is silent on whether that mapping survives a restart.

Where SysMocap is the wrong tool

SysMocap is video-driven and single-source by design. Nothing in the README describes multi-camera fusion, optical marker support, or a capture volume. If your requirement is a clean take for pre-rendered animation with sub-centimetre accuracy, a webcam pipeline is the wrong instrument, and no amount of binding work changes that.

Live-streaming use has its own boundary. The README notes that HTTP and HTTPS share the same port in Mocap Data Forward, and that WebXR forwarding is HTTPS only. Anyone running other services on the same port, or terminating TLS in front of the forwarder, has to plan around that. There is also no documented Linux binary: the README says Linux is source code only, so Linux users are building from the Node.js path and maintaining that build themselves.

The macOS instructions are a genuine friction point rather than a bug. Disabling Gatekeeper system-wide with sudo spctl --master-disable lowers a machine-wide security setting to run one application. Clearing the quarantine attribute on a single app is the narrower option, and the README presents both without ranking them.

How it differs from VSeeFace and Warudo-style setups

The closest comparisons in this space are desktop VTuber applications that also do webcam tracking. The difference here is architectural. SysMocap is an Electron application whose renderer pulls Three.js, @pixiv/three-vrm, kalidokit and socket.io from node_modules at runtime, and it exposes a mocap forwarding server with a WebXR path. That makes it a node in a pipeline rather than a closed viewer: the same motion stream can feed the local view, a browser page, or a headset.

A second difference is the model format policy. SysMocap documents automatic skeleton detection for VRM 0.x, VRM 1.0 and Mixamo-format FBX, plus manual mapping for anything else. Applications that lock you into one avatar format cannot accept an existing FBX pipeline at all. If your assets are already Mixamo FBX, that flexibility is the reason to look here.

The trade-off is polish and documentation depth. A commercial VTuber app typically publishes latency targets, hardware recommendations and a troubleshooting guide. SysMocap's README covers features and installation well and leaves performance, rigging edge cases and failure recovery undocumented. That is the honest summary of the comparison.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-06-10, which is the same day as the v0.8.0 release. The release history before that is sparse: v0.7.3 on 2025-03-25 and v0.7.2 on 2024-07-18. So the pattern is long quiet stretches punctuated by substantial releases. Plan upgrades around releases rather than expecting continuous churn.

The licence situation needs care. The repository LICENSE is MPL-2.0, but package.json declares "license": "ISC". Those disagree, and the README does not reconcile them. MPL-2.0 is file-level copyleft: modifications to covered files must be made available under the same licence, while larger works that combine it with other code can be licensed differently. If you are embedding SysMocap in a product, resolve which licence actually governs the files you redistribute before you ship. That is a question for your own counsel, not something the README answers.

Upgrade cost from source is low in principle. npm i and npm start, with npm start rebuilding through Vite each time. The heavier cost is the Electron packaging scripts in package.json, which cover macOS DMG, Windows MSI and 7z output across x64 and arm64. Anyone producing their own builds inherits those scripts and the platform tooling they assume.

Editorial conclusion

Adopt SysMocap if you already have a VRM avatar and want webcam-driven full-body motion inside an OBS workflow without buying tracking hardware. Do not adopt it if you need documented multi-camera capture, a published performance budget, or a Linux binary, because the README offers none of those. Verify two things before committing: that your model contains the required skeleton node names listed in the README, and that your macOS Gatekeeper settings or quarantine flags allow the app to launch.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. README
4. Releases
5. xianfei/SysMocap on GitHub