FreeD Protocol — ±180° Pan Angle Hard Limit¶
CGI Motion Open All rigs BOTH
Summary¶
The FreeD protocol encodes pan angle as a signed value with a hard limit of ±180°. When a rig performs a continuous pan move that crosses the ±180° boundary (e.g., panning from 170° through 180° to 190°), the FreeD output wraps or jumps to the opposite extreme. The virtual camera in the receiving VP application flips or snaps to the wrong orientation for the remainder of the move. This is a protocol-level limitation, not a Flair bug, and there is no workaround within Flair itself.
Symptoms¶
- During a long pan move, the VP virtual camera suddenly flips to the opposite direction
- The flip occurs exactly at the ±180° pan boundary
- All other axes (tilt, roll, XYZ) continue correctly
- The physical camera moves smoothly — only the VP tracking breaks
Root Cause¶
The FreeD packet format allocates a fixed-width signed integer field for pan angle. The field can only represent values from −180° to +180°. When the rig's physical pan exceeds this range:
- Values above +180° wrap to −180° (and vice versa)
- The virtual camera appears to instantaneously snap to the opposite side of the scene
This is an inherent limitation of the FreeD protocol specification and cannot be fixed in Flair's FreeD output module without breaking compatibility with all receiving applications.
"The FreeD protocol has a hard limit of ±180° on pan. There is no workaround in Flair — it is a protocol limitation." — Simon Wakley (paraphrased)
Workarounds¶
Workaround A — Avoid crossing ±180° in the move¶
Design the shot so the total pan travel stays within ±180°. Re-zero the rig so that the pan range used by the move is centred around 0°.
Workaround B — Use OSC instead of FreeD¶
OSC (Open Sound Control) output from Flair sends camera data as floating-point values without the ±180° constraint. If your VP software supports OSC input, switch to OSC for continuous pan moves.
See NET freed unreal setup for OSC setup details.
Workaround C — Post-process the FreeD data¶
Some operators unwrap the pan angle in a middleware layer (e.g., TouchDesigner, a custom Python bridge) before forwarding to the VP application. The middleware detects the wrap event (a sudden jump of ~360°) and adds or subtracts 360° to reconstruct the continuous value.
No official fix
As of 2026-05, MRMC has not released a FreeD replacement protocol that removes the ±180° limit. The issue is tracked but there is no scheduled fix date.
Affected Scenarios¶
- Continuous pan turntable moves (object rotates more than 180°)
- Very wide pan tracking shots that start and end on opposite sides of a stage
- Roll Up moves with large pan travel
WhatsApp Excerpts¶
"FreeD has a ±180 degree limit on pan — if you pan past that it wraps around and the virtual camera flips." — Community discussion (multiple confirmations)
"Simon confirmed it's a protocol limitation, not something Flair can fix on their end." — Tom D (paraphrased)
Related Issues¶
- See also: FreeD / OSC Data to Unreal Engine, Aximmetry, or Disguise — Setup and Pitfalls — Full FreeD / OSC network setup guide
- See also: FreeD Output Sends All Zeros — Wrong Output Type Selected — FreeD sending all zeros (wrong device type)
Related Tutorials¶
Official Documentation¶
Revision History¶
| Date | Change | Editor |
|---|---|---|
| 2026-05-24 | Initial extraction | Tom D / Claude Code |