I’m developing an AR application using Unity’s ARFoundation 5.1.1.
The application consists of several scenes and the flow is roughly as follows:
Startup
nonARScene
ARFaceScene
nonARScene
ARImageScene
When I set the LightEstimation in ARImageScene to Everything, the rear camera will be enabled in Android, but the front camera will be enabled in iOS When the LightEstimation is None, the rear camera will be enabled in Android, and the front camera will be enabled in the first frame in iOS.
When LightEstimation is None then Android enables the back camera, in iOS it enables the front camera in the first frame, but after that it becomes the rear camera.
Why does using LightEstimation cause the ARImageScene to enable the front camera instead of the expected back camera?
Just to make sure I understand correctly, you are expecting both iOS and Android to have the rear camera be used for your ARImageScene from frame 1 correct? and within your session camera config for that scene, you are specifying that you explicitly want the rear camera?
one thing I am curious about is if you are able to determine easily, that if you modify your flow to be the following:
Startup
nonARScene
ARImageScene
… do you get the same behavior on iOS? in other words, could the inclusion of the ARFaceScene (which I expect uses a front facing camera) be somehow leading to this behavior?
One thing that we can easily try would be to spoof the same flow using the ARF samples. I will check this on our end as well. If it works with the samples, then perhaps we can narrow down from there where the issue lies.
I did a test run of AR Foundation samples with the following flow order:
Main Menu
Face Tracking/Face Mesh
Main Menu
Camera/Basic Light Estimation
and I did not witness the front facing camera engage. You will perhaps see a black screen background prior to the pass-thru kicking in on the light estimation scene however. See if you are able to get a similar result, and compare the code execution of your scenes against how the sample configures and shuts down its AR sessions on ARKit.
Sorry for the late reply, I’ve created a repository to reproduce the issue via GitHub:
In this repository has 3 AR scenes:
image scene for ARTrackedImageManager.
plane scene for ARPlaneManager.
face scene for ARFaceManager, the iOS required setting ProjectSettings - XR Plug-in Management - AppleARKit/FaceTracking is already set to true.
If I set the image scene ARCameraManager.LightEstimation to None, everything works fine, but once I set it to Everything, it will automatically use the front facing camera by default.
Thank you for sharing a reproduction project. I will take a look at it and see if I can spot what might be the issue here.
Given that configuration modification can lead to occasional unexpected changes to camera selection, this might be a reason if the session is not completely new, and starting from a known default configuration state.
AR Foundation’s default configuration chooser chooses a session configuration for you based on the features that you request. Changing the requested features can cause a session configuration change. You can customize this behavior, and it looks like you should in this case.
This is in our technical writing team’s backlog to document better, and some day I would like to revisit these API design choices from the previous AR Foundation team, but any such code changes are not a priority for us at the moment.
I also used light estimation in another project, but this problem did not occur.
The obvious difference between the two projects is whether the Face Tracking option is checked in Project Settings. This problem occurred for projects with this option checked.
So there is definitely an issue here, and the reason for the issue is exactly as @andybiar has described. When choosing “everything” for light estimation, the “behind-the-scenes” configuration choosing mechanism which attempts to satisfy all requested features, is overriding the requested camera direction.
However, if I individually select light estimation features – such as ambient color, intensity, main light direction, etc. then it respects the rear facing camera choice. So we at least have a workaround that you can use for your project.
My recommendation would be to file a bug. As Andy mentions, the priority for this is not high at the moment when weighed against other bugs and features, but having the bug filed makes sure that the issue is tracked and looked at – and we can definitely improve the messaging of this behavior through better documentation.