Partially fixes #93, fixes #311.

Enable HMD position tracking based on ARCore's motion tracking capabilities. Note that this only works on devices that support ARCore; see the official list for more information. (All devices on this list are supported, regardless of depth API support/camera resolution. Tracking accuracy may vary.)

Performance looks to be pretty good, though I am testing this on a Samsung Galaxy S23 which is pretty much a best-case scenario. The device does heat up after a while, but from what I've heard that's pretty standard for ARCore. However, as of writing, it's not stable enough yet to be actually used, which is why this PR is marked as a draft.

I'm opening this PR to get some feedback and perhaps some help with development. Here's a general TODO list:

• Add user-side toggle for enabling/disabling ARCore-based tracking (right now it's enabled by default)
• Add user-side settings for ARCore (whether to use orientation data from Cardboard or ARCore directly (not recommended unless I can work out the delay, see later comment), camera FPS limit, filtering to camera configs without depth support/with lower resolution for processing power/accuracy tradeoff, etc.)
• Figure out orientation drift. The orientation (rotation) that we get from the Cardboard API drifts away from the ARCore tracking orientation over time, so e.g. walking forwards starts moving sideways instead. Using the orientation data from ARCore itself solves this, but also introduces a ~0.5s delay which is very noticeable. I don't think there's a way to reduce this delay - it's just a side effect of how ARCore works, and is probably going to be worse on weaker devices. The solution would likely be to somehow adjust the orientation to match the one that ARCore reports...?
  • Occasionally when ARCore loses tracking it will "teleport", i.e. the position will be shifted; I think this could be related to the repositioning behavior described in the Pose docs. This completely breaks orientation when it occurs, so fixing the above would probably fix this too (in fact, I'm willing to believe that it's the same issue).
• Figure out pose scaling. Currently the actual speed of movement is a little out of wack, we will probably need to scale the values from ARCore. I've done some more testing and I think it's actually fine, but someone with more VR experience would need to test.
• Figure out altitude. Right now it seems to be wrong (maybe it just needs scaling? or maybe it's picked up from the first plane it identifies), so you'll usually end up clipping through the floor or just generally being very low. The ARCore geospatial API has the ability to get altitude data, but it must use Google's location APIs which is privacy-intrusive and has a ratelimit. I was also considering using the phone's barometer sensor and a short calibration process before each play session to determine the floor position and what scaling to use for anything higher than it, but I'm not sure if that's actually possible + wouldn't work on phones that don't have a barometer/pressure sensor.
  • This is done! The solution I went with is to find the lowest-placed plane and place an anchor on it; this way we can track the Y position of the floor, then subtract it from the headset position. While working on this, I also found out that ARCore's world space is based on the position of the device when the session is set up, so placing the device on the floor while turning on PhoneVR works best (but this also works very well once it gains tracking, so the UX is at least somewhat nice).
  • I did have a WIP patch for barometer-based tracking, but the barometer values were very jittery, and to smooth them out accurately and maybe include data from other sensors for extra accuracy, I'd probably need something like a Kalman filter. Unfortunately I do not know enough maths to actually implement one, so that's left as an exercise to someone more knowledgeable than me.
  • We could probably add a setting to force a specific altitude.

I saw somebody say that iVRy supports ARCore-based tracking (personally I didn't know that, I'd have to check) - if that's true, it'd be interesting to see how they tackle some of these problems.