We have been experiencing an odd glitch in our tracking data on occasion in v5.3.2. First caveat is that we haven’t noticed this in previous versions of UE, but that isn’t to say that this glitch hasn’t happened before. It happens very quickly (over the course of a frame or two), relatively infrequently, and not in every project.
Attached are two images, labelled “before” and “after”. In the “before” image, you can see the rotational values of the camera the frame before the glitch occurred. In this particular take, the camera was a lock off, so these rotational values had been keyed up until this moment and continued after the glitch auto-corrected. In the “after” image, you can see that the rotational values only snapped to different values on all 3 axes (with the Z-axis being the most affected) and then auto-corrected back to the actual position.
Our data flow looks like this: Motive tracked rigid body → WVcam for IMU fusion → UE via LiveLink.
Because we do not see translations being affected in this glitch moment, we feel confident ruling out any marker occlusion or “usual” mocap interference. If this was the culprit, then we would expect to see translational data affected as well.
We also don’t think that the issue is stemming from WVcam, the IMU fusion software. If the IMU was receiving interference, then we would expect to see more high-frequency noise, or more than a single frame of glitch.
To note here: This doesn’t happen in every project that we have in v5.3.2, per se, and in the course of a shoot day, it may happen once, not at all, or a few times and then stop. This take from which these screen grabs were taken was the only time this happened on that shoot day. Back in March, we had a show where the glitch didn’t happen on the first shoot day but happened multiple times on the second (same UE project, different levels), both when the camera was static and when it was moving.
Because the glitch happens at a single frame and then reconciles on all axes for same amount of time (with what appears to be an automatically generated type of curve), we feel like the logical place to look to is LiveLink. Could a momentary data packet loss cause something like this? Or a rounding error in the curve data? Has this sort of issue been reported already?
Any insights would be valuable. In the mean time, because it’s such a hard thing to catch, we’ll have to rely on analyzing data that we happen to record during a shoot.
