Pocket Live turns one camera into a complete virtual performance. Face, body, and hand movement are tracked locally, stabilized, mapped onto a VRM avatar, and rendered as a clean scene ready for streaming—without sending camera frames to the cloud.
What Pocket Live does
One camera
Face, head, upper body, arms, and hands contribute to one continuous performance.
Fully local
Tracking and rendering run on your Mac. The camera feed never needs a cloud round trip.
One avatar signal
Filtered landmarks drive humanoid bones, expressions, gaze, and secondary motion together.
Stream-ready output
Only the composed avatar scene reaches OBS or your live platform.
The product is deliberately narrower than a general animation suite. It owns the path from live camera motion to a stable character scene, so creators can spend their time performing rather than wiring together separate face, body, renderer, and output tools.
Live2D and VRM: two good solutions, two different abstractions
Live2D Cubism starts with layered artwork. ArtMeshes and deformers create the authored shapes for head turns, mouth movement, arms, hair, and clothing. Parameters such as Angle X or Mouth Open/Close interpolate between those shapes. The result can retain the exact linework and visual language of an illustrator. That is Live2D's defining strength, not a limitation. The mechanics are described in Live2D's official guides to deformers and parameters.
VRM starts from a different premise. It packages a humanoid 3D avatar and standardizes how applications find its bones, expressions, gaze, materials, secondary motion, and metadata. The format is designed for runtime loading and general-purpose motion capture, with the avatar data carried in one file. The VRM Consortium documents these avatar operations and humanoid conventions.
| Decision | Live2D | VRM |
|---|---|---|
| Visual language | Authored 2D illustration and mesh deformation | Spatial 3D character, materials, lighting, and camera |
| Motion interface | Model-specific parameters and keyforms | Standard humanoid bones, expressions, and gaze |
| Body and hands | Possible when the model is authored with the required parameters | Skeletal pose maps directly onto articulated limbs and fingers |
| Viewpoint | Best inside the angles and forms prepared by the artist | Free 3D camera movement and scene composition |
| Runtime integration | Cubism model data rendered through the Cubism ecosystem | Platform-independent avatar data built on glTF conventions |
Why Pocket Live uses VRM
Pocket Live begins with spatial observations: face rotation and expressions, shoulders, elbows, wrists, hips, and hand landmarks. A VRM humanoid gives those observations stable semantic targets. The solver can address leftUpperArm, leftLowerArm, hand, fingers, head, and expression channels without inventing a new control vocabulary for every avatar.
The Pocket Live path
Camera → local landmarks → filtered pose → VRM humanoid → native render → clean stream
This also keeps the whole scene coherent. The avatar, camera, lighting, background, and effects share one 3D renderer. A creator can change the camera or stage without asking the model artist to draw another view. And because the tracking and rendering stay on the Mac, only the final avatar scene needs to reach streaming software.
What VRM does not solve for us
A standard skeleton is not a motion-quality button. Webcam landmarks still become noisy when hands cross the torso, limbs leave frame, or depth is ambiguous. Pocket Live still needs confidence gating, temporal filtering, joint limits, inverse kinematics, collision guardrails, and graceful recovery when tracking disappears. Rig quality matters too: a technically valid avatar can still deform poorly around shoulders or elbows.
That distinction matters. VRM reduces the amount of model-specific integration; it does not remove the work required to make continuous human motion look natural.
When Live2D is the better choice
Choose Live2D when the character's identity lives in a particular drawing, when a mostly frontal performance is the goal, or when carefully authored exaggeration matters more than free 3D movement. A strong Live2D rig can feel more expressive than an average 3D model because every deformation was composed for that character.
Teams embedding Cubism should also review the official SDK publication terms for their product and business model. The terms distinguish development, publication, company size, and expandable applications, so there is no useful one-line licensing answer.
When Pocket Live is the better fit
Pocket Live is aimed at creators who want one camera to drive face, body, and hands; who want a 3D avatar that can move between scenes; and who prefer a local pipeline they can inspect and extend. VRM is the interchange layer. PocketJS is the execution layer.
PocketJS already supplies native VRM rendering, morph targets, animation retargeting, and spring-bone physics in a compact process. Its Pocket Character engineering noteexplains the renderer and its measured native architecture. Pocket Live adds the live camera, tracking, stabilization, character plugins, backgrounds, and stream-ready output.
What the full local pipeline actually costs
An idle character benchmark does not represent a live product. We measured Pocket Live with the camera, face, pose, and hand inference, VRM mapping, virtual background, and 1920×1080 window rendering all active. OBS was deliberately excluded so this is a measurement of Pocket Live itself, not the streaming encoder.
| Runtime process | Median CPU | Median RSS |
|---|---|---|
| PocketJS / VRM render host | 7.5% | 127 MiB |
| Apple Vision camera bridge | 4.8% | 209 MiB |
| MediaPipe face + pose + hands | 31.0% | 302 MiB |
| Complete Pocket Live pipeline | 43.1% | 638 MiB |
Test setup. MacBook Pro with Apple M5 Max, 18 CPU cores, 48 GB memory, and macOS 26.6.2; Pocket Live's default 27 MB VRM avatar and comic background; camera tracking enabled. We allowed 25 seconds for warm-up, then collected 13 process-tree samples at five-second intervals. CPU uses the macOS ps convention, where 100% means one fully occupied logical core. Memory is the sum of resident set size for the three product processes and can count shared pages more than once. Per-process medians are calculated independently, so rounded rows need not add exactly to the total.
The useful result is not just the total: landmark inference is the dominant CPU cost. The PocketJS render host—including the VRM avatar, animation, expressions, background, and native window—used a 7.5% median CPU in this run. That is why Pocket Live keeps PocketJS as a compact execution layer and spends its performance budget on motion quality. This is one reproducible machine-and-scene snapshot, not a universal guarantee; avatar complexity, camera hardware, and tracking settings will move the numbers.
The decision in one sentence
Live2D is the right tool when you want to animate a drawing; Pocket Live chose VRM because it wants to translate a person's spatial performance into a portable, fully rendered 3D avatar—locally and in real time.