Resolved Paradigm for Managing ARSessions & Plane Data — ARF 3.x to 4.x Changes

So I've been updating a project which was using ARF 3.x to ARF 4.x because we want access to some of the more recent ARKit features. The biggest "breaking" change that impacts our project is that destroying the ARSession object no longer destroys the underlying ARKit session but simply pauses it and unpauses when you make a new ARSession object.

We have several custom components which tie into the ARF objects. Chief among them is a system which takes the updated geometry via ARPlaneManager.planesChanged and performs a variety of operations on it to automatically lay out our game space. We previously loaded these objects at the same time as loading the scene containing an ARSession and ARPlaneManager instance, so they were able to keep track of every plane created, updated or destroyed. We maintain own list of "active" planes for various reason (partly to discard subsumed ones).

However, with the change from ARF 3.x to ARF 4.x we run into trouble the second time we run a scene. Any planes added during the first scene will not be "added" when running a second scene — they will only be in the "updated" list because the underlying session wasn't cleared. This conflicts with our internal list of active planes, which is currently cleared between scenes.

There are several ways I could try to hack around this, but I'd like to understand the intended paradigm and find the "correct" way to handle it. Here are some things I've considered along with concerns I have or issues I hit. Would love to know what the ARF team thinks on this.

Proposed Solution 1: "Pull" the current plane data from ARPlaneManager immediately when the ARKit session resumes and update our lists accordingly. Then our responses to the planesChanged event remain the same as before. Problems: I don't see any way to do this!

Proposed Solution 2: When responding to the planesChanged event, treat "updated" planes as potentially being "added" planes. That should clear things up on the first update when running our second scene. Problems: Have to wait for an update before doing anything. That's usually within seconds but it seems like bad form.

Proposed Solution 3: Keep our custom components loaded between scenes and simply regarded them as pausing/unpausing like the underlying ARKit session. Problems: These components depend on the events fired by the ARPlaneManager, which does not stay loaded, which means unhooking from/re-hooking into these events when scenes unload and load. Very messy.

Proposed Solution 4: Manually stop and start the session on unloading and loading scenes, as per the migration guide. Problems: I immediately started getting ArgumentNullException errors in UnityEngine.XR.ARFoundation.ARInputManager.OnEnable when I tried this, although probably there are some steps I'm missing. Possibly related: I'm not tracking whether or not it is the first run of an AR scene so I'm calling LoaderUtility.Initialize() each time on init, including the first. Can add this but it seems weird to start the first session differently from the rest...?

Proposed Solution 5: Manually call ARSession.Reset() on init. Problems: Actually, this seems to work for the most part! However, probably there is a chance of it mucking something up on the first run for the same reason as the last solution. Also, TBH, it feels like it is counter to the intended operation of ARF 4.x.

Proposed Solution 6: Make ARSession and ARPlaneManager objects — along with our own — be persistent and manually pause/unpause the session instead of unloading/reloading anything. Problems: Seems counter to ARF's design?

Would love to hear feedback as to which if any of these solutions are recommended for working with ARF 4.x. I'm trying to wrap my head around the intended paradigm here where the wrapper, ARSession, is ephemeral but the underlying AR session is persistent.

 

ARSession.Reset() should do the trick in your case.

But to be 100% sure, here is a method to start your AR scene from scratch. Official AR Foundation Samples repo also uses this method, but the following code will work both for ARF3 and ARF4:
https://forum.unity.com/threads/reset-ar-session.537261/#post-6581095