Camera Tracking

Camera tracking allows the position and lens characteristics of Camera objects to be driven by the values of a real-world camera, allowing virtual scenes to be rendered from the camera’s point of view. This is particularly important for XR and VP workflows.

Disguise Designer has integrations with many different camera tracking and automation systems. See automation driver index for a list of available drivers. These can be used to apply tracking data to the positional and/or lens properties of a camera.

Workflows

Add a tracking source to a camera

1. Under Devices add a PositionReceiver.
2. In the PositionReceiver under Drivers, add the relevant tracking driver and set it up to receive tracking data.
3. Engage the position receiver.
4. Create a Camera in the Stage.
5. Under the Camera’s Settings, select the tracking source. This should have been automatically generated by the driver once tracking data started to be received.
6. Data from the Tracking Source should start overwriting the values in the camera.

Note

Values received from the tracking system may not align with the Designer coordinate system, unless the tracking system has been calibrated to achieve this. Designer provides a spatial calibration workflow which can be used to align positional and lens tracking data with the positions of LED screens represented in Designer.

Toggle values applied from the tracking source

1. From the Camera, open the Tracking Source editor.
2. Expand the Values section.
   • Values highlighted in green are being received from the tracking source.
   • Values with a dark grey background are not being received.
   • Values with a light grey background are received but toggled off.
3. Untick the checkbox to stop the value being applied in the camera.
4. Tick the checkbox to apply values again.

Toggle receive time smoothing

To toggle receive time smoothing, check or uncheck the Smooth receive time box in the tracking source. Turning this one should result in smoother tracking data, but may add a small amount of latency.

Troubleshooting

FAQs

What should I do if the logs contain ‘Attempted to access tracking data beyond end of buffer’?

We dynamically adjust the point at which we look back in the buffer to find smooth data, based on the history of tracking data receive times. You may occasionally see this message if tracking data comes in later than expected. You should find that the message stops after a second or two as the buffer lookup updates dynamically to account for the latest data. If this error appears constantly, then most likely the incoming tracking data is not reliable. Double-check the sender device and network routes to resolve the problem. If the issue persists, please take a Device Recording and send it to Disguise support for further investigation.

How do I read the tracking smoothing graph?

New tracking smoothing graphs have been added to help debug tracking issues. The lines in the graph can be interpreted as follows:

• Lookup offset. This is the time in ms between the smooth tracking data we are looking up and the latest data received. This should almost never go below zero, as that would mean we received tracking too late to be able to smooth it. If it is consistently much greater than zero, that means we are adding unnecessary additional latency while waiting to receive smooth data.

• Index delta is the change in index of the tracking data we look up in the buffer each frame, e.g. if the tracking frame rate is twice the frame rate this would be around 3. The smoothness of this line shows the success of the receive time smoothing - we are aiming for a consistent index offset between each packet of tracking data we look up.

• tReceived delta is the change in the receive time of the tracking data each frame. This shows us how smooth the tracking data would be without receive time smoothing - it can be compared against the index delta line to check that receive time smoothing is working.

• Instantaneous smooth data delay tells us how far we would have to look in the buffer to ensure we have received tracking, based on the latest received packet. This is aggregated over time to give a stable lookup time.

• Local smooth data delay is a maximum over time of the instantaneous smooth data delay, for this machine. It shouldn’t change often.

• Global smooth data delay is the maximum smooth data delay over all machines, which is particularly relevant when we are redistributing tracking data across machines. It should provide a consistent period to look back in the buffer to ensure we have smooth tracking data.