Risoluzione dei problemi

Questa pagina elenca i problemi comuni che interferiscono con Rendering remoto di Azure e i metodi per risolverli.

Il client non riesce a connettersi al server

Assicurarsi che i firewall (nel dispositivo, all'interno dei router e così via) non blocchino le porte indicate nei requisiti di sistema.

Non è stato possibile caricare il modello

Quando si carica un modello (ad esempio, tramite un esempio unity) ha esito negativo anche se la configurazione del BLOB è corretta, è probabile che l'archiviazione BLOB non sia collegata correttamente. Il collegamento corretto è illustrato nel capitolo collegamento di un account di archiviazione. Dopo aver corretto il collegamento, possono essere necessari fino a 30 minuti fino a quando le modifiche non diventano effettive.

Non è possibile collegare l'account di archiviazione all'account ARR

In alcuni casi, durante il collegamento di un account di archiviazione, l'account di Rendering remoto non è presente nell'elenco. Per risolvere questo problema passare all'account ARR nel portale di Azure e selezionare Identità nel gruppo Impostazioni a sinistra. Verificare che Stato sia impostato su Attivo.

Impossibile caricare il modello tramite un token di firma di accesso condiviso

Se l'applicazione client non riesce a caricare un modello dall'archiviazione tramite un token di firma di accesso condiviso valido, potrebbe essere dovuto al livello di accesso alla rete pubblica configurato nell'archiviazione BLOB. Il caricamento di un modello ARR dal token di firma di accesso condiviso funziona solo se è stato configurato con l'opzione "Abilitato da tutte le reti":

Se la limitazione agli endpoint privati è un requisito, l'account di archiviazione deve essere collegato e il modello deve essere caricato tramite il percorso del codice non SAS, come descritto qui.

Errore 'Disconnected: VideoFormatNotAvailable'

Verificare che la GPU supporti la decodifica video hardware. Vedere PC di sviluppo.

Se si lavora su un computer portatile con due GPU, è possibile che la GPU su cui l'utente esegue operazioni per impostazione predefinita non fornisca funzionalità di decodifica video hardware. In tal caso, provare a forzare l'uso dell'altra GPU nell'app. La modifica della GPU usata è spesso possibile nelle impostazioni del driver GPU.

Errore durante il recupero dello stato della sessione/conversione

L'invio di comandi dell'API REST troppo frequentemente causa la limitazione e la restituzione dell'errore da parte del server. Il codice di stato HTTP nel caso di limitazione è 429 ("troppe richieste"). Come regola generale, è necessario un ritardo di 5-10 secondi tra chiamate successive.

Si noti che questo limite non influisce solo sulle chiamate API REST quando viene chiamato direttamente, ma anche sulle controparti C#/C++, ad esempio Session.GetPropertiesAsync, Session.RenewAsync o Frontend.GetAssetConversionStatusAsync. Alcune funzioni restituiscono anche informazioni quando vengono salvate per riprovare. Ad esempio, RenderingSessionPropertiesResult.MinimumRetryDelay specifica il numero di secondi di attesa prima di tentare un'altra verifica. Se disponibile, l'uso di un valore restituito di questo tipo è ottimale, in quanto consente di eseguire controlli il più spesso possibile, senza essere limitati.

Se si verifica una limitazione lato server, modificare il codice per eseguire le chiamate meno frequentemente. Il server reimposta lo stato di limitazione ogni minuto, quindi è possibile eseguire nuovamente il codice dopo un minuto.

Il codec H265 non è disponibile

Esistono due motivi per cui il server potrebbe rifiutare di connettersi con un errore di codec not available.

Il codec H265 non è installato:

Assicurarsi anzitutto di aver installato le estensioni video HEVC come indicato nella sezione Software dei requisiti di sistema.

Se ancora si riscontrano problemi, verificare che la scheda grafica supporti il codec H265 e che sia installato il driver grafico più recente. Per informazioni specifiche del fornitore, vedere la sezione PC di sviluppo dei requisiti di sistema.

Il codec è installato, ma non può essere usato:

Il motivo di questo problema è un'impostazione di sicurezza non corretta per le DLL. Questo problema non viene rilevato quando si tenta di guardare video codificati con il codec H265. Reinstallare il codec non risolve il problema. In tal caso, seguire la procedura seguente:

1. Aprire una sessione di PowerShell con diritti di amministratore e avviare l'esecuzione

   Get-AppxPackage -Name Microsoft.HEVCVideoExtension*
   

   Si noti che "*" è dovuto al fatto che per alcune versioni di installazione del pacchetto il nome è HEVCVideoExtensions anziché HEVCVideoExtension. Il comando deve restituire il parametro InstallLocation del codec, ad esempio:

   InstallLocation   : C:\Program Files\WindowsApps\Microsoft.HEVCVideoExtension_1.0.23254.0_x64__5wasdgertewe
   

2. Aprire la cartella in Esplora risorse

3. Si dovrebbero visualizzare le sottocartelle x86 e x64. Fare clic con il pulsante destro del mouse su una delle cartelle e scegliere Proprietà

   1. Selezionare la scheda Sicurezza e selezionare il pulsante delle impostazioni Avanzate
   2. Selezionare Modifica per Proprietario
   3. Digitare Amministratori nel campo di testo
   4. Selezionare Controlla nomi e quindi su OK

4. Ripetere la procedura precedente per l'altra cartella

5. Ripetere i passaggi precedenti anche in ogni file DLL all'interno di entrambe le cartelle. Dovrebbero essere presenti quattro DLL.

Per verificare che le impostazioni siano corrette, seguire questa procedura per ognuna delle quattro DLL:

1. Fai clic su Proprietà > Sicurezza > Modifica
2. Scorrere l'elenco di tutti i Gruppi/utenti e assicurarsi che per ognuno sia stato impostato il diritto Lettura ed esecuzione (deve essere presente il segno di spunta nella colonna Consenti)

Qualità video scarsa

La qualità del video può essere compromessa dalla qualità della rete o dall'assenza del codec video H265.

• Vedere i passaggi per identificare i problemi di rete.
• Vedere i requisiti di sistema per l'installazione del driver di grafica più recente.

I video registrati con MRC non riflettono la qualità dell'esperienza dal vivo

Un video può essere registrato in HoloLens tramite MRC (Mixed Reality Capture, Acquisizione di Realtà mista). Il video risultante presenta tuttavia una qualità peggiore rispetto all'esperienza dal vivo per due motivi:

• La frequenza di fotogrammi del video è limitata a 30 Hz e non a 60 Hz.
• Le immagini del video saltano il passaggio di elaborazione della riproiezione con ritardo della fase, pertanto il video ha un aspetto maggiormente mosso.

Entrambe sono limitazioni intrinseche della tecnica di registrazione.

Schermata nera dopo il completamento del caricamento del modello

Se dopo essersi connessi al runtime di rendering e aver caricato correttamente un modello viene visualizzata una schermata nera, possono esservi diverse cause.

Si consiglia di provare le soluzioni seguenti prima di svolgere un'analisi più approfondita:

• Il codec H265 è installato? Sebbene sia previsto un fallback per il codec H264, sono stati riscontrati casi in cui tale fallback non funzionava correttamente. Vedere i requisiti di sistema per l'installazione del driver di grafica più recente.
• Quando si lavora con un progetto di Unity, chiudere Unity, eliminare la libreria temporanea e le cartelle obj nella directory del progetto e caricare/creare nuovamente il progetto. In alcuni casi, i dati memorizzati nella cache hanno impedito il funzionamento corretto dell'esempio, senza nessun motivo apparente.

Se questi due passaggi non sono stati utili, è necessario verificare se i fotogrammi del video vengono ricevuti o meno dal client. La query può essere eseguita a livello di codice come indicato nel capitolo Query sulle prestazioni lato server. Il parametro FrameStatistics struct presenta un membro che indica il numero di fotogrammi video ricevuti. Se il numero è maggiore di 0 e aumenta nel tempo, il client riceve i fotogrammi video effettivi dal server. Di conseguenza, deve trattarsi di un problema lato client.

Il valore di ridimensionamento nelle impostazioni di conversione non viene applicato al modello

Se un modello viene visualizzato in Showcase o Avvio rapido con scalabilità invariata anche se viene applicata una scalabilità come parte dei parametri geometrici delle impostazioni di conversione , questo è probabilmente dovuto alla funzionalità di ridimensionamento automatico predefinita dell'esempio. Ovvero, l'esempio ridimensiona il modello per adattarsi al frustum di visualizzazione, indipendentemente dal ridimensionamento dell'input.

Nel caso di Showcase, il ridimensionamento automatico può essere disabilitato specificando un MaxSize pari a zero nella sezione Transform del modello all'interno del file models.xml. Questo approccio basato sui dati richiede che il modello venga caricato tramite il codice XML in primo luogo, perché in tutti gli altri casi MaxSize per impostazione predefinita è 1 contatore. Esiste anche una proprietà MinSize che per impostazione predefinita è pari a 0,5 metri, causando l'aumento delle prestazioni di tutti i modelli più piccoli. Per altre informazioni sui modi per caricare i modelli in Showcase, vedere il capitolo Aggiunta di asset di modelli 3D a ARR Showcase della documentazione di Showcase.

Problemi comuni lato client

Il modello supera i limiti della macchina virtuale selezionata, in particolare il numero massimo di primitive:

Vedere limiti specifici delle dimensioni del server.

Il modello non si trova all'interno del frustum della fotocamera:

In molti casi, il modello viene visualizzato correttamente ma si trova al di fuori del frustum della fotocamera. Una causa frequente potrebbe essere legata al fatto che il modello è stato esportato con una trasformazione tramite pivot decentrata in modo che venga ritagliato dal piano di ritaglio anteriore della fotocamera. Consente di eseguire una query sul rettangolo di selezione del modello a livello di codice e di visualizzare il riquadro di Unity come riquadro della riga o di stamparne i valori nel log di debug.

Inoltre, il processo di conversione genera un file json di output insieme al modello convertito. Per eseguire il debug dei problemi di posizionamento del modello è utile notare la voce boundingBox nella sezione outputStatistics:

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

Il rettangolo di selezione è descritto come una posizione min e max nello spazio 3D, con un valore espresso in metri. Di conseguenza, una coordinata di 1000,0 indica una distanza di 1 chilometro dall'origine.

Con questo rettangolo di selezione possono sorgere due problemi da ricondurre alla geometria invisibile:

• Il rettangolo può essere distante dal centro, quindi l'oggetto viene ritagliato completamente a causa del ritaglio del piano anteriore. I valori boundingBox in questo caso hanno un aspetto simile al seguente: min = [-2000, -5,-5], max = [-1990, 5,5], usando uno spostamento consistente sull'asse x come riportato nell'esempio di seguito. Per risolvere questo tipo di problema, abilitare l'opzione recenterToOrigin nella configurazione della conversione del modello.
• Il rettangolo può essere centrato ma gli ordini di grandezza sono troppo ampi. Ciò significa che, benché la fotocamera si avvii al centro del modello, la relativa geometria viene ritagliata in tutte le direzioni. In genere i valori boundingBox in questo caso hanno un aspetto simile al seguente: min = [-1000,-1000,-1000], max = [1000,1000,1000]. Il motivo di questo tipo di problema è solitamente una mancata corrispondenza nel dimensionamento delle unità. Per compensare, specificare un valore di ridimensionamento durante la conversione o contrassegnare il modello di origine con le unità corrette. Il dimensionamento può essere applicato anche al nodo radice durante il caricamento del modello al runtime.

La pipeline di rendering di Unity non include gli hook di rendering:

Rendering remoto di Azure include gli hook alla pipeline di rendering di Unity per eseguire la composizione del fotogramma con il video ed eseguire la riproiezione. Per verificare che questi hook esistano, aprire il menu Window > Analysis > Frame debugger. Abilitarlo e verificare la presenza di due voci per HolographicRemotingCallbackPass nella pipeline:

Per risolvere il problema, assicurarsi che venga usato l'asset HybridRenderingPipeline fornito:

...come descritto in modo più dettagliato nelle pipeline di rendering di Unity.

Il rendering del modello checkerboard viene eseguito dopo il caricamento del modello

Se l'immagine sottoposta a rendering è simile alla seguente:

il renderer raggiunge quindi i limiti del poligono per le dimensioni di configurazione standard. Per attenuare il problema, passare alla dimensione di configurazione Premium o ridurre il numero di poligoni visibili.

L'immagine sottoposta a rendering in Unity è capovolta

Assicurarsi di seguire l'esercitazione su Unity: Visualizzare esattamente i modelli remoti. Un'immagine rovesciata indica che è necessario Unity per creare una destinazione di rendering fuori schermo. Questo comportamento non è attualmente supportato e crea un impatto enorme sulle prestazioni su HoloLens 2.

I motivi di questo problema possono essere MSAA, HDR o abilitazione della post-elaborazione. Assicurarsi che il profilo di bassa qualità sia selezionato e impostato come predefinito in Unity. A tale scopo, passare a Modifica > Impostazioni progetto... > Qualità.

Quando si usa il plug-in OpenXR in Unity 2020, sono disponibili versioni dell'URP (Universal Render Pipeline) che creano questa destinazione di rendering extra fuori schermo indipendentemente dall'abilitazione della post-elaborazione. È quindi importante aggiornare manualmente la versione URP ad almeno 10.5.1 (o versione successiva). Questo processo di aggiornamento è descritto nei requisiti di sistema.

Il codice Unity che usa l'API di Rendering remoto non viene compilato

Eseguire il debug durante la compilazione per l'editor di Unity

Modificare il tipo di compilazione della soluzione Unity in Debug. Quando si esegue il test di ARR nell'editor di Unity, il parametro UNITY_EDITOR definito è disponibile solo nelle compilazioni di debug. Questa impostazione non è correlata al tipo di compilazione usato per le applicazioni distribuite, in cui è necessario preferire le compilazioni "Release".

Errori di compilazione quando si compilano esempi di Unity per HoloLens 2

Provando a compilare esempi di Unity (avvio rapido, ShowCaseApp, ...) per HoloLens 2 sono stati riscontati degli errori spuri. Visual Studio non è in grado di copiare alcuni file sebbene siano presenti. Se si rileva questo problema:

• Rimuovere tutti i file temporanei di Unity dal progetto e riprovare. Ciò significa chiudere Unity, eliminare la libreria temporanea e le cartelle obj nella directory del progetto e caricare/compilare nuovamente il progetto.
• Assicurarsi che i progetti si trovino in una directory su disco con un percorso ragionevolmente breve, dal momento che il passaggio di copia talvolta riscontra problemi con nomi di file troppo lunghi.
• Se la soluzione non è utile a risolvere il problema, è possibile che MS Sense interferisca con il passaggio di copia. Per configurare un'eccezione, eseguire questo comando del registro dalla riga di comando (sono necessari i diritti di amministratore):

  reg.exe ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection" /v groupIds /t REG_SZ /d "Unity"
  

Le build Arm64 per i progetti Unity hanno esito negativo perché manca AudioPluginMsHRTF.dll

Il AudioPluginMsHRTF.dll per Arm64 è stato aggiunto al pacchetto Windows Mixed Reality (com.unity.xr.windowsmr.metro) nella versione 3.0.1. Assicurarsi di avere installato la versione 3.0.1 o successiva tramite Gestione pacchetti Unity. Dalla barra dei menu di Unity passare a Finestra > Gestione pacchetti e cercare il pacchetto di Windows Mixed Reality.

Il plug-in Unity Cinemachine non funziona in modalità pose remota

In modalità pose remota, il codice di associazione unity ARR crea in modo implicito una fotocamera proxy che esegue il rendering effettivo. In questo caso, la maschera di selezione della fotocamera principale è impostata su 0 ("nulla") per disattivare efficacemente il rendering per esso. Tuttavia, alcuni plug-in di terze parti (ad esempio Cinemachine) che guidano la fotocamera, possono basarsi su almeno alcuni bit di livello da impostare.

A questo scopo, il codice di associazione consente di modificare a livello di codice la maschera di bit del livello per la fotocamera principale. In particolare, sono necessari i passaggi seguenti:

1. Creare un nuovo livello in Unity che non viene usato per il rendering di qualsiasi geometria della scena locale. In questo esempio si supponga che il livello sia denominato "Cam".
2. Passare questa maschera di bit ad ARR in modo che ARR lo imposti sulla fotocamera principale:

   RemoteManagerUnity.CameraCullingMask = LayerMask.GetMask("Cam");
   

3. Configurare le proprietà Cinemachine per l'uso di questo nuovo livello:

La modalità di posa locale non è influenzata da questo problema, perché in questo caso l'associazione ARR non reindirizza il rendering a una fotocamera proxy interna.

L'applicazione basata su C++ nativa non viene compilata

Errore 'Libreria non trovata' per l'applicazione UWP o la DLL

All'interno del pacchetto NuGet C++ è presente un file microsoft.azure.remoterendering.Cpp.targets che definisce quale del sapore binario usare. Per identificare UWP, le condizioni nel file controllano la presenza di ApplicationType == 'Windows Store'. È quindi necessario assicurarsi che questo tipo sia impostato nel progetto. Ciò dovrebbe verificarsi quando si crea un'applicazione UWP o una DLL tramite la procedura guidata del progetto di Visual Studio.

Ologrammi instabili

Se gli oggetti di cui è stato eseguito il rendering sembrano sportarsi con i movimenti della testa, potrebbe trattarsi di problemi con la Riproiezione con ritardo della fase. Per istruzioni su come affrontare una situazione di questo tipo, fare riferimento alla sezione in Riproiezione con ritardo della fase.

Gli ologrammi instabili (oscillazione, distorsione, tremolio o salto degli ologrammi) possono derivare anche da una connettività di rete insufficiente, in particolare da una larghezza di banda di rete insufficiente o una latenza troppo elevata. Un buon indicatore per la qualità della connessione di rete è il valore sulle statistiche delle prestazioniServiceStatistics.VideoFramesReused. I fotogrammi riusati indicano situazioni in cui è necessario riusare un fotogramma video precedente sul lato client perché non è disponibile alcun nuovo fotogramma video, ad esempio a causa di una perdita di pacchetti o di variazioni nella latenza di rete. Se il valore ServiceStatistics.VideoFramesReused è spesso superiore a 0, significa che si è riscontrato un problema di rete.

Un altro valore da esaminare è ServiceStatistics.LatencyPoseToReceiveAvg. Deve essere sempre inferiore a 100 ms. La visualizzazione di valori più elevati potrebbe indicare che si è connessi a un data center troppo lontano.

Per un elenco delle possibili mitigazioni, vedere le Linee guida per la connettività di rete.

Contenuto locale (interfacce utente, ...) in HoloLens 2 esegue il rendering con artefatti di distorsione significativamente più di quelli senza ARR

Questo artefatto è dovuto a un'impostazione predefinita che scambia la qualità della proiezione del contenuto locale per le prestazioni di runtime. Fare riferimento al capitolo sulle modalità di posa di riprogettazione per vedere come è possibile modificare la modalità di proiezione in modo che il rendering del contenuto locale venga eseguito allo stesso livello di qualità di riprogettazione come senza ARR.

Z-fighting

Mentre ARR offre funzionalità di mitigazione dell’effetto z-fighting, l’effetto z-fighting può ancora essere visualizzato nella scena. Questa guida mira a risolvere questi problemi rimanenti.

Procedure consigliate

Usare il flusso di lavoro seguente per attenuare l’effetto z-fighting:

1. Testare la scena con le impostazioni predefinite di ARR (mitigazione dell’effetto z-fighting su)

2. Disabilitare la mitigazione dell’effetto z-fighting tramite l'API

3. Cambia il piano della telecamera vicino e lontano a una distanza più ravvicinata

4. Risolvere i problemi della scena tramite la sezione successiva

Analisi dell’effetto z-fighting rimanente

Se i passaggi precedenti sono stati esauriti e il rimanente effetto z-fighting è inaccettabile, deve essere analizzata la causa sottostante dell’effetto z-fighting. Come indicato nella pagina delle funzionalità di mitigazione dell’effetto z-fighting, esistono due motivi principali per l’effetto z-fighting: la perdita di precisione della profondità all'estremità dell'intervallo di profondità e le superfici che si intersecano mentre sono coplanari. La perdita di precisione della profondità è una finale matematica e può essere mitigata solo seguendo il passaggio 3 precedente. Le superfici coplanari indicano un difetto dell'asset di origine e sono più corrette nei dati di origine.

ARR ha una funzionalità per determinare se le superfici potrebbero contrastare l’effetto z: evidenziazione della scacchiera. È anche possibile determinare visivamente ciò cosa causa l’effetto z-fighting. La prima animazione seguente mostra un esempio di perdita di precisione della profondità nella distanza e la seconda mostra un esempio di superfici quasi coplanari:

Confrontare questi esempi con il proprio effetto z-fighting per determinare la causa radice o, facoltativamente, seguire questo flusso di lavoro dettagliato:

1. Posizionare la fotocamera sopra le superfici dello z-fighting per guardare direttamente la superficie.
2. Spostare lentamente la fotocamera all'indietro, lontano dalle superfici.
3. Se l’effetto z-fighting è visibile tutto il tempo, le superfici sono perfettamente coplanari.
4. Se l’effetto z-fighting è visibile la maggior parte del tempo, le superfici sono quasi coplanari.
5. Se l’effetto z-fighting è visibile solo da lontano, la causa è la mancanza di precisione di profondità.

Le superfici coplanari possono avere molte cause diverse:

• Un oggetto è stato duplicato dall'applicazione di esportazione a causa di un errore o di approcci diversi al flusso di lavoro.

  Verificare questi problemi con l'applicazione e il supporto dell'applicazione corrispondenti.

• Le superfici vengono duplicate e capovolte per essere visualizzate a doppio lato nei renderer che usano la facciata anteriore o posteriore.

  L'importazione tramite la conversione del modello determina la entità principale del modello. L'impostazione predefinita è l'impostazione predefinita per il doppio nesso. La superficie viene sottoposta a rendering come un muro sottile con illuminazione fisicamente corretta da entrambi i lati. La modalità a lato singolo può essere implicita dai flag nell'asset di origine o forzata in modo esplicito durante la conversione del modello. Facoltativamente, tuttavia, la modalità a lato singolo può essere impostata su "normale".

• Gli oggetti si intersecano negli asset di origine.

  Anche gli oggetti trasformati in modo che alcune delle loro superfici si sovrappongano creano fenomeni di z-fighting. La trasformazione di parti dell'albero della scena nella scena importata in ARR può anche creare questo problema.

• Le superfici sono create appositamente per toccare, ad esempio decalcomanie o testo sulle pareti.

Artefatti grafici che usano il rendering stereo a più passaggi nelle app C++ native

In alcuni casi, app C++ native personalizzate che usano una modalità di rendering stereo a più passaggi per il contenuto locale (rendering a sinistra e destra in passaggi separati) dopo la chiamata di BlitRemoteFrame può attivare un bug del driver. Il bug causa errori di rasterizzazione non deterministici, causando la scomparsa casuale di singoli triangoli o parti di triangoli del contenuto locale. Per motivi di prestazioni, è comunque consigliabile eseguire il rendering del contenuto locale con una tecnica di rendering stereo a passaggio singolo più moderna, ad esempio usando SV_RenderTargetArrayIndex.

Errori di download del file di conversione

Il servizio di conversione può riscontrare errori durante il download di file dall'archivio BLOB a causa delle limitazioni del file system. Di seguito sono elencati casi di errore specifici. Informazioni complete sulle limitazioni del file system di Windows sono disponibili nella documentazione relativa ai nomi, ai percorsi e agli spazi dei nomi.

Percorso e nome file in collisione

Nell'archivio BLOB è possibile creare un file e una cartella con lo stesso nome delle voci di pari livello. Il file system di Windows non consente questo problema. Di conseguenza, il servizio genera un errore di download in tal caso.

Lunghezza dei percorsi

Esistono limiti di lunghezza del percorso imposti da Windows e dal servizio. I percorsi di file e i nomi di file nell'archivio BLOB non devono superare i 178 caratteri. Ad esempio, dato un blobPrefix di models/Assets, ovvero 13 caratteri:

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

Il servizio di conversione scarica tutti i file specificati in blobPrefix, non solo i file usati nella conversione. I file o le cartelle che causano problemi possono essere meno evidenti in questi casi, quindi è importante controllare tutti gli elementi contenuti nell'account di archiviazione in blobPrefix. Per informazioni su ciò che viene scaricato, vedere gli input di esempio seguenti.

{
  "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 'Scatta una foto' (MRC) non mostra alcun contenuto locale o remoto

Questo problema si verifica in genere se un progetto viene aggiornato da WMR a OpenXR e il progetto ha eseguito l'accesso alle impostazioni della classe HolographicViewConfiguration (Windows.Graphics.Holographic). Questa API non è supportata in OpenXR e non deve essere accessibile.

Passaggi successivi

• Requisiti di sistema
• Requisiti di rete