Persona

Use the parameter editor to choose tracking inputs, weights, input and output ranges, and response curves for each Cubism parameter

Persona follows the model's own .vtube.json first, so a rig tuned in VTube Studio loads exactly as it was authored. This editor changes things on top of that, and writes the changes to a sidecar beside the model; the .vtube.json itself is left alone

Opening the Editor

Select a Live2D layer and expand Parameters in its detail. It is the deepest section in the model detail, collapsed by default

This page covers Live2D tracking bindings. Face tracking on a VRM avatar directly drives preset expressions and humanoid bones; controllers use virtual binding targets

Given enough width the section splits in two: the input list on the left, the selected binding's settings on the right. Below that they stack

The Input List

The left column lists every available input, not only the bound ones — you can add a parameter directly to any unbound input. They are grouped into families: Head, Eyes, Brows, Mouth, Hands, Mouse, then Perfect Sync, the 52 raw ARKit channels, and last of all one family per controller profile

Hands comes from webcam hand tracking — see Webcam Tracking. Mouth also holds the microphone's Voice* inputs — see Lip Sync

Mouse is the OS cursor's position, as Cursor X and Cursor Y (MousePositionX and MousePositionY, VTube Studio's own names). Both run −1..1 across the display the cursor is on, growing rightward and upward. It is independent of face tracking and of the tracking switch, so it can drive the eyes, the head or a desk pet's paw with the camera off. Position only — buttons and keys would need a global input hook Electron does not offer

Search Inputs at the top matches an input's label, its id, a binding's own name, and the parameter it drives

Each row shows the label over its raw id. Labels are for reading; .vtube.json, .cdi3.json and the plugin API all use ids, and one click copies one. The level under the name follows that input's live value

An input's bindings hang beneath it, and a row can carry these tags:

Add Parameter opens the parameter picker. The names and their grouping come from the model's .cdi3.json; without that file the list is empty, because Persona has no way to know what a parameter is called. Picker rows are tagged drives physics and physics as well

A parameter another binding already drives is not disabled. Its row names the current driver, and picking it moves that binding rather than adding a second — this prevents two rules from overwriting the same parameter. The parameter keeps its mapping (output range, smoothing, curve, the author's name); only the input and its band change

Binding Detail

The right column holds every setting on the selected binding

The line at the top is what this binding does: input → parameter. The parameter half opens a picker — Change parameter — which retargets the binding while keeping everything you tuned: its inputs, input band, smoothing, curve and name. Only the output range follows, being in the old parameter's units. Picking a parameter another binding already drives moves that binding here, as the input list does

A parameter id this model does not have is tagged missing, with a line below saying the binding drives nothing — a common sight after swapping models

Inputs and Weights

Combined Inputs lists each input summed into this binding, with a × weight on each. They are added together before the mapping below, so one binding can combine several signals. A weight commits on blur — each commit is a write to disk

An input missing from a frame reads as 0; a binding is skipped only when none of its inputs is present. That is what makes a formula like blink × −0.8 + wide × 0.8 work, with the constant absorbed by the input range

The first input decides which row the binding files under. Removing the first refiles it under the next, and the last one cannot go

Ranges

Input Start/Input End is the band of the input this binding cares about; Output Start/Output End is the band it pushes the parameter across

Adjust the input range to change expression sensitivity. For example, mapping MouthSmile from 0.2–0.8 onto −1..1 reaches the maximum output at an input of 0.8. Swap the output limits to invert the binding

A new binding starts at the input's own span rather than a flat 0..1 — head angles are in degrees, ARKit channels are 0..1, the rest unitless

Smoothing

0–100, shown on the slider and typeable. It is a One Euro filter coefficient rather than plain interpolation: tight when you move fast, steady when you hold still

Response Curves

The default mapping is a straight line. Add Response Curve inserts a curve you can draw between input and output; Remove Curve takes it away

Both axes are normalized 0..1, framed with the binding's two ranges to the left and below, so the shape you see is how that input band maps onto that output band. A dot on the curve marks where the current input falls

Click to add a point, drag to move, right-click to remove. The two end points move only vertically. With a point selected, the X/Y fields above take a value in the axes' own units — a plateau is easier to type than to drag onto

Segment Types

The selected point decides how the segment leaving it travels:

The last point has no segment leaving it, so its type buttons are disabled

Presets

Presets offers a few common shapes to drag from: Linear, Ease In, Ease Out, S-Curve, Threshold and Steps

Physics

A model's .physics3.json tells the editor which parameters physics reads and which it writes:

• drives physics — physics takes this parameter as an input. Binding it is normal; plenty of rigs route head rotation through physics exactly this way
• physics — the physics simulation writes this parameter itself. Bind tracking to it as well and the two will conflict, which the detail pane also warns about

Live Values and Scrubbing

While tracking is running, each input's level and the dot on the curve follow the live value

Below the level sits Parameter Value, what the parameter actually reads on the model right now — after motions, expressions and physics have had their say — drawn on the output band. Where it parts from the dot on the curve, something else is writing that parameter too

Drag a level to hold that input at a value, so you can pose the model and tune a curve with the camera off. Release and tracking takes over again; a held value also expires by itself after a few seconds, so closing the window, reloading, or a drag that never got its release cannot strand the model

Undo and Redo

Undo is Cmd/Ctrl+Z; redo adds Shift

One drag is one step. Curves, ranges, weights, adding or removing an input, and adding or removing a binding all share the same history. That history belongs to the Parameters section — with focus elsewhere, the same keys go back to scene undo

Where Edits Are Saved

Edits are written to <model>.persona.json beside the model, the same sidecar Remembering Expressions uses. Bindings are never written back into .vtube.json — the format has no fields for response curves or input weights

Read precedence is .persona.json → .vtube.json → built-in defaults. Once the sidecar carries bindings its bindings take precedence and are never merged with a .vtube.json; edits you make in VTube Studio from then on no longer reach this model, which the section says at its top

Importing from .vtube.json

On the first read, the ParameterSettings in a model's .vtube.json are imported whole, including the name the author gave each binding. Names are editable and are saved to the sidecar; clearing one falls back to the parameter's own name

Input names resolve in three passes: VTube Studio's own vocabulary first, then a raw ARKit shape name, then VBridger's spelling, which shortens Left/Right to L/R. A VBridger rig therefore loses no rows — EyeSquintL, MouthDimpleR and MouthUpperUpL are all recognized

VBridger's own composite names are not inputs. They expand on import into the weighted sums VBridger computes them with, transcribed from its preset, so the signs and proportions match what VBridger produces