You can get the SDKExample 3d Model on Plane into this state by pointing the camera at a surface that is likely very hard to track e.g. a flat white ceiling and pressing the play button
My questions are
1) Is this a bug or expected behavior ?
2) Is there a way of detecting this state in order to transition my InstantTracker immediately back to the INITIALIZING state ?
I also have similar issue. It seems that when we start tracking (set state to TRACKING), if the camera closes to a surface (put it in the table but not hand over for example), the application will be crashed.
Please try our latest beta build, available here.
We're about to release the next major version of our SDK which also contains this fix.
I'll try. Thanks!
1) Run the SDKExamples that come with the iOS JS SDK .
2) Launch the "3d Model on Plane" example
3) Point at a hard to track surface like a blank white piece of paper
4) Press the play button
Instead of the crosshairs turning blue, sometimes they stay red which means (I believe) that we've transitioned the InstantTracker to the TRACKING state, but the InstantTrackable is still showing the initialization crosshairs and we're not actually tracking. I don't think augmentations can be added to the instant trackable in this state ... they cannot in the examples at least.
I would like to be able to detect this condition so I can immediately return the InstantTracker to the Initialization state and re-enable the play button.
The red crosshairs represent the initialisation phase of instant tracking. As long as the crosshairs don't turn blue, no tracking can be performed, meaning that no augmentations are drawn.
Do you implement the AR.InstantTracker onStateChanged callback? This one is called when the InstantTracker actually performed state changes. InstantTracker also have a state property. Maybe this one works for you to check in which state the tracker currently is.
So I log out to the console various state changes from both the InstantTracker and the InstantTrackable. What I see is in my logs is
2017-04-11 09:22:42.746668 ARDemo[5179:1785322] ### Wikitude event: state changed to 1
2017-04-11 09:22:42.752689 ARDemo[5179:1785322] ### Wikitude event: tracking stopped
The first message comes from the onChangedState method from the InstantTracker
The second message comes from the onTrackingStopped method from the InstantTrackable
I am currently monitoring onChangedState, onDisabled, and onError from my InstantTracker and onTrackingStarted and onTrackingStopped from my InstantTrackable. There are no other messages logged from any of these
Note the InstantTrackable.onTrackingStopped fires within about 1/100th of a second from when the InstantTracker starts tracking.
I will probably try to use this as an indicator of the scene being untrackable and reset the tracking back to the initialization state manually when I see this but it also sort of seems like a bug because of the way the initialization crosshairs stay permanently stuck on the scene when this occurs (video attached)
So the workaround I'm testing for this is
1) I keep track of the state change coming from the InstantTrackable in a local variable so I know at all times whether the scene is tracked according to the InstantTrackable
2) When the user presses play causing my InstantTracker to change state from INITIALIZING to TRACKING I set a timer to fire 0.3 seconds in the future
3) If by that time my InstantTrackable hasn't called its onTrackingStarted function I assume the user has pointed at a location that is effectively untrackable (I've been testing with the palm of my hand covering the camera). I then alert the user to re-point his camera and I reset the InstantTracker to its INITIALIZING state
Does this seem like an appropriate workaround ? Are there any issues you notice that I might run into with it ?
Sounds good so far.
Can you just quickly give me some more information with which API of our SDK you work? I'm afraid I lost track throughout your different threads and I want to make sure that I give you proper answers.