Résolution des problèmes

Cette page liste les problèmes courants qui interfèrent avec Azure Remote Rendering et les façons de les résoudre.

Le client ne peut pas se connecter au serveur

Assurez-vous que vos pare-feu (sur l’appareil, les routeurs internes, etc.) ne bloquent pas les ports mentionnés dans la Configuration requise.

Impossible de charger le modèle

Si le chargement d’un modèle (par exemple via un exemple Unity) échoue alors que la configuration des objets blob est correcte, il est probable que le stockage d’objets blob n’est pas correctement lié. La définition d’une liaison correcte est expliquée dans le chapitre Lier des comptes de stockage. Une fois la liaison correctement effectuée, la prise en compte des changements peut prendre jusqu’à 30 minutes.

Parfois, lors de la liaison d’un compte de stockage, le compte de rendu à distance (ARR, Remote Rendering Account) n’est pas répertorié. Pour résoudre ce problème, accédez au compte ARR dans le portail Azure, puis sélectionnez Identité dans le groupe Paramètres sur la gauche. Assurez-vous que l’État est Activé. Unity frame debugger

Impossible de charger le modèle par le biais d’un jeton SAP

Si l’application cliente ne parvient pas à charger un modèle à partir du stockage via un jeton SAP valide, il peut être dû au niveau d’accès réseau public configuré sur le stockage d’objets blob. Le chargement d’un modèle ARR à partir d’un jeton SAP fonctionne uniquement s’il a été configuré avec l’option « Activé à partir de tous les réseaux » : Screenshot of Azure portal settings for public network access level on blob storage.

Si la limitation aux points de terminaison privés est requise, le compte de stockage doit être lié et le modèle doit être chargé via le chemin de code non SAS, comme décrit ici.

Erreur : Disconnected: VideoFormatNotAvailable

Vérifiez que votre GPU prend en charge le décodage vidéo matériel. Consultez PC de développement.

Si vous travaillez sur un ordinateur portable avec deux GPU, il est possible que le GPU que vous utilisez par défaut n’offre pas de fonctionnalité de décodage vidéo matériel. Si c’est le cas, essayez de forcer votre application à utiliser l’autre GPU. La modification du GPU utilisé est souvent possible dans les paramètres du pilote GPU.

La récupération de l’état de la session/conversion échoue

L’envoi de commandes d’API REST trop fréquemment entraîne la limitation et le retour du serveur. Le code d’état HTTP dans le cas de limitation est 429 (« trop de demandes »). En règle générale, il doit y avoir un délai de 5 à 10 secondes entre les appels successifs.

Notez que cette limite affecte non seulement les appels d’API REST effectués directement, mais aussi leurs équivalents C#/C++, tels que Session.GetPropertiesAsync, Session.RenewAsync ou Frontend.GetAssetConversionStatusAsync. Certaines fonctions retournent également des informations quand une nouvelle tentative peut être effectuée sans problème. Par exemple, RenderingSessionPropertiesResult.MinimumRetryDelay spécifie le nombre de secondes à attendre avant de tenter une autre vérification. Si une valeur retournée comme celle-ci est disponible, nous vous recommandons de l’utiliser. Vous pourrez ainsi effectuer autant de vérifications que possible sans aucune limitation.

Si vous rencontrez une limitation côté serveur, modifiez le code pour effectuer les appels moins fréquemment. Le serveur réinitialisant l’état de limitation à chaque minutes, vous pouvez sans problème réexécuter le code au bout d’une minute.

Codec H265 non disponible

Le serveur peut refuser de se connecter avec une erreur codec not available pour deux raisons.

Le codec H265 n’est pas installé :

Tout d’abord, veillez à installer les extensions vidéo HEVC comme indiqué dans la section Logiciels de la configuration système requise.

Si vous rencontrez toujours des problèmes, assurez-vous que vos graphiques carte prennent en charge H265 et que le pilote graphique le plus récent est installé. Pour connaître les informations spécifiques au fournisseur, consultez la section PC de développement de la configuration requise.

Le codec est installé, mais ne peut pas être utilisé :

La raison de ce problème est un paramètre de sécurité incorrect sur les DLL. Ce problème ne se manifeste pas quand vous tentez de regarder des vidéos encodées avec le codec H265. La réinstallation du codec ne résout pas non plus le problème. Effectuez plutôt les étapes suivantes :

  1. Ouvrez PowerShell avec des droits d’administrateur, puis exécutez la commande suivante

    Get-AppxPackage -Name Microsoft.HEVCVideoExtension*
    

    (Notez que le signe « * » est dû au fait que, pour certaines versions d’installation du package, le nom est HEVCVideoExtensions au lieu de HEVCVideoExtension). Cette commande doit générer la valeur InstallLocation du codec, similaire à ce qui suit :

    InstallLocation   : C:\Program Files\WindowsApps\Microsoft.HEVCVideoExtension_1.0.23254.0_x64__5wasdgertewe
    
  2. Ouvrez le dossier dans l’Explorateur Windows

  3. Il doit y avoir un sous-dossier x86 et un sous-dossier x64. Cliquez avec le bouton droit sur l’un des dossiers, puis choisissez Propriétés

    1. Sélectionnez l’onglet Sécurité, puis le bouton Paramètres avancés
    2. Sélectionnez Modifier pour Propriétaire
    3. Tapez Administrateurs dans le champ de texte
    4. Sélectionnez Vérifier les noms, puis OK
  4. Répétez les étapes ci-dessus pour l’autre dossier

  5. Répétez également les étapes ci-dessus sur chaque fichier DLL présent dans les deux dossiers. Il doit y avoir quatre DLL en tout.

Pour vérifier que les paramètres sont désormais corrects, effectuez les étapes suivantes pour chacune des quatre DLL :

  1. Sélectionnez Propriétés > Sécurité > Modifier
  2. Parcourez la liste de tous les Groupes/Utilisateurs, puis vérifiez que le droit Lire et exécuter est défini pour chacun d’eux (la colonne Autoriser doit contenir une coche)

Vidéo de mauvaise qualité

La qualité de la vidéo peut être compromise par la qualité du réseau ou par l’absence du codec vidéo H265.

La vidéo enregistrée avec la fonction MRC ne reflète pas la qualité de l’expérience en direct

Une vidéo peut être enregistrée sur HoloLens par le biais de la fonction Mixed Reality Capture (MRC). Toutefois, la vidéo qui en résulte est de moins bonne qualité que l’expérience en direct pour deux raisons :

  • La fréquence d’images vidéo est limitée à 30 Hz au lieu de 60 Hz.
  • Les images vidéo ne passent pas par l’étape de traitement Reprojection en phase tardive, de sorte que la vidéo semble plus hachée.

Les deux sont des limitations inhérentes à la technique d’enregistrement.

Écran noir après le chargement réussi d’un modèle

Si vous êtes connecté au runtime de rendu et que vous avez correctement chargé un modèle, mais que vous ne voyez ensuite qu’un écran noir, cela peut avoir plusieurs causes distinctes.

Nous vous recommandons de tester les opérations suivantes avant de procéder à une analyse plus approfondie :

  • Le codec H265 est-il installé? Même s’il y existe un mécanisme de secours pour le codec H264, nous avons observé des cas où ce mécanisme de secours ne fonctionnait pas correctement. Consultez la configuration système requise pour savoir comment installer le pilote graphique le plus récent.
  • Quand vous utilisez un projet Unity, fermez Unity, supprimez les dossiers library et obj temporaires dans le répertoire du projet, puis chargez/générez à nouveau le projet. Dans certains cas, les données mises en cache entraînaient un mauvais fonctionnement de l’exemple sans aucune raison évidente.

Si ces deux étapes n’ont pas permis de résoudre le problème, il est nécessaire de déterminer si les trames vidéo sont reçues ou non par le client. Cela peut être déterminé par programmation, comme expliqué dans le chapitre Requêtes de performances côté serveur. Le FrameStatistics struct a un membre qui indique le nombre de trames vidéo reçues. Si ce nombre est supérieur à 0 et qu’il augmente dans le temps, le client reçoit des trames vidéo réelles du serveur. Il doit donc s’agir d’un problème côté client.

La valeur de mise à l’échelle dans les paramètres de conversion n’est pas appliquée au modèle

Si un modèle apparaît dans Showcase ou Démarrage rapide avec une mise à l’échelle inchangée, même si une mise à l’échelle est appliquée dans le cadre des paramètres géométriques des paramètres de conversion, cela est probablement dû à la fonctionnalité intégrée de mise à l’échelle automatique de l’exemple. Autrement dit, l’exemple met à l’échelle le modèle pour qu’il s’adapte le mieux au frustum d’affichage, quelle que soit sa mise à l’échelle d’entrée.

Dans le cas de Showcase, la mise à l’échelle automatique peut être désactivée en spécifiant un MaxSize zéro dans la section du Transform modèle dans le fichier models.xml. Cette approche pilotée par les données nécessite que le modèle soit chargé via le code XML en premier lieu, car dans tous les autres cas, les MaxSize valeurs par défaut sont de 1 mètre. Il existe également une MinSize propriété dont la valeur par défaut est de 0,5 mètre, ce qui entraîne le scale-up de tous les modèles plus petits. Pour plus d’informations sur les façons de charger des modèles dans Showcase, consultez le chapitre Ajout de ressources de modèle 3D à ARR Showcase de la documentation Showcase.

Problèmes courants côté client

Le modèle dépasse les limites de la machine virtuelle sélectionnée, notamment le nombre maximal de primitives :

Consultez les limites de taille de serveur spécifiques.

Le modèle ne se trouve pas dans le frustum de l’appareil photo :

Dans de nombreux cas, le modèle s’affiche correctement, mais il se trouve en dehors du frustum de l’appareil photo. Une raison courante à cela est que le modèle a été exporté avec un tableau croisé dynamique trop décentré, de sorte qu’il est coupé par le plan arrière de découpage de l’appareil photo. Cela permet d’interroger par programmation le cadre englobant du modèle et de visualiser la zone avec Unity sous la forme d’une zone de ligne ou d’imprimer ses valeurs dans le journal de débogage.

En outre, le processus de conversion génère un fichier JSON de sortie avec le modèle converti. Pour déboguer des problèmes de positionnement du modèle, il est utile de regarder l’entrée boundingBox dans la section outputStatistics :

{
    ...
    "outputStatistics": {
        ...
        "boundingBox": {
            "min": [
                -43.52,
                -61.775,
                -79.6416
            ],
            "max": [
                43.52,
                61.775,
                79.6416
            ]
        }
    }
}

Le cadre englobant est décrit comme une position min et max dans l’espace 3D, en mètres. Par conséquent, une coordonnée de 1000,0 signifie qu’elle est à un kilomètre du point d’origine.

Ce cadre englobant peut présenter deux problèmes qui mènent à une géométrie invisible :

  • Le cadre peut être très décentré, de sorte que l’objet est coupé entièrement en raison du plan arrière de découpage. Dans ce cas, les valeurs de boundingBox ressemblent à ceci : min = [-2000, -5,-5], max = [-1990, 5,5], en utilisant un décalage important sur l’axe X comme illustré en exemple ici. Pour résoudre ce type de problème, activez l’option recenterToOrigin dans la configuration de conversion du modèle.
  • Le cadre peut être centré, mais être d’un ordre de grandeur trop important. Cela signifie que, bien que l’appareil photo démarre au centre du modèle, sa géométrie est découpée dans toutes les directions. Dans ce cas, les valeurs typiques de boundingBox se présentent comme suit : min = [-1000,-1000,-1000], max = [1000,1000,1000]. La raison de ce type de problème est généralement une incompatibilité de l’échelle d’unités. Pour compenser, spécifiez une valeur de mise à l’échelle pendant la conversion ou marquez le modèle source avec les unités appropriées. La mise à l’échelle peut également être appliquée au nœud racine lors du chargement du modèle au moment de l’exécution.

Le pipeline de rendu Unity n’inclut pas les crochets de rendu :

Azure Remote Rendering se raccroche au pipeline de rendu Unity pour créer la composition du cadre avec la vidéo et effectuer la reprojection. Pour vérifier que ces crochets, ouvrez le menu Window > Analysis > Frame debugger. Activez-le et vérifiez qu’il existe deux entrées pour HolographicRemotingCallbackPass dans le pipeline :

Unity render pipeline

Pour résoudre ce problème, vérifiez que la ressource HybridRenderingPipeline fournie est utilisée :Screenshot of the Unity asset browser and Project Settings dialog. The HybridRenderingPipeline asset is highlighted in the asset browser. An arrow points from the asset to the UniversalRenderPipelineAsset field in project settings.

.. comme décrit plus en détail dans les pipelines de rendu Unity.

Le modèle de damier est rendu après le chargement du modèle

Si l’image rendue ressemble à ceci : Screenshot shows a grid of black and white squares with a Tools menu.

alors le renderer atteint les limites de polygones pour la taille de configuration standard. Pour atténuer ce problème, basculez vers une taille de configuration Premium ou réduisez le nombre de polygones visibles.

L’image rendue dans Unity est à l’envers

Veillez à suivre le didacticiel Unity : afficher exactement les modèles distants . Une image à l’envers indique que Unity est nécessaire pour créer une cible de rendu hors écran. Ce comportement n’est pas pris en charge actuellement, et crée un impact énorme sur les performances sur HoloLens 2.

Ce problème peut être lié à MSAA, à HDR ou à l’activation du post-traitement. Vérifiez que le profil de qualité inférieure est sélectionné et défini comme valeur par défaut dans Unity. Pour ce faire, accédez à Modifier > Paramètres du projet... > Qualité.

Quand vous utilisez le plug-in OpenXR dans Unity 2020, certaines versions du pipeline de rendu universel (URP, Universal Render Pipeline) créent cette cible de rendu hors écran supplémentaire, quel que soit le post-traitement activé. Il est donc important d’effectuer une mise à niveau manuelle de la version du pipeline URP vers au moins la version 10.5.1 (ou ultérieure). Ce processus de mise à niveau est décrit dans Configuration système requise.

Le code Unity utilisant l’API Remote Rendering ne se compile pas

Utiliser Debug lors de la compilation dans l’éditeur Unity

Basculez le type de build de la solution Unity sur Déboguer. Lors du test de ARR dans l’éditeur Unity, le UNITY_EDITOR défini est disponible uniquement dans les builds « Debug ». Ce paramètre n’est pas lié au type de build utilisé pour les applications déployées, où vous devez préférer les builds « Release ».

Échecs de compilation lors de la compilation d’exemples Unity pour HoloLens 2

Nous avons constaté de faux échecs lors de tentative de compilation d’exemples Unity (démarrage rapide, ShowCaseApp, etc.) pour HoloLens 2. Visual Studio signale qu’il ne peut pas copier certains fichiers qui sont pourtant présents. Si vous avez rencontré ce problème :

  • Supprimez tous les fichiers Unity temporaires du projet, puis réessayez. C’est-à-dire, fermez Unity, supprimez les dossiers library et obj temporaires dans le répertoire du projet, puis chargez/générez à nouveau le projet.
  • Vérifiez que les projets se trouvent dans un répertoire sur disque dont le chemin est relativement court, car l’étape de copie échoue parfois en présence de noms de fichiers longs.
  • Si cela n’est pas la cause, il est possible que MS Sense interfère avec l’étape de copie. Pour configurer une exception, exécutez cette commande de Registre à partir de la ligne de commande (nécessite des droits d’administrateur) :
    reg.exe ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection" /v groupIds /t REG_SZ /d "Unity"
    

Les builds Arm64 pour les projets Unity échouent car AudioPluginMsHRTF.dll est manquant

AudioPluginMsHRTF.dll pour Arm64 a été ajouté au package Windows Mixed Reality(com.unity.xr.windowsmr.metro) dans la version 3.0.1. Vérifiez que la version 3.0.1 ou ultérieure est installée par le biais de Unity Package Manager. Dans la barre de menus Unity, accédez à Fenêtre > Gestionnaire de package et recherchez le package Windows Mixed Reality.

Le plug-in Unity Cinemachine ne fonctionne pas en mode Pose à distance

En mode Pose à distance, le code de liaison ARR Unity crée implicitement une caméra proxy qui effectue le rendu réel. Dans ce cas, le masque de culling de la caméra principale est défini sur 0 (« rien ») afin de désactiver efficacement le rendu pour celle-ci. Toutefois, certains plug-ins tiers (comme Cinemachine) qui pilotent la caméra peuvent s’appuyer sur au moins certains bits de couche définis.

À cet fin, le code de liaison vous permet de modifier par programmation le masque de bits de couche pour la caméra principale. Spécifiquement, les étapes suivantes sont nécessaires :

  1. Créez une couche dans Unity qui n’est pas utilisée pour le rendu d’une géométrie de scène locale. Dans cet exemple, nous partons du principe que la couche se nomme « Cam ».
  2. Passez ce masque de bits à ARR pour que ARR le définit sur la caméra principale :
    RemoteManagerUnity.CameraCullingMask = LayerMask.GetMask("Cam");
    
  3. Configurez les Cinemachine propriétés pour utiliser cette nouvelle couche : Screenshot that shows Unity's inspector panel for camera settings in Cinemachine.

Le mode de pose local n’est pas affecté par ce problème, car en l’occurrence la liaison ARR ne redirige pas le rendu vers une caméra proxy interne.

L’application basée sur C++ native ne se compile pas

Erreur « bibliothèque introuvable » pour une application ou DLL UWP

Le package NuGet C++ contient un fichier microsoft.azure.remoterendering.Cpp.targets qui définit la version de fichier binaire à utiliser. Pour identifier UWP, les conditions dans le fichier vérifient la présence de ApplicationType == 'Windows Store'. Il faut donc vérifier que ce type est défini dans le projet. Cela devrait être le cas lors de la création d’une application ou DLL UWP via l’Assistant Projet de Visual Studio.

Hologrammes instables

Si les objets rendus semblent se déplacer avec les mouvements des têtes, vous rencontrez peut-être des problèmes avec la Reprojection en phase tardive (LSR). Pour obtenir des conseils sur la façon d’aborder une telle situation, consultez la section relative à la reprojection en phase tardive.

Les hologrammes instables (hologrammes qui oscillent, déformés, qui vacillent ou qui sautent) peuvent également s’expliquer par une mauvaise connectivité réseau, en particulier une bande passante réseau insuffisante ou une latence trop élevée. La valeur de statistiques de performancesServiceStatistics.VideoFramesReused constitue un bon indicateur de la qualité de votre connexion réseau. Les trames réutilisées indiquent les situations où une ancienne trame vidéo devait être réutilisée côté client car aucune nouvelle trame vidéo n’était disponible, par exemple en raison d’une perte de paquets ou de variations de la latence du réseau. Si ServiceStatistics.VideoFramesReused est souvent supérieur à zéro, cela indique un problème réseau.

Une autre valeur à examiner est ServiceStatistics.LatencyPoseToReceiveAvg. Elle doit toujours être inférieure à 100 ms. Des valeurs plus élevées pourraient indiquer que vous êtes connecté à un centre de données trop éloigné.

Pour obtenir la liste des atténuations potentielles, consultez les instructions pour la connectivité réseau.

Le contenu local (IU, ...) sur HoloLens 2 s’affiche avec beaucoup plus d’artefacts de distorsion que sans ARR

Cet artefact est dû à un paramètre par défaut qui échange la qualité de la projection du contenu local pour les performances de runtime. Reportez-vous au chapitre sur les modes de pose de reprojection pour voir comment le mode de projection peut être modifié de sorte que le contenu local soit rendu au même niveau de qualité de reprojection que sans ARR.

Z-fighting

Bien qu’ARR propose une fonctionnalité d’atténuation du Z-fighting, il est possible que le Z-fighting soit encore visible dans la scène. Ce guide vise à résoudre ce problème.

Utilisez le workflow suivant pour atténuer le Z-fighting  :

  1. Testez la scène avec les paramètres par défaut d’ARR (atténuation du Z-fighting activée).

  2. Désactivez l’atténuation du Z-fighting par le biais de son API.

  3. Changez les plans proche et lointain de la caméra de façon à obtenir une plage plus proche.

  4. Résolvez les problèmes de la scène à l’aide de la section suivante.

Examen du Z-fighting restant

Si vous avez effectué les étapes ci-dessus et que le Z-fighting restant est inacceptable, vous devez en rechercher la cause sous-jacente. Comme indiqué dans la page de fonctionnalité d’atténuation du Z-fighting, il existe deux raisons principales pour la présence de Z-fighting : la perte de précision de profondeur à l’extrémité lointaine de la plage de profondeur, et des surfaces qui se croisent tout en étant coplanaires. La perte de précision de profondeur est une éventualité mathématique qui ne peut être atténuée qu’en effectuant l’étape 3 ci-dessus. Des surfaces coplanaires traduisent un défaut d’élément multimédia source, et il est préférable de les corriger dans les données sources.

ARR dispose d’une fonctionnalité permettant de déterminer si les surfaces pourraient se battre : mise en surbrillance du checkerboard. Vous pouvez également déterminer visuellement ce qui provoque le Z-fighting. La première animation ci-dessous montre un exemple de perte de précision de profondeur dans la distance, tandis que la deuxième montre un exemple de surfaces presque coplanaires :

Animation shows an example of depth-precision loss in the distance.Animation shows an example of nearly coplanar surfaces.

Comparez ces exemples à votre z-fighting pour déterminer la cause racine ou suivez éventuellement ce flux de travail pas à pas :

  1. Placez la caméra au-dessus des surfaces Z-fighting pour regarder directement la surface.
  2. Reculez lentement la caméra afin de l’éloigner des surfaces.
  3. Si le Z-fighting est visible à tout moment, les surfaces sont parfaitement coplanaires.
  4. Si le Z-fighting est visible la plupart du temps, les surfaces sont presque coplanaires.
  5. Si le Z-fighting est uniquement visible de loin, la cause est un manque de précision de profondeur.

Les surfaces coplanaires peuvent avoir de nombreuses causes différentes :

  • Un objet a été dupliqué par l’application d’exportation en raison d’une erreur ou d’approches de workflow différentes.

    Vérifiez ces problèmes avec l’application concernée.

  • Les surfaces sont dupliquées et retournées de façon à apparaître recto verso dans les convertisseurs qui utilisent le front-face ou back-face culling.

    L’importation par le biais de la conversion de modèle détermine le côté principal du modèle. Le caractère bilatéral est considéré comme la valeur par défaut. La surface est rendue sous la forme d’un mur mince avec un éclairage physiquement correct des deux côtés. Le caractère unilatéral peut être impliqué par des indicateurs dans l’élément multimédia source, ou forcé explicitement pendant la conversion de modèle. En outre, mais de manière facultative, le mode unilatéral peut être défini sur « normal ».

  • Des objets se croisent dans les éléments multimédias sources.

    Un Z-fighting peut aussi être créé quand des objets sont transformés de telle manière que certaines de leurs surfaces se chevauchent. La transformation de certaines parties de l’arborescence de la scène dans la scène importée dans ARR peut également créer ce problème.

  • Des surfaces sont intentionnellement créées pour se toucher, comme des décalques ou du texte sur des murs.

Artefacts graphiques utilisant le rendu stéréo à plusieurs passes dans les applications C++ natives

Dans certains cas, les applications C++ natives qui utilisent un mode de rendu stéréo à plusieurs passes pour le contenu local (rendu gauche et droite dans des passes séparées) après l’appel de BlitRemoteFrame peuvent déclencher un bogue du pilote. Le bogue entraîne des problèmes de pixellisation non déterministes, provoquant la disparition aléatoire de triangles individuels ou de parties de triangles du contenu local. Pour des raisons de performances, il est de toute manière recommandé de rendre le contenu local avec une technique de rendu stéréo en une seule passe plus moderne, par exemple à l’aide de SV_RenderTargetArrayIndex.

Erreurs de téléchargement du fichier de conversion

Le service de conversion peut rencontrer des erreurs lors du téléchargement de fichiers à partir du stockage d’objets blob en raison de limitations du système de fichiers. Les cas de défaillance spécifiques sont répertoriés ci-dessous. Vous trouverez des informations complètes sur les limitations relatives au système de fichiers Windows dans la documentation relative au nommage des fichiers, chemins d’accès et espaces de noms.

Chemin d’accès et nom de fichier conflictuels

Dans un stockage d’objets blob, il est possible de créer un fichier et un dossier portant exactement le même nom que des entrées sœurs. Le système de fichiers Windows n’autorise pas cela. En conséquence, le service émet une erreur de téléchargement dans ce cas.

Longueur des chemins d'accès

Windows et le service imposent des limites de longueur de chemin d’accès. Dans le Stockage Blob, les chemins et les noms de fichiers ne doivent pas dépasser 178 caractères. Par exemple, pour un blobPrefixmodels/Assets qui comporte 13 caractères :

models/Assets/<any file or folder path greater than 164 characters will fail the conversion>

Le service de conversion télécharge tous les fichiers spécifiés sous le blobPrefixfichier , pas seulement les fichiers utilisés dans la conversion. Les fichiers ou le dossier à l’origine des problèmes peuvent être moins évidents dans ce cas. Il est donc important de vérifier tout ce qui se trouve dans le compte de stockage situé sous blobPrefix. Consultez les exemples d’entrées ci-dessous pour savoir ce qui est téléchargé.

{
  "settings": {
    "inputLocation": {
      "storageContainerUri": "https://contosostorage01.blob.core.windows.net/arrInput",
      "blobPrefix": "models/Assets",
      "relativeInputAssetPath": "myAsset.fbx"
    ...
  }
}
models
├───Assets
│   │   myAsset.fbx                 <- Asset
│   │
│   └───Textures
│   |       myTexture.png           <- Used in conversion
│   |
|   └───MyFiles
|          myOtherFile.txt          <- File also downloaded under blobPrefix      
|           
└───OtherFiles
        myReallyLongFileName.txt    <- Ignores files not under blobPrefix             

HoloLens2 « Prendre une image » (CRM) n’affiche aucun contenu local ou distant

Ce problème se produit généralement si un projet est mis à jour de WMR vers OpenXR et que le projet a accédé aux paramètres de la classe HolographicViewConfiguration (Windows.Graphics.Holographic). Cette API n’est pas prise en charge dans OpenXR et ne doit pas être accessible.

Étapes suivantes