I am really excited about your new Instant-Tracking feature. The Demo Videos on Youtube look very awesome and the tracking seems very robust.
But I tried the feature now on two phones (nexus5X + Samsung A3) and couldn't get a good tracking result. I use the Instant-Tracking sample scene in Unity 5.5 without any modifications, I testet the sample app both outdoors and indoors, with good lightning conditions. When I initialize Tracking and just rotate the phone, it works really good. But when I start moving and doing some translational movement, the tracking is lost very quickly. It also seems that tracking is lost immediately when the 3D-content leaves the viewport.
Is there anything I might do wrong or is there any way to improve tracking perfomance? Is there a difference in accuracy between Unity and native APIs?
E.g. the floating turtle example seems so accurate, even though the tar road shouldn't be the ideal texture to track on..
I uploaded a video on vimeo (pw: wikitude) to demonstrate this issue.
Can you please let us know which version of Unity and the Wikitude SDK you are using? And on which device and Android version did you test?
Running at 15 fps is not expected, so I would like to reproduce these issues and see where the problem is.
Disabling 32-bit Pixel Buffer shouldn't be an issue. Did you notice any camera rendering artifacts when doing this?
Multithreading should work in SDK 8. If that was the version you were testing, could you provide more information about the crashes you had?
Regarding ARM64 support, this is included in SDK 8 as well, but requires some additional steps from the user, as mentioned in the Setup Guide, in the 64 bit support for Android section.
The reason we can't include it by default is because of backwards compatibility with older version of Unity, as well as the fact that ARM64 support is experimental at the moment, at least in final versions of Unity.
Thx for the detailed description above. We'll look into this issue and let you know once we have any feedback.
Should you need anything further, just let me know anytime.
I did comparison between 32-bit and 64-bit version of your SDK by running your Native Android sample on the same device capable of running 64 bits builds. As opposed to what you are saying, 32-bit variant didn't seem that much slower as the Unity sample was - at least not significant change so one could get annoyed by lagginess of the camera preview and tracker performance.
Then I compared with Unity 32-bit variant and it feels like camera frame rate drops by 50%. Runs at much less than 15 fps IMHO.
But then I started tweaking rendering options in Unity and got quite a decent perf (I would say comparable to 32 bit Native sample). Here are the changes if anyone is interested:
- Quality level: Fastest (fine with me since my project doesn't require realistic shading and lighting)
- Disabled 32-bit Pixel Buffer (gave a little bit of improvement but not sure how much Wikitude depends on that setting cause it was checked in the Unity sample project) - can WIkitude Team confirm this is not going to break anything?
- Disabled Multithreading (because it was crashing the app quite frequently and was checked in when I launched the sample project)
- Used .NET 4 toolchain + IL2CPP (without ARM64 for now as camera viewfinder doesn't work at all in that config)
Also, I had to do necessary changes in Unity sample to replace the ground plane grid with simple rect + remove directional light component so that my perf comparisons are fair in terms of scene complexity.
Just as a friendly advice to the Wikitude Team: I suggest you update your Unity sample project/docs with improved build/quality settings for Android devices so that people don't get discouraged from using it when they see bad perf and forum discussion for about a year old about the same thing.
Regarding ARM64 and Unity: would be also great if you could release updated unity settings so that sample is built in 64-bit variant as well. Because, it doesn't work for some people today no one can be sure that this is due to wrong settings or bugs in Unity / Wikitude / glue layer. Let me know if I can somehow help you guys with this.
Yeah, same problem. Kudan AR have much better instant tracking of wikitude. Wikitude instant tracking lost very quickly the tracking when user move close to virtual object.
I have also noticed that the Instant Tracking has poor performance - especially in comparison to market competitor Kudan which appears to track items much better with their SLAM implementation.
I am using the Unity SDK with a Samsung Galaxy S6 and have tried various different environments. The phone also gets extremely hot whilst using the application too - so much so that after a 5 minutes or so the phone has to close all applications (Even though the app running Wikitude is the only application open) as the phone is in danger of overheating.
Is there anything that I can do to improve the Instant Tracking performance, and SLAM behaviour.
alright, I will try and test the android SDK then and see how this works.
Yes, I would expect that the other SDKs would work better on the 5X. I don't have an A3 to test on right now, but on the S6 and S7 the performance is much better, compared to the 5X, even if they too are 64 bit devices.
I tried the Unity scene on an Samsung A3 as well and perfomance was almost the same as on my Nexus.
One of the main reasons for the performance difference is that Unity doesn't currently allow 64 bit libraries to be used on Android, so we need to use 32 bit, even when the device is capable of running 64 bit instead. The Nexus 5X in particular seems to have a big performance drop because of this. The turtle video was shot on an iPhone 7 Plus, as mentioned in the description, and on iOS we have no restriction in using 64 bit with Unity. We will also investigate further to see if there are other issues specific to the 5X.
thanks for your fast response.
Sorry, I edited the video settings so it's no available for everyone.
I also uploaded a second video with an outdoor example.