The UDP Stream
The UDP provider takes body pose data from anything that can send it over the network. No vendor SDK, no LABO-specific library — if you can open a UDP socket and write numbers to it, you can drive an avatar in LABO.
That makes it the way in for:
- Your own sensors. Inertial suits, custom hardware, anything with its own driver.
- Your own processing. Pose that comes out of a biomechanics pipeline, a machine-learning model, or an analysis script.
- Recordings. Replay a session from CSV, so you can build and test a scene without a participant or hardware present.
- Another machine. The sender does not have to be the machine running Unity.
How it fits together
your sensors, script, or recording
│ UDP packets
▼
LABO — UDP provider on the Body tab
│
▼
avatar, gizmos, Body CSV
Once pose data is inside LABO it is treated like any other source. It drives avatars, draws gizmos, takes part in Fusion, and is written to the Body CSV the same way headset tracking is.
Start here
The fastest way to see it work is the bundled sample. It ships a recording and a Python sender, needs no hardware and no Python packages, and takes a couple of minutes:
Do that first even if you intend to write your own sender. It gives you a known-good reference: once the sample animates a character correctly, anything that goes wrong with your own data is your data, not the setup.
What's in this section
- Settings — every option in the UDP row, and what to set it to.
- Wire format — what a packet has to look like, so you can write a sender.
- Coordinate frames — the four settings that decide whether the pose lands correctly, and how to work out what they should be.
- Python setup — installing Python, picking an editor, and what the scripts actually need.
- Running the sample — importing it, moving it out of your project, and running it.
- Troubleshooting — nothing arrives, or it arrives and looks wrong.
Partial sensor sets
You do not need a full suit. LABO's channel map covers 17 body segments, and a sender that has fewer sensors sends a zero for the segments it does not cover — those joints simply stay untracked while everything else works normally.
The practical consequence: the default channel map is correct whether you have six sensors or seventeen. A trunk-and-one-arm setup lands on the trunk and arm joints, not on the first six slots of the map, and needs no reconfiguration. See Wire format for how a sender declares which segments it has.