After reading this post by @Manos_Tsotros , I decided to try ARDK 2.3.0 myself. However, the test result was not satisfactory, since I am still getting around 20% FPS less with ARDK 2.3.0 vs ARDK 2.0.1.
I checked the Unity profiler with both ARDK versions in the same app. This is what I got for the same meshing scene, with an Adreno 650 device (meets ARDK’s system requirements) targeting 60FPS:
ARDK 2.0.1: stable 60 FPS, with the render thread spending most of its time in Gfx.PresentFrame, which, according to Unity’s doc, means that “the app is waiting for the GPU to render and present the frame, which includes waiting for VSync”. Looking at the CPU Vsync Usage, my understanding is that the app has plenty of time to render at those 60FPS.
ARDK 2.3.0: the app strugles with the 60FPS, and the Render Thread spents most of its time in Camera.Render/ARCore Update driver. Again, according to Unity’s documentation, spending time in the Camera.Render process means that “your application is CPU-bound and might be spending too much time sending draw calls or textures to the GPU.”
ARDK2.0.1 was using ARCore 1.14. Meanwhile, ARDK 2.2.0/2.3.0 are using ARCore 1.32. Do you think the ARCore upgrade could be the source of this problem? Any other ideas what might be causing this difference in performance?
Additionally, I am still unable to run ARDK’s contextual awareness features on theoretically capable devices, as I pointed out in this post. I mention it here just in case it also has some relation with this issue.
I will be taking a look at this performance issue and will be getting back to you once I have more information.
In the meantime, if you are running an ARDK example when you use the profiler, can you provide the example? If this isn’t an ARDK example, can you just provide the features that you were running? By the looks of the information you provided, you’re using Depth, is there anything else you’re using?
OmigariMeshColliderChunk is different from ARDK’s MeshColliderChunk. I can provide it if you need it. PaintableMaterialExternalMaskBuffer is not used by the component when meshing is performed, so it shouldn’t affect.
There are also networking managers in the scene, but they are not initialized during the scan. Other than a couple of UI elements, nothing else is loaded in the scene either.
I just made the discovery totally by chance, while I was working on a different thing, but I have no idea why that value might influence ARDK’s performance so much. I thought its goal was simply to define a minimum version for the Google Play Services for AR apk installed on the phone (the last version in case of my phones, so that shouldn’t be an issue). Might this modification enforce to not use some heavy features of the last ARCore versions? To be honest, I’d really like to understand it. I hope you can find an explanation and confirm if this workaround is a valid solution.
I haven’t tested all the ARDK features with this workaround yet, but I’ll let you know if something doesn’t work as expected.
Sorry for the delay. The issue is still being discussed/ looked into but I will try to get you and update by Monday, there is still a bit of discussion going around about the ARCore versions.
The next version of ARDK will be addressing some changes with ARCore which should fix these performance issues you’re experiencing. I don’t have a solid timeline for when it will be out but please keep an eye out. If the next release does not address the issue, please submit a new topic linking this one and if performance has changed in any way please detail how as well (it worsened, it improved but not as expected, etc…)
Sure, I’ll check it once the new version is out. Do you know if the issue of (theoretically capable) phones failing ARWorldTrackingConfigurationFactory.CheckDepthEstimationSupport() or ARWorldTrackingConfigurationFactory.CheckMeshingSupport() will also be addressed with this fix, or that’s not related?
Hi @Jesus_Hernandez,
I’ve just seen the new ARDK release. I didn’t test it yet, but I can anticipate that the performance is going to be OK. I observe bad performance when arcore min_apk_version is > 203000000, but the value defined in the arcore.aar included in the new ARDK release (2.3.1) is 202940000, so it should work fine if that’s the only change vs 2.3.0. Anyway, I will try to test it properly soon and let you know in case I notice any issue.
Thanks
