Start a new topic

UNITY PLUGIN 1.2.1-1.1.0 update

UNITY PLUGIN 1.2.1-1.1.0 update


No, I'm afraid it's a bit more complicated.

At runtime, you would have to find all MeshFilter components, access the mesh variable and change the bounds value there. Something like this:

foreach (var meshFilter in GetComponentsInChildren<MeshFilter>()) {
   var newBounds = meshFilter.mesh.bounds;
   newBounds.size *= 2.0f;
   meshFilter.mesh.bounds = newBounds;
}

You would do this once, in Start, on the root object. In the example project, this can be the ToggleTrackable script.

You can also look at this blogpost for more info, but keep in mind that the example there won't work properly as is because the forward of the Wikitude camera is not pointing the right direction. I hope this will also get fixed soon. Sorry for the inconvenience, but I hope this will get it working.

Thanks for your answer. To update the bounds of the meshes do you mean increasing the collider size in the editor?

Thank you for confirming the issue. I will definitely look into ways we can update the camera so it behaves properly in the editor. In the mean time, maybe you could try disabling the frustum culling by increasing the size the bounds of the meshes. Unfortunately, Unity doesn't seem to offer any proper way to disable frustum culling, at least as far as I know, but hopefully we will fix the issue soon.

Yeah I placed those logs and the tracker was not lost but both objects (my 3d model and my 3d UI) disappeared, so I think it's somehting related to the frustum culling. That said sometimes the tracker was getting lost if the movement was too fast or if the camera lost focus.

I did the same test on the example project, simple target tracking and it didn't affect. Perhaps it is some issue with culling, rather than tracking. Would it be possible to check if the target is actually lost by placing some logs in the script that handles events from TrackableBehaviour? In the sample application, the equivalent script would be ToggleTrackable, and make sure they are linked to events in TrackableBehaviour. It might help tracking down this issue.

mmm, then it's weird because if you do change the FOV value of the Wikitude camera then the triggers are not working properly anymore. That means that somehow that number is used somewhere?

 

The FOV value in the camera inspector is not used. At runtime, the plugin provides a custom projection matrix that overrides it because it needs to match what the actual physical camera is seeing. The target should only be lost when exiting the field of view of the physical camera, but blurry frames caused by rapid movement will also cause issues, unfortunately. Phone performance and camera quality will help with this.

I'm using a trigger with 3 stars so that should not be the issue. Could it be that the narrow 34 degrees view angle set on the Wikitude cameras make it easy to loose the tracker if going outside the 34° frustum? 

Hi Robin, 

Is there any difference in the quality of tracking between the sample and your app? You can also check if the targets you are using are suitable for tracking. In the target manager, the number of stars on each target will indicate this.

Hi Alexandru,

 

I replaced the 3D UI with a 2D one. Now the tracking works much better, but compared with other techs I still think it gets lost too easily when moving the device. Most people use the device moving it very fast and with steep angles which of course doesn't help the recognition.

Hi, 

I'll try to reproduce it and find what the problem is. Maybe in the mean time you can try to display the 3D UI with a separate, static camera, by converting the augmentation position from the wikitude camera space to the new one.

Hi there,

I can't send the current sample at the moment for corporate reasons. That said I simply visualized a 3d model together with a 3D UI on its right and they were both childs of the tracker object container.

 

Hi, 

I would like to look into this issue, because it shouldn't matter, as long as the target image is visible to the camera. It might be a problem with Unity not handling frustum culling very well with our camera. Would it be possible for you to send a small sample project where we can reproduce this? Thank you.

Kinds regards, 

Alexandru

Hi there,

I found the issue. Basically I was visualizing an object containing a 3D model and a 3D UI placed on its right. The fact that the UI was placed on the right made it so that its 3D panel would exit the camera frustum quite easily and I think that's why then the whole tracker object was hidden often. I'm not sure why that's the case though, the trigger was always visible on camera. Once I disabled the 3d UI the whole marker was much more stable. Do you somehow check if the visualized model is inside the camera frustum at all times? 

No it's the correct project. But one thing I noticed is that one must really move the device very slowly else the tracking gets lost easily. Maybe when I tried it the first time I was panning very slowly without realizing it.  I noticed that people tend to move their iPad or iPhone quite frantically when scanning triggers and so they tend to loose the camera focus quite easily. Is there a way to soften this problem somehow? Thanks
Login or Signup to post a comment