0

I have next code:

    guard let feauturePoint = frame.hitTest(normalizedPoint, types: .featurePoint).first?.worldTransform else {
        return
    }
    let anchor = MyAnchorSubclass(transform: feauturePoint, plus: someAdditionalInfo)
    arSession.add(anchor: anchor)

This function creates and adds object of my subclass of ARAnchor. Then...

    func renderer(_ renderer: SCNSceneRenderer, didAdd node: SCNNode, for anchor: ARAnchor) {
        guard let anchor = anchor as? MyAnchorSubclass else { return }
        anchors.append(anchor)
        /* then goes some my logic with adding SCNNode */
    }

... after anchor was rendered, I'm adding my SCNNode there. But, when I'm using anchors.append(anchor), where anchors is [MyAnchorSubclass], scene freezes right after 14 added anchors. If I'm not saving anchor in array, scene view does not freezes.

Does anyone know what is it? iOS 11 Beta bug or some kind of limitations?

UPDATE

Last, what happens - is renderer(_:didUpdate:for:) being called and after it scene view freezes and few [Technique] World tracking performance is being affected by resource constraints [0] messages appears in log.

UPDATE 1

Interesting fact: after app goes to the background and returns back, sessionWasInterrupted(:) and sessionInterruptionEnded(:) being called, even though scene view was freezed before.

Vasilii Muravev
  • 3,063
  • 17
  • 45
  • Never hurts to [file a bug](http://bugreport.apple.com) just in case. On a quick read, I'd also guess there's some danger that your anchor subclass is (perhaps indirectly) holding onto some resources (like the camera pixel buffer) that ARKit is expecting to recycle. Also, have you pinpointed where in your code the freeze begins, e.g. by stepping in the debugger? – rickster Aug 02 '17 at 20:21
  • @rickster Can't tell you on which exact moment does it freezes. But if happens after `renderer(_:didUpdate:node:for anchor:)` is being called. And after it I see few `World tracking performance is being affected by resource constraints [0]` messages. – Vasilii Muravev Aug 02 '17 at 20:29
  • Are those log messages > [Technique] World tracking performance is being affected by resource constraints [0] …appearing _after_ the session failed, or also before? – PDK Aug 07 '17 at 14:13
  • @PDK `appearing after the session failed, or also before` - after – Vasilii Muravev Aug 07 '17 at 14:27
  • @VasiliiMuravev Kind of not related but would you know the [difference of using ARAnchor instead of adding an SCNNode directly](https://stackoverflow.com/questions/47460372/difference-of-using-aranchor-instead-of-adding-scnnode-directly)? – Francescu Nov 23 '17 at 17:25

2 Answers2

3

Ok, your issue is, you don’t want to be maintaining your own array of the anchors. You want to be maintaining an array of the identifiers (UUID) of each anchor. In Apple docs:

Anchors are considered equal based on their identifier property.

Reason being, ARKit calls init(anchor:) on a background thread to copy instances of your anchor class from each ARFrame to the next. In storing an array of each ARAnchor you are only holding-on to one set of instances of those anchors in time, that would otherwise have been discarded by ARKit.

With your array of UUIDs of the anchors, if you need to reference one, iterate through the anchors in the session for the current ARFrame, searching for the UUID of the one you need to do something with.

You could use something along the lines of:

func anchorForID(_ anchorID: UUID) -> ARAnchor? {

    return session?.currentFrame?.anchors.first(where: { $0.identifier == anchorID })

}
Geoff H
  • 3,107
  • 1
  • 28
  • 53
0

Does anyone know what is it? iOS 11 Beta bug or some kind of limitations?

Please implement the callback session(_:didFailWithError:) so you can see what ARError is returned when your ARSession fails—causing your screen to freeze.


NB. if you receive the Code=200 "World tracking failed." I would very much like to know, because I'm diagnosing that over here.

PDK
  • 1,476
  • 1
  • 14
  • 25
  • In my case session doesn't fail. It just freezes. – Vasilii Muravev Aug 07 '17 at 14:31
  • My view froze, but I noticed the app hadn't crashed, so I implemented `session(_:didFailWithError:)` and then I noticed the freeze happened the moment the session had failed. Can you confirm that you have it implemented and it doesn't get called when it freezes? (If so, that's a serious bug on Apple's side then—so then you should file a bug report for sure) – PDK Aug 07 '17 at 14:51
  • `session(_:didFailWithError:)` doesn't being called. And after you're going to the background and return back, everything starts work again. – Vasilii Muravev Aug 07 '17 at 15:43