Solver Marker Validation

[FlantasticDan]

• [ ] Solver errors too late in the event one set of tracker data has no corresponding marker in the other (i.e user tracker name typos).

• [x] Solver should be able to select relevant tracks of the same joint which follow the joint.## pattern.

[FlantasticDan]

The solver now solves points of a specific joint according to the following priority:

1. The first (joint.01) track from both cameras.
2. The same exact track (joint.02, joint.03, etc...) from both cameras.
3. Differing tracks from the same joints from each camera (joint.01/joint.02 or joint.02/joint.05, etc.)
4. No solve for the current frame.

Improvement

The new implementation leads to glitches in the solve as the markers jump from track to track. It would be smoother if rather than jumping off of the primary (joint.01) track, the subsequent tracks were paired to provide offset data for frames which are missing the primary track. This would require an overlap of at least one frame wherever the primary track becomes unavailable.

[FlantasticDan]

Changes

For frames where data cannot be calculated based off of the primary track(joint.01) from both cameras, an offset based calculation of other related tracks will be used to translate the primary track according to the aforementioned track selection priority.

Exceptions

Errors result frequently because the markers selected for cross check happen on the current frame irrelevant of what happened on the last frame. Should the previous frame be unable to satisfy the current frame's ideal markers a KeyError results.

Fix

Force users to overlap primary tracks with secondary tracks on tracker export and potentially warn users when a tracker export may necessitate using a third priority track selection.

• Validate overlapping data inside Blender as part of the tracker export
• Suggest users track ALL viable markers for every frame for redundancy