acceleration weirdness

[Chovin]

from what I remember, there's not a reliable way of deriving position from acceleration data as sensor drift starts adding up quite a bit. Currently I try to tackle that by taking a weighted rolling average of sorts of all accelerations and considering that our "drift". I subtract the drift from the current value to get what it "should" be. There were still drift issues with this if I recall and needing to recalibrate whenever I moved a step to the side or passed the controller to someone seemed annoying, besides the view plane is supposed to be the player's view, not their absolute position relative to some stationary place in the world. This made the acceleration feel pretty unnatural though, players would keep extending their arms further in one direction to try to keep their saber in that spot.

I'm not sure of a solution to this, but I wanted to try some things.

1. ignore tiny movements. This may be enough to handle drift, but I worry it may make the saber feel unresponsive
2. don't weight the average to more current values
3. use the average acceleration of queued phones as a baseline, or even a phone on the player to anchor the view plane to them while being able to tell how far the saber is away from it. This may not be a viable solution at all however as I'm pretty sure having multiple sensors only helps eliminate drift if we know exactly how far away they are from each other.

[Chovin]

wanted to try calibration for acceleration, although I've been avoiding it to reduce friction for players from starting the game and also avoiding needing to recalibrate or deal with incorrect calibration or change in player's resting stance and/or position relative to the game screen. It looks like having some calibration session during a tutorial might be good for the upside down/backwards phones anyways though