As of Vuforia Engine 6.2, the ARCamera APIs have been refactored to support a global camera configuration for all scenes in a Vuforia Unity project. The refactoring includes renaming of many of the classes ( Behaviours ) that interact with the ARCamera. These behaviours no longer derive from the Unity MonoBehaviour class, rather they now derive from a new ARController base class.
This article documents these changes and how they affect the set-up and lifecycle of a Vuforia Engine app in Unity. See: Migrating Unity Projects to Vuforia Engine 6.2 for instructions on how to migrate legacy Unity projects to the latest ARCamera and Behaviour APIs.
|Old MonoBehaviour||New ARController|
The derived classes in the open source project have been removed, because the new classes can be instantiated directly.
All of these new classes implement the singleton pattern. The singleton can be accessed with the public property Instance, e.g. VuforiaARController.Instance.
Usually, only the classes DigitalEyewearAbstractBehaviour and VuforiaAbstractBehaviour were used in application code. For these we already had a property to get the instance. Only the class name has to be changed in the code. The often used null-check for the instance is not needed anymore, because the singleton instance always exists independent from the scene content.
VuforiaBehaviour.Instance => VuforiaARController.Instance
DigitalEyewearBehaviour.Instance => DigitalEyewearARController.Instance
A new VuforiaAbstractBehaviour was added to the ARCamera prefab. This behaviour does not expose any public API to the developers.
The inspector for the new behaviour contains the world center mode settings. Currently, also the 3rd-party VR SDK settings are exposed in this inspector. These will be replaced by a better integration.
Special settings for a particular scene can be achieved with the VuforiaConfiguration-class.
Nearly all settings which can be defined in the editor have a public property to set them during runtime. Changing any of these settings won’t have an immediate effect. The changed settings will be used for all upcoming scenes. Changing something immediately can be done with existing runtime API which has not changed.
VuforiaConfiguration.DigitalEyewear.EyewearType = EyewearType.VideoSeeThrough;
VuforiaConfiguration.VideoBackground.VideoBackgroundEnabled = false;
Additional API changes
VuforiaARController.SetAppLicenseKey() has been removed. The license key can only be set via the global configuration before the app starts.
Initialization and deinitialization of Vuforia Engine is done only once per app instead of every scene. The code for initialization and deinitialization is moved from the VuforiaBehaviour to a new class VuforiaRuntime.
/// <summary> /// Initialize correct platform-specific player /// </summary> public void InitPlatform(IUnityPlayer player); /// <summary> /// Initialize Vuforia. This has to be called after InitPlatform /// </summary> public void InitVuforia(); /// <summary> /// Deinitialize Vuforia when application is quit. /// </summary> public void Deinit() /// <summary> /// Register for a callback that is invoked if Vuforia initialization fails. /// More than one callback can be registered. /// </summary> public void RegisterVuforiaInitErrorCallback( Action<VuforiaUnity.InitError> callback); /// <summary> /// Unregister a previously registered callback. /// </summary> public void UnregisterVuforiaInitErrorCallback( Action<VuforiaUnity.InitError> callback);
The methods InitPlatform, InitVuforia and Deinit are called from open source Vuforia scripts and should not be called from the developer directly. Registering a callback for the initialization error has to be changed in application code.
VuforiaBehaviour.Instance.RegisterVuforiaInitErrorCallback => VuforiaRuntime.Instance.RegisterVuforiaInitErrorCallback
In case the developer has selected Delayed Initialization in the configuration window, Vuforia Engine has to be initialized manually with VuforiaRuntime.InitVuforia(). The initialization has to be done before an ARCamera is started.