Start a new topic
Solved

Rendering 3D model in native Android SDK - inaccurate AR matrices

Hello,


I'm having one more issue with Wikitude's native Android SDK.


If I run the sample project you provided, it shows a cube on a 2D target. However, the AR positioning does not seem very accurate. Please, see the attached video (native_sdk_sample.mp4).


I've tried the same thing with Unity plugin (changed the tracking target to be the same and built it for Android). The AR positioning here seems very accurate, much better than the cube in the first case. Please, see the attached video (unity_sample.mp4)


I'm having the same issue after setting up a custom external rendering of 3D models with native Android SDK. Please, see the attached video (native_sdk_model.mp4).


I hope you can see what I have in mind. 


Am I doing something wrong? Is this a bug in Wikitude Android SDK? Is this a limitation of that SDK? (that would be very unfortunate)


The single observation I made, that could prove useful, is that it might be related to FOV and projection matrix calculation. If, for instance, I provide an incorrect aspect ratio for calculation of projection matrix, the issue is even worse - in the same way, but way more noticable.


I'm using this line of code to calculate projection matrix:


Matrix.perspectiveM(projectionMatrix, 0, fieldOfView, width / height, 0.05f, 5000f);


Where FOV was recovered from cameraManager's renderingCorrectedFov and width + height are the dimensions of the surface view.


I also tried using the deprecated target.projectionMatrix instead of calculating the matrix manually but the results were exactly the same.


I'll be very thankful for any thoughts regarding the matter.


Kind regards,


Adam

mp4
mp4
mp4

Hi Adam,



it's definitely not a limitation of the Android SDK. Unity uses the exact same computer vision code internally as all the other products. How you are calculating your projection matrix seems to me to be correct.


In fact, I think there might not be an issue at all, just some visual weirdness.


The stroked cube, and I'm guessing your model as well, have their origin in the center, not at the bottom. So they are extending beneath the image target in the Z dimension. Since there is no occlusion happening it looks, well, weird. The difference in the unity case is that the augmentation is positioned such that its bottommost point is on the target, not beneath.


I believe you will find the tracking to be correct if you move the cube up by 0.5 in the Z axis.



- Daniel

Hi Daniel, 


thank you again for a quick response with correct solution.


It indeed looks fine after moving the cube as you sugggested.


I suspected this may be the case for a while but it looked just too weird so I didnt even try it.


You may want to consider modifying the sample code to be translated by default though and add a short commentary. It made a confusing impression on us.


It was as easy as changing:

private float zTranslate = 0.0f;

to


private float zTranslate = 0.5f;


in StrokedCube.java


Adam

I agree on adapting the sample and I can see how easily this can be mistaken for poor tracking. I'll make sure we change it for the next release.



- Daniel

Login or Signup to post a comment