documentation

Preparing 3D Models for Model Tracking
Level: Basic
Preparing3DModelsForModelTracking_banner.jpg

Since VisionLib's main advantage is to track particular objects, it makes sense to use digital 3D models of those real objects for both, visualization purposes and tracking.

The following guide gives a plain overview on best practices while preparing your 3D files for tracking. The prefabs and example scenes mentioned in this guide concern the VisionLib SDK for Unity. We assume that you've imported the VisionLib plugin for Unity in your project.

Using 3D models for tracking may come with different requirements than for sole rendering and visualization. That is why we recommend to duplicate the 3D model's file for tracking and visualization (e.g. one stored in StreamingAssets/VisionLib the other in the Models folder) — although both files may be similar or the same.

We use the assimp-library to import models into VisionLib. So file formats supported by this library should work with VisionLib right away. If you experience trouble, please give us a note and contact us at request@visionlib.com.

Please be careful to provide VisionLib the metric of your models in the parameters section of the tracker. I.e. if one unit of the model represents one meter in the real world, set the metric parameter to m. For further details, please consult vlUnitySDK_UnderstandingTrackingParameters.

Requirements & Limitations:

  • The 3D model should have enough detectable structure (models of white walls do not work).
  • The model should be distinct and invariant to any transformation (although rotation-invariant models, like a simple sphere, might generally work, those objects won't be stable and initialize arbitrarily).
  • The model should not consist of too much clutter (i.e. many very small elements).
  • The real model should fit exactly to the virtual model — while some minor variations won't matter, others may break the tracking entirely: e.g., an arbitrary mug model with any arbitrary real mug won't work appropriately.
  • It is good practice to keep the tracking model as lightweight as possible. For instance, if you are going to track a car solely from its outside, you won't need a 3D model with the whole interior.
  • Generally the VisionLib is tolerant against big models. To speed up the rendering of tracking hypothesis, we recommend to merge the meshes of complex models, when they exceed 100MB in filesize.
  • Keep an eye on your memory left for device and application
  • VisionLib uses only normals and triangles - when exporting files you might only export normals and indices. You may skip color and texture information in order to save memory. If you have not exported normals, the VisionLib will try to create normals from your model automatically.
  • You can also import polygonal meshes. They will be converted into triangle representation while loading. You can save loading time by already providing them with precalculated triangles.

Setting up Occlusion Models

In order to optimize your model for tracking, you might make use of occluding structures. Therefore you should use occlusionModelURI parameter, that works like the modelURI parameter. You can load some replacement model which in turn covers the use of lines in the covered area by the loaded occlusion model. If you have e.g. some car you want to track, but the rotational position of the wheel does usually not cover the real model, you might leave the wheels in the tracking model away. Instead you will have a line model being generated for the space behind the wheel, and thus tracking will not work properly in this region. A better approach is using an occlusion model, which covers the rims. This will lead to a line model, where wheels are respected, but no lines for the rims will be generated.

A Tutorial on how to use this feature in detail will follow in the next versions.