As the title suggests, the ARSession.NotTrackingReason is never Relocalizing on iOS (ARFoundation v5.1.5). I’m asking if this is expected behavior, or if there is an explanation to this.
As per the ARKit documentation, the available reasons are:
initializing
relocalizing
excessiveMotion
insufficientFeatures
Relocalizing:
The AR session is attempting to resume after an interruption.
This never occurs under any circumstance, even when:
→ applicationDidEnterBackground()
and
→ applicationWillEnterForeground()
I wouldn’t expect the tracking reason to switch to relocalizing when the application is resumed from the background – this is indeed an initializing state.
I double checked our plug-in code, and it looks obviously correct to me. (It’s about 10 lines of Objective-C). Therefore I conclude that you are observing the expected behavior of ARKit.
At first I made your response the solution, but I’m now fairly certain that this isn’t right.
Contrary to what you said, the tracking reason should be Relocalizing when the app resumes from the background, unless sessionShouldAttemptRelocalization is implemented and returning false.
Could you still check this and confirm? I trust that ARKit is reporting the correct tracking reason, however the behaviour depending on the implementation of sessionShouldAttemptRelocalization.
[Edit]
Since ARKit is able to relocalize within the first few seconds, I’m guessing sessionShouldAttemptRelocalization is not implemented and ARKit simply does not report the tracking reason as relocalizing. If this is the case, this may be more of a feature request for the ARKit plugin, but anyway confirmation would be great.
Our plug-in does not set sessionShouldAttemptRelocalization. If you have further questions, I recommend downloading a sample ARKit app from Apple so you can compare against the ARKit ground truth.