Troubleshooting
Work down this page in order — the first section rules out the most common cause of all of them, which is that only one of the two sources is actually arriving.
Nothing appears at all
The composite produces no pose until its base source is tracking. That is by design: until the body has a position, there is nowhere to put the other sources' joints. So an override source streaming perfectly still shows nothing if the base is down.
Check, in this order:
- The base source has a live frame. Put the base on its own tracking row temporarily and confirm the row turns green.
- Base source points at the right entry. If it names a source that was removed, or an orientation-only source, see below.
- The Console for messages tagged
[LABO][Composite]. A missing base reports itself there once.
The whole body sits at the origin in default proportions
Base source is pointing at an orientation-only source — a UDP stream of IMU quaternions, typically.
An inertial sensor set reports which way segments are pointing and never where they are, so nothing supplies a position or a bone length, and the skeleton falls back to a default-sized body at the world origin. Set Base source back to the source that has real world positions.
An assigned joint stays on the base source
The assignment is not resolving. Either its source index refers to a source that no longer exists — likely if you removed one — or it names the base source itself, which is the same as not assigning it.
The Console reports an unresolvable index once. Re-pick the source in the dropdown.
If the assignment looks right and the joint still does not move, the override source is not producing that joint. A UDP sender only drives joints it has sensors for; confirm the segment is actually in your channel map.
The whole avatar is bent, and it looks like a rigging problem
The composite mirrors its base source's skeleton, including that source's own rest pose. If it fails to pick that rest pose up, every frame is interpreted against the wrong reference and the result is a character bent in a way that looks like the avatar is at fault rather than the tracking.
Check the Console for a warning about rebuilding from the base source's bind. If it is there, the base source has not published a usable rest pose yet — usually because it has not had a good tracked frame. Gizmos are unaffected by this, so if the gizmo skeleton looks correct and only the avatar is bent, this is the cause.
An overridden limb moves correctly but in the wrong direction
The limb bends by the right amount but in the wrong plane — a forward reach comes out across the body.
This is coordinate handling in the override source, not the composite. For a UDP source it is almost always the heading offset. See Coordinate frames, and remember the composite's UDP settings are a separate set from any standalone UDP row you may have already tuned.
An overridden limb sits at a constant offset
Every frame is wrong by the same amount — an arm held out to the side when the participant's arm is down, for instance.
That is the neutral-pose reference in the override source, either captured against the wrong pose or captured at the wrong moment. Two fixes:
- Set Calibration pose to the pose the participant actually held during calibration.
- Recapture the reference. The Recapture button reaches sources nested inside a composite, so you can do it in Play mode — have the participant hold the calibration pose and press it.
If you are replaying a recording, restart the stream from the beginning instead, so the reference is taken from the calibration section of the recording.
The forearm looks stretched
Pin weight is too high. Soft-pinning moves the hand without re-solving the forearm, so the whole discrepancy ends up in that one bone. Lower the weight, or turn Soft-pin hands off — it is off by default for this reason. See the joint map.
An overridden limb is detached or the wrong size
Limb lengths come from the base source, always. A limb that is detached or wrongly proportioned means the base is not supplying poses for those bones — check that the base is tracking that part of the body at all, rather than, say, a headset that cannot see a limb behind the participant's back.
Port already in use
A UDP source starts listening as soon as its provider exists, which happens in the Editor and not only in Play mode. If something else already holds the port — an earlier session, or a second UDP row pointed at the same port — the receiver cannot start.
Set the row's provider to None and back, or restart Play mode. Note that a port can only be bound once, so a composite's UDP source and a standalone UDP row cannot share one.
Two sets of sources in the hierarchy
After a script recompile you may briefly see duplicated source objects under the composite. They are cleared the next time settings are pushed — change any setting on the row, or re-enter Play mode.
Still stuck: isolate the halves
The fastest way to find which source is at fault is to stop combining them.
- Put the base source alone on its own tracking row. Confirm the body tracks the room correctly.
- Put the override source alone on its own row. Confirm the limb moves correctly. For a UDP source, the sample is the known-good reference to compare against.
- Only then put them back in a composite.
If both work alone and the composite does not, the problem is in the joint map or the base-source selection, and the sections above cover it.