Remove tracker polarity tracking

[ButterscotchV]

Moving on from #1343

It turns out, there is no possible way for this code to function. Quaternions have a rotation limit of 360 degrees, and even assuming a limited joint rotation of 180 degrees, it would take a mere 2 joints to hit the limit of our precision... We cannot feasibly track rotation this way, we would be better off tracking local rotations on the skeleton and assuming positive rotations (180 degrees joint limit), then comparing between joints, reaching the maximum 360 degree limit. I don't think it's actually possible for the human body to go beyond 180 degrees for any joint, but if we wanted to, then we could go even further and use either skeleton constraints or temporal tracking within the local rotations.

tl;dr: It's not reasonably possible to track rotations globally

This PR is just a simple removal of polarity tracking from quaternion moving average stuff. Currently, smoothing and prediction both still technically track the polarity, but this is how it was initially and it should be fine anyways.

[Erimelowo]

I don't think it's actually possible for the human body to go beyond 180 degrees for any joint

This whole thing was for fingers since they do and will.

And how is it a problem that quaternions can only track 360 degrees? We can just loop after that. Moving a tracker 720 degrees looks just fine

[ButterscotchV]

I don't think it's actually possible for the human body to go beyond 180 degrees for any joint

This whole thing was for fingers since they do and will.

And how is it a problem that quaternions can only track 360 degrees? We can just loop after that. Moving a tracker 720 degrees looks just fine

In this case, we could probably track this for fingers specifically. The only issue is you would need to track the local rotation, not the global rotation, wouldn't you? I feel like I'm missing something very essential... I could just keep the polarity tracking as it is now because honestly it shouldn't affect anything else, but I've been racking my brain trying to figure out how it's supposed to work.

[Erimelowo]

It can also be useful for cases such as #1124

in my mind, the way polarity is tracked is like this

So it doesn’t actually matter that it does or doesn’t know how many 360s it has done. It just needs to (and do) know if it has gone over 180 degrees. If we don’t track polarity, going 270 degrees right or going 90 degrees left would be the same.

[ButterscotchV]

It can also be useful for cases such as #1124

in my mind, the way polarity is tracked is like this

So it doesn’t actually matter that it does or doesn’t know how many 360s it has done. It just needs to (and do) know if it has gone over 180 degrees. If we don’t track polarity, going 270 degrees right or going 90 degrees left would be the same.

I do see that, I guess just my main concern is what use does this have on a global tracker rotation? A global tracker rotation would include yaw, so if we turn around, would that not cause this polarity tracking to lose all significance? Or is it enough to have all the trackers within the same relative space for polarity tracking, like all being tracked after a full reset? I'm just trying to understand why it isn't working correctly (as seen from the "centaur" issues).

[ButterscotchV]

For now, I think we can just leave polarity tracking as-is... It shouldn't cause any issues, we should be able to handle unknown polarity. I will make a new PR for the unrelated changes I've made here along the way, as they are useful improvements and tests. I may re-open the other PR at a future point when I can re-explore the issue, as we should be able to do something about polarity tracking.