Calibrations
Two windows record the same kind of fact in two places:
- LABO → Windows → Tracking Calibrations — which way a tracking source's axes point.
- LABO → Windows → Avatar Calibrations — which way an avatar rig's axes point.
You need them when something bends the right amount in the wrong direction. That symptom is specific: a joint that moves through the correct range but around the wrong axis is a coordinate-convention mismatch, not a tracking failure and not a rig failure.
The problem these solve
There is no universal agreement on which way is up, which way is forward, or whether a coordinate system is left- or right-handed. Unity uses left-handed, Y-up, Z-forward. Most tracking SDKs and most 3D authoring tools use something else. Blender is Z-up. OpenXR is right-handed. Inertial sensors often report against a compass frame where Z points down.
None of these is wrong, and none can be inferred from the data — a quaternion looks the same whichever convention produced it. So each source has to be told once, and recorded.
Not noise, and not a frozen limb. A handedness mismatch is a mirror: the participant raises their right arm and the avatar raises its left, or bends forward and the avatar bends back. The motion is smooth and correctly sized, which is why it is easy to mistake for a rigging problem and hard to fix by adjusting anything else.
Which window
| Symptom | Window |
|---|---|
| The gizmo skeleton itself moves wrongly | Tracking Calibrations |
| The gizmo skeleton is right but the character mirrors it | Avatar Calibrations |
Turn on Gizmos → Joints, Bones and Axis before deciding. The gizmo skeleton is the tracking data before any avatar touches it, so comparing it to the character tells you which side of the boundary the problem is on. Guessing here means changing the wrong window and making things worse.
The fields, in both windows
Both windows record the same three things per entry:
| Field | Meaning |
|---|---|
| Native Space | The convention the source actually produces. For a tracking source, what the SDK emits. For an avatar, the rig's authored convention in the tool it came from. |
| Handedness Flip | The axis flip needed to get from native to what LABO consumes. Handedness differences are mirrors, not rotations, so they are recorded separately rather than folded into an angle. |
| Emitted Space | What LABO receives after the flip. |
Both windows also offer Reload, Remove, Clear and Clear All. Clearing is safe — an entry can be re-added, and a missing entry means the source is treated as already matching LABO's convention.