WLT + ASA : vue d’ensemble des logiciels de support
IBinder : liaison de SpacePins à des Azure Spatial Anchors
L’interface IBinder se trouve au centre, implémentée ici par la classe SpacePinBinder. SpacePinBinder est un monocomportement d’Unity, et peut être configuré soit à partir de l’inspecteur d’Unity, soit à partir d’un script.
Chaque IBinder est nommé, de sorte qu’un seul IBindingOracle peut gérer les liaisons de plusieurs IBinder.
IPublisher : lecture et écriture d’ancres spatiales dans le cloud
L’interface IPublisher gère la publication des ancres spatiales dans le cloud, puis leur récupération lors de sessions ultérieures ou sur d’autres appareils. IPublisher est implémenté ici avec la classe PublisherASA. Les données de pose dans l’espace physique actuel sont capturées et récupérées à l’aide d’Azure Spatial Anchors.
Lorsqu’une ancre spatiale est publiée, un ID d’ancre cloud est obtenu. Cet ID peut être utilisé lors de sessions ultérieures ou sur d’autres dispositifs pour récupérer la pose de l’ancre cloud dans le système de coordonnées actuel, ainsi que toutes les propriétés stockées avec. Le système ajoute toujours une propriété identifiant l’instance SpacePin associée à l’ancre cloud.
Il convient de noter que IPublisher et PublisherASA ne savent rien des SpacePin. IPublisher ne sait pas ou ne tient pas compte les données d’ancrage du cloud. Il fournit une interface simplifiée et pouvant être attendue pour publier et récupérer des ancres cloud.
Lecture et recherche
Si l’ID d’une ancre cloud est connu, l’ancre cloud peut être récupérée par son ID. Cette méthode est la plus fiable pour récupérer une ancre cloud. La méthode est Read.
Cependant, il existe des scénarios intéressants dans lesquels les identifiants des ancres cloud dans une zone ne sont pas connus par un dispositif. Mais si ces ancres cloud peuvent être récupérées, leurs données spatiales et leurs propriétés se combinent pour fournir suffisamment d’informations pour les rendre utiles.
La fonction Find recherche les ancres cloud dans la zone autour d’un appareil et retourne tout ce qu’elle a pu identifier. Ce processus est connu sous le nom de « relocalisation approximative ».
IBindingOracle - partage des ID d’ancre cloud
L’interface IBindingOracle permet de conserver et de partager les liaisons entre les SpacePin et des ancres spécifiques dans le cloud. Plus précisément, elle conserve les paires espace-pin-ID/cloud-anchor-ID, ainsi que le nom du IBinder.
L’interface de l’oracle est extrêmement simple. Pour un IBinder donné, il peut soit Poser (Put) les liaisons du IBinder, soit les Obtenir (Get). Put les stocke, et Get les récupère. Le mécanisme de stockage et de récupération est laissé à la charge de la classe concrète implémentant l’interface IBindingOracle.
Cet exemple implémente ce qui peut-être l’IBindingOracle le plus simple possible, sous la forme de la classe SpacePinBinderFile. Sur Put, il écrit les liaisons IBinder de dans un fichier texte. Sur Get, il les lit à partir du fichier texte (si disponible) et les alimente dans le IBinder.
ILocalPeg : blob marquant une position dans l’espace physique
L’interface ILocalPeg est une abstraction d’une ancre locale de dispositif. Dans un monde plus parfait, les ILocalPeg nécessaires seraient gérés en interne par les IPublisher. Cependant, les ancres locales des dispositifs fonctionnent beaucoup mieux lorsqu’elles sont créées alors que le dispositif se trouve à proximité de la pose de l’ancre. Le IPublisher sait seulement où les ancres locales du dispositif doivent être placées lorsqu’elles sont nécessaires, et non au moment optimal de leur création.
Le SpacePinASA sait quel est le meilleur moment pour créer son ancre locale. Lorsque la manipulation du SpacePin se termine et que sa pose est définie, SpacePinASA demande à IPublisher de créer une fixation locale opaque au niveau de la pose souhaitée. SpacePinBinder extrait ensuite l’ILocalPeg de SpacePinASA et le transmet à IPublisher pour qu’il soit utilisé lors de la création d’une ancre spatiale cloud.