Good morning again David,
I agree, that such a callback would be useful, especially for the use case you have mentioned since I cannot come up with a viable workaround.
Our major concern, however, for the time being, is to have a minimal ARKit integration for the existing AR.InstantTracker interface, changing only what is strictly necessary. For the final implementation, we intent the ARKit implementation to be fully and conveniently usable.
I took a note of your feature request and will bring it up when relevant.
Thank you very much for taking the time to try our beta implementation and provide feedback.
- Daniel
Daniel,
I agree with David - it would be great to have this callback. In the meantime, is there a way to not throw the alert box? That way I could check if tracking worked, and use that in a loop.
Gabriel
Good morning Gabriel,
there certainly is. The message box is explicitly created in the sample code; the SDK itself just informs you of the failure to perform the requested state change.
In case you are using the JavaScript SDK, simply remove the alert call from the onChangeStateError callback. In case you are using the native SDK remove the UIAlertController from the instantTracker:didFailStateChangeWithError:andMessage delegate function.
My guess is, though, that constructing a workaround based on a loop will not quite be want you want since you cannot, currently, query the viability of state change without actually changing the state, which you most likely will want to be initiated by the user.
Thank you for testing the beta release and giving feedback in any case.
- Daniel
Good morning David and Gabriel,
just wanted to inform you that updated versions of the ARKit beta release have been published. The issues that have been reported should be fixed and the requested API implemented. ARCore is now available as well.
As always, they can be downloaded here under the Beta tab.
- Daniel
Great news Daniel! I've been playing with it this morning and the improvements on the iOS side are very evident!
What is the new API for the callback when tracking becomes available ? I haven't spotted it (yet) in the JS api doc
Thanks!
-Dave
Hello David,
glad to here our fixes are working for you.
The reason you cannot find the API is that we have not yet taken proper care of the reference and documentation yet. It should, however, be used in all of the instant tracking samples; look for canStartTracking.
The function performs a single hit test internally (the same as when actually switching the state) and informs you about its success. Combined with setInterval, you should be able to achieve what you've been asking for. The samples, in fact, do just that.
- Daniel
Looks good! Does this API work for non ARKit experiences as well ? I guess we'll find out soon enough :)
-Dave
It does, but since (at least currently) it's always possible to switch to tracking state using Wikitude's instant tracking algorithm, canStartTracking always returns true. But there's definitely no harm in including the check.
- Daniel
David Hakim
In the new Wikitude 7.1 Javascript ARKit beta there is a callback we can set on the InstantTracker if there is an error transitioning to the tracking state
This could be improved upon if there was a callback while in the initializing state that fires when tracking has switches from impossible to possible or back. This would allow a UI where we disable the play button or gray out the crosshairs when the user is pointing at an untrackable surface and only enable them once we know tracking will be successful rather than presenting users with an error message only after they attempt to start tracking. A feature like this may be possible when ARKit is in use by attempting a hit test with every frame
2 people like this idea