The joint map
The joint map is the whole point of the Composite provider: a list saying which source drives each joint. Anything not on the list stays on the base source.
What you are actually choosing
The map assigns rotation only. There is no per-joint position setting, and that is not an omission.
In a skeleton, a joint's position is its parent's pose plus a fixed offset — the length of the bone between them. So a "position source" would really be a bone-length source, and bone lengths are a property of the participant, not of the moment. They come from the base source, for every joint, every frame.
Two things follow, and both are worth knowing:
- An orientation-only source loses nothing. Inertial sensors report which way a segment is pointing and nothing else. Rotation is the entire contribution they have to make, so a map that assigns rotation is a map that uses everything they measure.
- There is nothing to keep aligned. Because the composite's root is simply the base's root, the overridden limbs cannot drift away from the body. That is why this provider has no dead zone, no half-lives and no foot-plant settings, where Fusion needs all three.
Assigning a chain, not a joint
Sensors measure segments, and a limb is a chain of them. Assign the whole chain that your sensors cover, in order, rather than picking joints out of the middle.
The default map is a trunk-and-one-arm inertial setup, which instruments the right arm from the shoulder blade outward:
| Joint | The segment a sensor sits on |
|---|---|
| RightScapula | Shoulder blade |
| RightArmUpper | Upper arm |
| RightArmLower | Forearm |
| RightHandWrist | Hand |
Each joint in that chain hangs off the one above it. Assign the forearm but not the upper arm and the forearm's own angle is still correct, but it is hanging from an upper arm the base is estimating — so the elbow ends up wherever the base put it. That is sometimes what you want; more often it is a gap in the map.
LABO's joint list is finer than the humanoid skeleton it drives: it names both a Scapula and a Shoulder where the skeleton has one bone. Either name reaches that bone, so pick whichever matches your sensor naming. If you list both, the lower entry in the map wins.
Where to put the trunk
The default map leaves the trunk on the base source even when the sensor set instruments it, and this is deliberate rather than an oversight.
An inertial world frame is levelled by gravity, which fixes which way is up but leaves the compass direction free. That is what the heading offset exists to supply, and it is a per-session number that has to be right. A headset does not have that problem — it knows which way the room faces.
So leaving the trunk on the headset hangs the instrumented limb off a trunk whose facing direction is known, rather than off one that depends on a setting being dialled in correctly.
Moving the trunk onto the sensors is supported — add Hips and Chest to the map. Do it when the trunk motion itself is what you are studying, and expect the heading offset to matter a great deal more once you have.
Soft-pinning the hands
An overridden arm arrives at the wrist by working outward: the sensors' joint angles applied along the base's bone lengths. That lands close to where the headset sees the wrist, but not exactly on it — the gap is the two systems disagreeing, accumulated over the whole chain.
Soft-pin hands closes that gap by moving the hand toward the base's wrist. It is off by default, for two reasons:
- The headset's wrist estimate is part of what the sensors are there to replace. Pinning to it trades measured joint angles back for the estimate they were meant to improve on.
- The hand is moved without re-solving the forearm, so the entire discrepancy goes into one bone. As Pin weight approaches 1, the forearm renders visibly stretched.
Turn it on when contact matters more than the arm's own kinematics — reaching for a physical target, where a visible gap between hand and object is worse than a few degrees of error further up the chain. Only hands you actually overrode are affected.
What ends up in the CSV
The composite writes a combined pose, so the recorded skeleton is the one you configured: base positions throughout, override rotations where you assigned them.
The composite builds its pose on Unity's humanoid skeleton, which is coarser than LABO's joint list. Joints it does not distinguish — Scapula against Shoulder, and the foot ball — are recorded as pass-through links carrying no rotation of their own, with the segment's full orientation on the joint that does exist.
For most analysis this changes nothing, since the segment orientations are all present. It matters if you specifically need a source's own separation of those joints — a headset reports a distinct scapula and shoulder, and the composite's CSV will not.
A composite owns its sources, and they do not appear as rows with their own Data Capture toggles — the composite is the row, and its CSV is the only one the arrangement produces.
To capture a source's unmodified stream, run it in its own tracking row in a separate session.
Recording both at once needs the source to support two connections, which a UDP stream does not on one port — a port can only be bound once, so a second UDP row pointed at the same port fails to start. If you need the raw and combined streams from the same run, have your sender emit to two ports and give the second row the second port.