Table of Contents

Prise en charge des appareils et session report

En raison des différences de matériel et de performances entre les appareils, les fonctions AR ne peuvent souvent pas fonctionner sur tous les appareils. Il est donc très important, lors de l'utilisation de fonctions AR, d'évaluer avec précision la prise en charge de l'appareil actuel. Cet article explique comment la disponibilité des appareils est exprimée dans Unity, et comment obtenir les informations de prise en charge des appareils et de disponibilité de session via session report (ARSession.Report).

Avant de commencer

Prise en charge des appareils, disponibilité de session et assembly

Les appareils pris en charge par chaque fonction AR sont différents. Par exemple, motion tracking a certaines exigences pour les composants matériels et nécessite généralement une calibration de l'appareil, tandis qu'image tracking peut fonctionner sur presque tous les appareils dont la caméra est disponible. Ainsi, pour déterminer si une application AR peut fonctionner sur un appareil donné, il faut généralement savoir quelles fonctions AR sont actuellement utilisées, autrement dit déterminer si une session peut fonctionner sur cet appareil.

Dans Unity, ce processus d'évaluation s'effectue à l'étape de session assembly (Assemble()). Le processus d'assembly détermine l'état final avant le démarrage de la session selon les composants contenus dans la session et la prise en charge de l'appareil actuel.

Si l'assembly réussit, la session entre dans l'état Ready et peut continuer à démarrer et fonctionner. Si l'assembly échoue, la session entre dans l'état Broken, et la cause précise de l'échec peut être consultée via session report (ARSession.Report).

Session report

La propriété ARSession.Report fournit le rapport runtime de la session. Un session report contient les champs suivants:

Propriété Description
Availability Rapport de disponibilité complet
BrokenReason Cause de la session endommagée, valide lorsque l'état de session est Broken
Exception Exception précise de la session endommagée, valide lorsque l'état de session est Broken

Dans session report, vous pouvez consulter la disponibilité de chaque composant via Availability, ou consulter la cause détaillée via BrokenReason lorsque la session est endommagée.

Exemple de session report

Par exemple, sous Windows, si la session contient ImageTrackerFrameFilter, CameraDeviceFrameSource et plusieurs autres composants frame source, le processus d'assembly vérifie la disponibilité de chaque composant et génère le rapport suivant:

alt text

On peut voir que même si Availability du composant ARCoreFrameSource est Unavailable, comme Availability de ImageTrackerFrameFilter et de CameraDeviceFrameSource sont tous deux Available, l'assembly de toute la session réussit et la session entre avec succès dans l'état Ready.

Si nous supprimons CameraDeviceFrameSource de la session, le processus d'assembly génère le rapport suivant:

alt text

On peut voir que le nombre dans la liste FrameSources passe de 9 à 8. Même si Availability du composant ImageTrackerFrameFilter est toujours Available, comme il n'y a aucun composant frame source disponible, l'assembly de toute la session échoue et la session entre dans l'état Broken. À ce moment, la valeur du champ BrokenReason dans le rapport est NoAvailabileFrameSource, ce qui indique qu'aucune frame source n'est disponible.

En dehors du processus d'assembly, la session peut aussi être endommagée pendant le runtime, par exemple lorsqu'un composant en cours d'exécution est supprimé accidentellement. Dans ce cas, la cause précise peut également être consultée via session report.

Mise à jour du rapport

Session report change aux moments suivants:

  • Fin de la première étape d'assembly
    À ce moment, un session report complet est généré, comprenant le rapport de disponibilité des composants. La partie Availability du session report est déterminée à ce moment et ne change plus. Les mises à jour du rapport de disponibilité des composants peuvent être obtenues via l'événement AssembleUpdate.
    Si la session est démarrée directement après l'assembly, les mises à jour de session report peuvent aussi être obtenues via l'événement StateChanged. Les états de session à surveiller incluent: Ready et Broken.

  • Fin de la deuxième étape d'assembly À ce moment, un nouveau rapport de disponibilité des composants est généré. Sauf redémarrage de la session, session report ne sera pas mis à jour. Les mises à jour du rapport de disponibilité des composants peuvent être obtenues via l'événement AssembleUpdate.

  • Lors du démarrage de la session ou lorsque la session est endommagée pendant le runtime
    BrokenReason et Exception dans session report sont mis à jour. Les mises à jour de session report peuvent être obtenues via l'événement StateChanged. Les états de session à surveiller incluent: Broken.

Contenu du rapport: causes de session endommagée

BrokenReason indique la cause de la session endommagée. Les cas suivants existent:

Cause Description
Uninitialized Processus d'assembly: EasyAR Sense n'a pas été initialisé correctement
LicenseInvalid Processus d'assembly: la vérification de license EasyAR Sense a échoué ou ne s'applique pas à l'utilisation actuelle
SessionObjectIncomplete Processus d'assembly: session object incomplet. Par exemple RendererFeature n'est pas configuré correctement dans URP
NoAvailabileFrameSource Processus d'assembly: aucune frame source disponible. Par exemple toutes les frame sources sont indisponibles ou aucune frame source n'a été ajoutée. Uniquement dans la configuration session par défaut, cette situation indique la prise en charge par l'appareil de la fonction AR actuellement sélectionnée
FrameSourceIncomplete Processus d'assembly: frame source incomplète. Cela apparaît généralement lorsqu'une custom frame source n'implémente pas correctement l'interface frame source
FrameFilterNotAvailabile Processus d'assembly: un frame filter indisponible existe. Cette situation n'existe que sous certaines options d'assembly.
StartFailed Échec du démarrage. Par exemple une exception se produit pendant le démarrage
RunningFailed Échec runtime. Par exemple un composant en cours d'exécution est supprimé accidentellement, ou RendererFeature n'est pas configuré correctement dans URP.

Contenu du rapport: informations de disponibilité

Availability fournit les informations de disponibilité de chaque composant dans la session. Il contient les champs suivants:

Champ Description
FrameFilters Liste de disponibilité des frame filters vérifiés pendant l'assembly
FrameSources Liste de disponibilité des frame sources vérifiées pendant l'assembly
PendingDeviceList Tâche de téléchargement de liste d'appareils non terminée
DeviceList Résultat du téléchargement de la liste d'appareils

Les champs PendingDeviceList et DeviceList servent à indiquer l'état de téléchargement de la liste de prise en charge des appareils. Lorsque la première étape d'assembly est terminée, si et seulement si PendingDeviceList n'est pas vide, l'assembly entre dans la deuxième étape. Cette condition peut être utilisée pour déterminer si AssembleUpdate sera exécuté une deuxième fois.

Étapes suivantes