Persona

Persona 接收手机应用通过局域网传输的 ARKit 面部数据，并逐帧映射到 Live2D 模型的参数，或 VRM 虚拟形象 的表情与骨骼。面部捕捉由手机完成

手机需满足所用面捕应用的设备要求，并与电脑连接到同一网络

也可以直接用电脑上的 摄像头 捕捉面部、手部和身体，或用 麦克风 驱动口型

Persona 支持多个捕捉源同时工作，每个源可分配给一个或多个虚拟形象。例如，多人可以各用一部手机，在同一台电脑上分别驱动自己的形象；网络连通时也可通过 VPN 连接

捕捉源

捕捉位于 控制面板 左栏，独立于当前选中的图层。捕捉源是应用级设置，不随场景切换而移除。面板从上到下依次是面部捕捉、姿态捕捉、本机 IP 地址卡片、摄像头追踪、口型同步和手柄，其中面部捕捉和姿态捕捉各有总开关、汇总状态和源列表。每个源是一张卡片，显示应用图标、名称、状态和开关。默认包含一个 VTube Studio App (3rd Party UDP) 面捕源和一个 VMC Protocol 姿态源

点开一张卡片会展开它的编辑器：

源卡片旁的添加面部来源…和添加姿态来源…卡片可添加该通道支持的协议，编辑器底部的移除来源把它删掉

启用面部捕捉和启用姿态捕捉分别控制对应通道的网络源，旁边显示汇总状态；摄像头有自己的开关。姿态捕捉接收 VMC 与 mocopi 源，仅支持 VRM，场景中没有 VRM 时会显示提示。两个区块下方的本机 IP 地址用于填写手机应用的目标地址

把形象分配给源

分配虚拟形象打开一个多选框，勾选这个源要驱动的形象，全选一次全勾上。行数只统计这个源所属通道能驱动的形象——姿态源只会列出 VRM

摄像头源的卡片上则是面部、身体和手部三个按钮，每个通道一个，见 摄像头追踪

每个虚拟形象在同一通道中只能分配给一个源。已分配的形象会显示由〈某某〉捕捉。选中它时会弹出重新分配捕捉对话框，列出将转移的形象，确认后才会更改分配

一个源可以同时驱动多个形象。分配给同一源的形象接收相同数据，例如用一部手机让两个形象同步表情

每个形象自己的详情里也有一个捕捉区块，放的是逐个形象的设置：控制器移动 和麦克风口型同步，后者决定麦克风何时驱动这个形象的嘴，见 口型同步。分配哪个源则在源卡片上完成

总开关与源开关

一行的状态受两件事影响：这个源自己的开关，以及它所属通道的总开关（启用面部捕捉或启用姿态捕捉）。任何一个是关的，这一行就显示 off。两个都开着，它才显示自己的实时状态

这样你既可以临时停掉某一个源，也可以一下把整条通道关掉，而不用去逐个改

支持的协议

各协议的配置步骤和工作原理见以下页面：

同时使用多个相同协议的源时，在追踪器 IP 中填写各自对应的手机地址。未填写 IP 的源会接收尚未分配给同类源的发送方数据。若需两部手机分别驱动两个形象，请为每部手机配置一个带 IP 地址的源

各源提供的数据

这三种面捕协议都传输全部 52 个原始 ARKit blendshape，以及头部旋转和位置数据，均支持 VRM perfect sync。输入推导、眨眼锁存和睁眼校准由 Persona 处理。下表列出了连接方式、数据精度和传输格式等方面的区别

对于增益较大的信号，整数量化可能让表情变化显得不够平滑。例如，Persona 对嘴角下垂信号使用 5 倍增益，1% 的步进也会随之放大，可能造成可见的表情跳变

LAPLACE Persona Tracker 还支持一键校准，校准结果会在应用重启后保留。省电模式可调暗屏幕，预览则显示面部线框，不显示摄像头画面。详见 LAPLACE Persona Tracker

这 52 个原始数值也可作为独立的 ARKit* 输入用于 参数绑定。Live2D 模型既可以使用 Persona 推导出的输入，也可以直接使用手机捕捉到的原始 blendshape 值

摄像头 的面部捕捉从摄像头画面算出同样的头部姿态和 blendshape，只是没有 tongueOut

状态

每个源那一行，以及捕捉总开关下方那行字，都会告诉你实际发生了什么：

每个源的状态用于检查对应设备，总开关下方的汇总状态用于检查整个通道

摄像头源使用同样的状态，但只要任一开启的任务检测到面部、手或身体就显示 tracking，见 摄像头追踪。面部捕捉和姿态捕捉的汇总状态只统计网络源

捕捉数据如何抵达模型

捕捉数据会经过以下三个处理阶段：

1. 接收——收到数据的那个源把自己的协议解析成一个中立的数据帧：头部旋转、头部位置和 ARKit blendshape。接下来的两步，对分配给这个源的每一个形象各走一遍
2. 推导——这一帧被转换成 VTube Studio 的输入词汇，也就是模型作者平时打交道的那套信号名：FaceAngleX、EyeOpenLeft、MouthSmile、Brows 等等。那 52 个原始 ARKit 通道则原样透传，各自作为一个 ARKit* 输入并列在旁边——不锁存、不校准、不加增益
3. 映射——每条 参数绑定 把一个或几个输入按权重相加，再依次经过输入范围、输出范围、响应曲线和逐参数的平滑，最后写到某个 Cubism 参数上

头部旋转、头部倾斜、睁眼与眨眼、视线、眉毛、鼓腮、张嘴、口型以及微笑或撇嘴都会被驱动。模型没有的参数直接跳过，而某一帧没带上的参数会被释放，而不是冻结在上一次的值上

自带映射的模型

如果模型自带 .vtube.json，Persona 就用这个模型自己的映射——它的参数配对、它的范围、它的增益和它的平滑——而不是内置的默认值。作者故意把双眼对调、把睁眼范围翻倍或者改了参数名的模型，在 Persona 里的表现和在 VTube Studio 里完全一致

没有 .vtube.json 的模型走内置映射，这套映射是对着真实的 ARKit 录制数据调出来的

VBridger 参数

VBridger 不是一张参数表，而是一个由用户自己写公式的引擎：每个输出名下面挂着一到三条关于那 52 个 ARKit 形状的表达式。它所谓的「标准」其实是随它一起发布的预设 VBridger_AdvancedARKit_V3.0，里面 MouthPucker、MouthFunnel、MouthShrug、MouthPressLipOpen 和六个 Body* 都不在 VTube Studio 自带的输入表里——在 VTS 那边它们只能由插件创建，而创建它们的正是 VBridger

所以 Persona 不把这些名字当作输入。它们在从 .vtube.json 导入绑定 时展开成 VBridger 自己算它们用的那个加权和，公式取自 VBridger 预设。MouthPucker 是 (mouthDimple_R + mouthDimple_L) × 2 − mouthPucker，撮口是负的；六个 Body* 和对应的 FaceAngle*/FacePosition* 是同一条式子。展开之后它们就是普通的加权输入，可在编辑器中继续调整

MouthOpen 和 JawOpen 是分开的两个输入：前者是嘴唇张开的程度，后者是下颌张开的幅度——正好对应 VBridger 模型上的 ParamMouthOpenY 与 ParamJawOpen。JawOpen 与 ARKitJawOpen 的数值相同，所以两个名字读到的是同一个数，写哪个都一样

模型位置移动

身体前倾或后仰移动的是整个模型，而不是某个绑定参数：它跟着你头部的水平与垂直位置平移，并随你靠近或远离而缩放。这与 VTube Studio 的内置行为一致，包括它默认的幅度和平滑，并通过 .vtube.json 里的 ModelPositionMovement 段落逐模型配置

VRM 虚拟形象

同样这几个面捕源也能驱动 VRM 虚拟形象，只有最后一步不同，因为 VRM 没有 Cubism 参数

把全部 52 个 ARKit blendshape 都做成表情的模型——也就是 perfect sync——会完全跳过推导出的词汇，直接被手机的原始 ARKit 数值一比一驱动，保留原始捕捉数值。名称匹配不区分大小写，以兼容不同模型的命名方式。只覆盖一部分是不够的：52 个里只有 51 个的模型会退回到下面这套映射，信息区块 的完美同步一行会报出这个数量

没有 perfect sync 时，推导出的信号会映射到模型的预设表情上：

• 嘴部——张嘴、撮口、噘嘴和微笑组合成 VRM 的口型表情（aa、ih、ou、oh），各个形状互相约束，避免不合理的口型叠加
• 眼睛——模型分左右眨眼就用分左右的，没有就用合并的眨眼表情
• 头部——偏航、俯仰和翻滚，其中一部分会分摊到胸部和脊椎上，让整个上半身自然地跟着转头
• 视线——通过模型自带的 look-at 控制眼睛朝向，无论它是骨骼驱动还是表情驱动

与待机动画切换

捕捉启用时优先控制形象，暂停待机的自动眨眼。关闭捕捉后，形象恢复待机行为

捕捉数据中断时的行为由每个形象待机分区里的追踪丢失时决定：默认的保持最后姿势冻在最后收到的那一帧上，回到待机则过渡到待机动画。两种情况下眼部控制都会被释放，恢复自动眨眼，直到数据流恢复。Live2D 还能指定一个顶替用的动作，见 追踪丢失时

无需校准

Persona 不提供中性姿态校准，而是与 VTube Studio 的 ARKit 捕捉一样，直接使用手机报告的绝对头部姿态。请将手机正对自己，放在大致与视线齐平的高度；位置过低可能让模型持续呈现抬头姿态

这是针对手机源的；摄像头 则在 Persona 里校准

摄像头追踪

摄像头追踪用电脑上的摄像头完成面部、手部和身体捕捉，由单独的启用摄像头追踪开关控制。每个形象的面部、身体和手部可以分别来自不同的源，所以摄像头可以在手机和动捕套件之外补上手指。详见 摄像头追踪

口型同步

口型同步用麦克风驱动形象的嘴，每支麦克风可以单独校准声音。每个形象的麦克风口型同步可选关闭、始终或面部捕捉不可用时。详见 口型同步

手柄

捕捉页底部的手柄区块用于设置控制器。手柄支持 Live2D 与 VRM 的 参数绑定、逐实例的舞台移动，以及 自动化 与 虚拟形象快捷键 的组合键。它不使用捕捉源或形象分配，也不支持控制相机

连接手柄

打开启用手柄，然后连接手柄。DualSense 与 DualSense Edge 通过 WebHID 自动识别，无需先聚焦窗口或按键，重启应用后也能识别。其他手柄使用浏览器的 Gamepad API：点击舞台，再按一下手柄按键，设备才会显示

已连接的控制器显示当前在线的设备数量，包括尚未分配的设备。已连接的配置排在前面，其余配置保留在折叠的已保存的配置中。选择卡片只会切换实时监视的对象，不会修改绑定

应用设置会保存配置编号、设备报告的产品名和硬件标识的哈希值，不保存硬件标识原文。有硬件标识的设备即使型号相同，更换连接顺序或线缆后也能保留各自的绑定。断开手柄只会释放输入，不会删除配置或绑定

Xbox、其他 PlayStation 与 Switch Pro 手柄走 Chromium 的 standard 布局，认的是按键的物理位置而不是它上面印的字母。认不出来的浏览器布局会被标为不支持。陀螺仪、触控板、自定义重映射，以及把多只手柄合并成一只，都不在这一版里

手柄驱动参数

模型的参数编辑器里，每一份已保存或已被绑定过的配置各有一组输入，每族 19 个控件：两根摇杆、摇杆按下、十字键、四个面键、肩键、扳机、options 与 home。摇杆和十字键的范围是 −1 到 1，Y 轴向上为正；按键和扳机是 0 到 1。每条绑定各自挑用哪一组的输入，所以不同手柄可以分别驱动不同的参数、不同的形象

一号配置沿用 VTS 的名字，比如 ControllerStickLeftX 和 ControllerCross，原有的映射照常能用。二号往后在 Controller 后面插入编号：Controller2StickLeftX、Controller3Cross、Controller12TriggerRight——这几个编号名是 Persona 自己的扩展，插件 API 的输入目标用的是同一套名字

手柄输入应用于每个已加载模型自己的规则，与面部捕捉的开关和源分配无关。它和面部输入一起在范围、曲线、平滑这几步之前完成加权求和——数据流中断期间，面部输入保持在最后的值上，手柄输入照常响应。编辑器里手动拖动某个输入时，手动值优先于对应的物理输入。手柄绑定统一走一条与帧率无关的指数响应：平滑为 0 是立即跟随，100 的时间常数是 350 毫秒

拔掉一只手柄只释放它那一组；关掉启用手柄释放全部。之后没有任何源在驱动的 Live2D 输出会回到 Cubism 的默认值

VRM 上的手柄目标

同一个参数编辑器给 VRM 虚拟形象 生成了另一批目标。它们是虚拟的绑定目标，不是从 Cubism 导入的参数：

角度沿用面部输入的约定，VRM 0.x 与 1.0 之间俯仰、翻滚的差异由渲染器处理；表情名按模型里写的原样匹配。骨骼与视线叠在当前的动画、姿态捕捉和面部捕捉之上，表情绑定只占它指到的那个权重。每帧末尾驱动器会把底下那层的状态还原回去，所以偏移不会越积越大，手动调好的表情权重也不会被抹掉。松开输入或删掉规则，对应目标会缓动回底下那层当前的姿态或表情，其他手柄和捕捉源控制的目标不受影响

绑定属于模型，存在它既有的捕捉 sidecar 里，所以同一个模型的多个实例共用这些规则。要让同一个模型的两份拷贝各自独立地动，用下面的逐实例移动设置

舞台移动

形象自己的捕捉区块里，打开控制器移动并选一份已保存的配置。总开关启用手柄也得是开着的。移动是可选的，默认关闭——参数绑定和快捷键不依赖它

移动速度在 Live2D 上的单位是每秒多少个舞台高度，在 VRM 上是米每秒（默认 0.5，范围 0–10），它同时决定 Live2D 的缩放速度和 VRM 的升降速度。旋转速度是度每秒（默认 90，范围 0–720）。响应平滑是速度的响应时间，单位秒（默认 0.12，范围 0–0.5），为 0 就是立即响应。Live2D 的缩放按当前大小成比例进行，照常受缩放上下限约束

移动是按实际经过的时间对平滑后的速度积分出来的，所以 30、60、120 fps 走得一样快。摇杆回中会缓动着停在新的位置上。拔掉、关掉或重新分配手柄会立刻清掉它的速度，重连不会接着之前的惯性走。隐藏的形象不会动。直接拖动摆放、位移过渡（自动化的模型位置操作或插件发起的移动），以及正在输入文字、录制快捷键、分配手柄时，都会暂停移动

移动会更新实例的位置，并随场景保存

移动时行走

VRM 独有。打开移动时行走并从动画素材库里选一个步行动画——开关可以先打开，选好片段之前它不生效。导入的 VRMA、Mixamo FBX 和 MMD VMD 与待机片段用的是同一批已注册素材

形象在地面上移动时片段循环播放，停下来就融回它平常的待机。步态速度是这个片段在播放速度 1 时对应的名义速度（米每秒），实际播放速度按测到的地面速度除以它、再除以形象的缩放——所以改移动速度或者换个大小的模型，步频会跟着调整。髋部的 X/Z 位移会被去掉，摆放仍以场景为准，上下起伏保留。行走这一层不带头部、视线和表情的轨道，手柄与面部的姿态因此不受影响。一次性动画优先级更高，姿态捕捉（VMC、mocopi 或摄像头）占着髋部或腿部时行走会被抑制，只驱动手部的 VMC 可以和它并存

朝向移动方向让形象按旋转速度转向行进方向，与有没有选步行动画无关；右摇杆的转身优先。行走看的是平面上的实际位移，包含缓停那一段，只有高度变化不算。这是叠在直接移动之上的动画，没有寻路、碰撞或地形贴合

手柄快捷键

快捷键录制器——无论用于自动化的键盘或控制器触发条件，还是 虚拟形象快捷键——接受同一只手柄上最多三个控件，摇杆与十字键的方向、扳机都算。录下来的键带着它所属的配置，所以一号机和二号机上的同一个键可以跑不同的操作；录制时按在别的手柄上的键不会被算进这一组。按下的那一瞬间触发一次，按住不放不会重复。后台生效对手柄快捷键同样有效，而且不需要额外带一个键盘修饰键——正在录制或正在输入文字时不会触发，期间按下的控件会被忽略，移开焦点或关闭录制器后，仍按住的控件也不会触发快捷键

一号手柄的组合沿用 VTS 那套 Controller* 名字，二号往后用带编号的 Persona 名字。它们不注册进操作系统的全局快捷键，也不支持键盘与手柄混按、或者跨手柄混按。组合键相同时，自动化优先于虚拟形象快捷键

.persona.json 用它平常的触发字符串存下所有配置。模型用的是 .vtube.json 时，带编号的手柄快捷键存在这条快捷键的 PersonaControllerTriggers 扩展字段里，同时把 VTS 原生的触发槽清空，以免 VTS 读取不支持的枚举名。Persona 优先读这个扩展；改成键盘或一号手柄的快捷键、或者清空它，会移除该扩展

疑难排查

状态一直停在「waiting…」

• 确认手机和电脑在同一网络下，并且这个网络不会拦截设备之间的通信——访客 Wi-Fi 和公共 Wi-Fi 通常会拦
• 检查防火墙是否允许 Persona 接收入站的 UDP
• 断开所有 VPN。VPN 可能拦截广播流量。Persona 会在每张物理网卡上发送子网定向广播，但部分 VPN 配置仍可能阻止它们

如果广播无法到达手机，可以在启动 Persona 前通过环境变量指定手机地址：

模型会动，但响应的部位不对

检查模型是否附带 .vtube.json。Persona 会使用其中的映射。可以在 VTube Studio 中加载同一个模型，对比相关参数的表现

某些参数从来不动

展开选中模型的信息，看一眼参数数量。使用非标准参数名的模型，以及沿用 Cubism 2 命名习惯的老模型，会让某些输入根本找不到可驱动的参数

什么都没反应，状态却是「tracking」

展开该源并检查虚拟形象列表。收到数据后，仍需将形象分配给这个源才能驱动它。每个形象在同一通道上只能分配给一个源，也请确认它是否已分配给其他源

两部手机，动的却是同一个形象

两个源的追踪器 IP 都留空时，数据可能被任一尚未匹配设备的源接收。为每个源填写对应手机的地址，确保数据发送给正确的形象