thank you yet again for testing our ARKit beta. I'm afraid the only answer I can give you in regards to this issue is very similar to what I answered in response to your other reports. Which is, that we are aware of these issues and are working on resolving them. They should not be present in the final release of our ARKit integration.
Both of the issues have the same root cause, actually, which is, that shutting down an AVCaptureSession can take a while. In line with Apple's documentation, it can take several seconds; not always, but sometimes. These seconds of stopping the capture session are when you are being presented black frames.
Since we cannot, when starting the SDK, know if, and if so, when an ARKit enabled InstantTracker is being created, we need to proceed under the assumption that such a tracker will not be present and therefore start a capture session ourselves. If the assumption does not hold, and such a tracker is created, we need to shut down our own capture session and let ARKit take over. As I've already mentioned, that can take a couple of seconds.
The flickering you referred to happens if the ARSession manages to grab camera frames before the stopCapturing call finishes. When this call finally does complete, it seems to mess with ARKit's ability to continue acquiring frames from its own capture session, causing it to fail and requiring us to restart the tracking.
Since we have a limited set of testing devices, it's good to know that these issues occur on other devices and OS versions as well.
I thought it might be something like this. I for one would be very happy to specify that we'll be using ARKit at the iOS view controller layer in order to make sure certain we don't need to shutdown a capture session. So maybe something like
self.architectView.requiredFeatures = WTFeature_UseARKitIfAvailable;
My testing device so far is an iPhone 7 running iOS 11.1.1
I'm also seeing this issue. Sometimes it takes more than 5 seconds before the camera view appears. Looking forward to a fix. Let me know if there's anything I should be doing in the meantime.
Good morning David and Gabriel,
of the things currently still amiss with the ARKit implementation I consider this to be the most pressing. I'm currently working on it and I hope to have a fix for it soon. I'm not sure yet what the fix will look like, though.
I don't believe there is any way for you to bypass this issue, I'm afraid. This requires internal fixing.
Just checking in, has there been any progress made on a fix for this issue? Or on a different approach to specifying that an experience should use ARKit ? We'd happily try it out if there has been!
by now we have implemented a fix for this issue. The actual problem seemed to have been slightly more nuanced than what I outlined previously, allowing for an internal fix.
The fix has been in place for a while now and I have not seen the black screen issue since.
When using the Wikitude 7.1 ARKit Beta we've noticed a black screen instead of the camera view, sometimes lasting for several seconds when an experience starts.
This seems most pronounced after exiting and re-entering a Wikitude + ARKit experience or under low light conditions.
There are some instances where we see the camera view for a few moments, and then the screen flickers black. Not sure if this is the same issue or not.
We see these issues in the included SDK example application.
2 people have this problem