mozilla-mobile / webxr-ios

An iOS app for testing WebXR
Mozilla Public License 2.0
211 stars 42 forks source link

We should reset the ARKit origin each time a session is started #132

Closed blairmacintyre closed 5 years ago

blairmacintyre commented 5 years ago

We don't need to restart ARKit. Rather, we should be able to just use setWorldoRigin https://developer.apple.com/documentation/arkit/arsession/2942278-setworldorigin

There is a question in my mind as to if setting World Origin overrides aligning with heading and gravity. Hopefully they will work together. There is some info here about making things reset properly, that might be useful regardless (when we come back from sleep, etc).

This post has some info on resetting the world to ensure it's oriented with north https://stackoverflow.com/questions/45803884/arkit-how-to-reset-world-orientation-after-interruption

blairmacintyre commented 5 years ago

We may literally want to restart ARKit. We need to keep it alive, but #158 should essentially restart it with each "request session"

robomex commented 5 years ago

Testing with the examples doesn't lead to much drift, so I'd like to expand upon this issue here before committing a potential fix.

It sounds like what's desired is re-running the session with the options .resetTracking and .removeExistingAnchors for all "request sessions" (i.e. all loads & reloads). If we were to only .resetTracking, this could lead to e.g. scanning my desk, putting the phone down to debug, while my phone is sitting on my desk the origin drifts and now I have a phantom scanned desk floating behind a wall in addition to the rescan of my desk – hence the need to .removeExistingAnchors as well.

If the above sounds right, I believe the trade-off entails us "losing" carrying world maps & scanned planes from page to page (i.e. we lose the current behavior of scanning planes upon visiting the first WebXR site after app launch and then utilizing that map/those planes/that scan across multiple subsequent WebXR pages).

In exchange for that loss, we're "gaining" a reduction in issues related to origin float/coordinate system drifting, and also a reduction in issues related to anchors "disappearing" yet showing up again after killing & restarting the app.

Let me know if the above sounds correct.

Furthermore, in looking into the above I found a bug that results in disappearing anchors. To reproduce:

Planes/anchors don't disappear in the similar sessionInterruptionEnded. I'll continue investigating in the morning and will file an issue then.

blairmacintyre commented 5 years ago

I think you're right; essentially, we want to do the equivalent of "completely reset tracking" fairly regularly. Something that's more or less equivalent to shutting down ARKit and restarting it.

I understand the "loss" of losing maps and planes; I think we need to go back to that more often.

In #158, I was suggesting a middle ground. We don't necessarily do a complete reset EVERY time, but rather do it on a "requestSession" if it's been more than a certain time since the last time we did it. And, if it's in the process of relocalizing, and we get a requestSession, we should re-start too.

I think these would be a reasonable first step. On requestSession:

Let's see where that gets us.