Panoramica del rendering olografico

Articolo
07/12/2023

Il rendering olografico consente all'applicazione di disegnare un ologramma in una posizione precisa in tutto il mondo intorno all'utente, indipendentemente dal fatto che si trovi esattamente nel mondo fisico o all'interno di un'area di autenticazione virtuale creata. Gli ologrammi sono oggetti fatti di suono e luce. Il rendering consente all'applicazione di aggiungere la luce.

Supporto di dispositivi

Funzionalità	HoloLens (prima generazione)	HoloLens 2	Visori VR immersive
Rendering	✔️	✔	✔

Rendering olografico

Chiave per il rendering olografico è sapere quale tipo di dispositivo viene usato. I dispositivi con display visualizzati, ad esempio HoloLens, aggiungono luce al mondo. I pixel neri sono completamente trasparenti, mentre i pixel più brillanti sono sempre più opachi. Poiché la luce dai display viene aggiunta alla luce dal mondo reale, i pixel bianchi sono traslucenti.

Mentre il rendering stereoscopico fornisce un segnale di profondità per gli ologrammi, l'aggiunta di effetti di base può aiutare gli utenti a vedere più facilmente la superficie di un ologramma. Una tecnica di terra consiste nell'aggiungere un bagliore intorno a un ologramma sulla superficie vicina e quindi rendere un'ombra contro questo bagliore. In questo modo, l'ombra sembra sottrarre la luce dall'ambiente. Il suono spaziale è un altro importante segnale di profondità, consentendo agli utenti di ragionare sulla distanza e sulla posizione relativa di un ologramma.

I dispositivi con display opachi, come Windows Mixed Reality visori immersivi, bloccano il mondo. I pixel neri sono nero a tinta unita e qualsiasi altro colore viene visualizzato come tale colore all'utente. L'applicazione è responsabile del rendering di tutti gli elementi visualizzati dall'utente. Ciò rende ancora più importante mantenere una frequenza di aggiornamento costante in modo che gli utenti abbiano un'esperienza confortevole.

Parametri di rendering stimati

Visori di realtà mista (sia HoloLens che visori immersivi) continuamente tiene traccia della posizione e dell'orientamento della testa dell'utente rispetto all'ambiente circostante. Quando l'applicazione inizia a preparare il frame successivo, il sistema stima la posizione in cui la testa dell'utente sarà in futuro al momento esatto in cui il frame viene visualizzato sui display. In base a questa stima, il sistema calcola la visualizzazione e le trasformazioni di proiezione da usare per tale frame. L'applicazione deve usare queste trasformazioni per produrre risultati corretti. Se le trasformazioni fornite dal sistema non vengono usate, l'immagine risultante non si allinea al mondo reale, causando disagio per l'utente.

Nota

Per prevedere in modo accurato quando un nuovo frame raggiungerà i display, il sistema misura costantemente la latenza end-to-end effettiva della pipeline di rendering dell'applicazione. Anche se il sistema si adatta alla lunghezza della pipeline di rendering, è possibile migliorare la stabilità dell'ologramma mantenendo la pipeline il più breve possibile.

Le applicazioni che usano tecniche avanzate per aumentare la stima del sistema possono eseguire l'override delle trasformazioni di visualizzazione e proiezione del sistema. Queste applicazioni devono comunque usare trasformazioni fornite dal sistema come base per le trasformazioni personalizzate per produrre risultati significativi.

Altri parametri di rendering

Quando si esegue il rendering di un frame, il sistema specifica il riquadro di visualizzazione back-buffer in cui l'applicazione deve disegnare. Questo riquadro di visualizzazione è spesso inferiore alla dimensione completa del buffer del frame. Indipendentemente dalle dimensioni del riquadro di visualizzazione, una volta eseguito il rendering della cornice dall'applicazione, il sistema esegue il backup dell'immagine per riempire l'intera gamma di visualizzazioni.

Per le applicazioni che non riescono a eseguire il rendering alla frequenza di aggiornamento necessaria, i parametri di rendering del sistema possono essere configurati per ridurre la pressione di memoria e il costo di rendering a costo di un aliasing di pixel aumentato. Il formato del buffer indietro può anche essere modificato, che per alcune app può aiutare a migliorare la larghezza di banda della memoria e la velocità effettiva dei pixel.

Il rendering frustum, risoluzione e framerate in cui viene chiesto al rendering dell'app potrebbe anche cambiare da frame a frame e potrebbe essere diverso nell'occhio sinistro e destro. Ad esempio, quando l'acquisizione di realtà mista (MRC) è attiva e la configurazione della visualizzazione della fotocamera foto/video non è esplicita, un occhio potrebbe essere sottoposto a rendering con un FOV o una risoluzione più grande.

Per qualsiasi frame specificato, l'app deve eseguire il rendering usando la trasformazione della visualizzazione, la trasformazione della proiezione e la risoluzione del viewport fornita dal sistema. Inoltre, l'applicazione non deve mai presupporre che qualsiasi rendering o parametro di visualizzazione rimanga fisso da frame a frame. I motori come Unity gestiscono tutte queste trasformazioni in oggetti fotocamera personalizzati in modo che lo spostamento fisico degli utenti e lo stato del sistema sia sempre rispettato. Se l'applicazione consente lo spostamento virtuale dell'utente attraverso il mondo (ad esempio usando il pollice su un gamepad), è possibile aggiungere un oggetto rig padre sopra la fotocamera che lo sposta intorno. In questo modo la fotocamera riflette sia il movimento virtuale che fisico dell'utente. Se l'applicazione modifica la trasformazione della visualizzazione, la trasformazione della proiezione o la dimensione del riquadro di visualizzazione fornita dal sistema, deve informare il sistema chiamando l'API di override appropriata.

Per migliorare la stabilità del rendering olografico, l'app deve fornire a Windows ogni frame il buffer di profondità usato per il rendering. Se l'app fornisce un buffer di profondità, deve avere valori di profondità coerenti, con profondità espressa in metri dalla fotocamera. Ciò consente al sistema di usare i dati di profondità per pixel per migliorare il contenuto se la testa dell'utente termina leggermente offset dalla posizione stimata. Se non si è in grado di fornire il buffer di profondità, è possibile fornire un punto attivo e normale, definendo un piano che taglia la maggior parte del contenuto. Se vengono forniti sia il buffer di profondità che un piano di messa a fuoco, il sistema potrebbe usare entrambi. In particolare, è utile fornire sia il buffer di profondità che un punto attivo che include un vettore di velocità quando l'applicazione visualizza ologrammi in movimento.

Per informazioni dettagliate su questo argomento, vedere Rendering in DirectX .

Fotocamere olografiche

Windows Mixed Reality introduce il concetto di fotocamera olografica. Le fotocamere olografiche sono simili alla fotocamera tradizionale trovata nei testi grafici 3D; definiscono sia le proprietà della fotocamera intrinseca (posizione e orientamento) che le proprietà della fotocamera intrinseca. Ad esempio, il campo di visualizzazione viene usato per visualizzare una scena 3D virtuale. A differenza delle fotocamere 3D tradizionali, l'applicazione non è in controllo della posizione, dell'orientamento e delle proprietà intrinseche della fotocamera. Invece, la posizione e l'orientamento della fotocamera olografica sono controllati in modo implicito dal movimento dell'utente. Lo spostamento dell'utente viene inoltrato all'applicazione in base a frame tramite una trasformazione di visualizzazione. Analogamente, le proprietà intrinseche della fotocamera sono definite dall'ottica calibrata del dispositivo e dalla cornice inoltrata tramite la trasformazione di proiezione.

In generale, l'applicazione eseguirà il rendering per una singola fotocamera stereo. Un ciclo di rendering affidabile supporterà più fotocamere e supporterà sia mono che fotocamere stereo. Ad esempio, il sistema potrebbe chiedere all'applicazione di eseguire il rendering da un punto di vista alternativo quando l'utente attiva una funzionalità come l'acquisizione di realtà mista (MRC), a seconda della forma del visore. Le applicazioni che possono supportare più fotocamere li ottengono optando per il tipo di telecamere che possono supportare.

Rendering dei volumi

Quando si esegue il rendering di mrI medici o volumi di ingegneria in 3D, le tecniche di rendering del volume vengono spesso usate. Queste tecniche possono essere interessanti nella realtà mista, in cui gli utenti possono naturalmente visualizzare tale volume da angoli chiave, semplicemente spostando la testa.

Risoluzioni supportate in HoloLens (prima generazione)

La dimensione max viewport è una proprietà di HolographicDisplay. HoloLens è impostato sulla dimensione massima del viewport, ovvero 720p (1268x720), per impostazione predefinita.
Le dimensioni del riquadro di visualizzazione possono essere modificate impostando ViewportScaleFactor in HolographicCamera. Questo fattore di scala è compreso tra 0 e 1.
Le dimensioni più basse supportate del viewport in HoloLens (prima generazione) sono pari al 50% del 720p, ovvero 360p (634x360). Si tratta di un viewportScaleFactor di 0.5.
Qualsiasi elemento inferiore a 540p non è consigliato a causa della riduzione visiva, ma può essere usato per identificare i colli di bottiglia nella frequenza di riempimento dei pixel.

Risoluzioni supportate su HoloLens 2

Le dimensioni di destinazione di rendering correnti e massime supportate sono proprietà della configurazione della visualizzazione. HoloLens 2 è impostato sulla dimensione massima di destinazione di rendering, ovvero 1440x936, per impostazione predefinita.
Le app possono modificare le dimensioni dei buffer di destinazione di rendering chiamando il metodo RequestRenderTargetSize per richiedere una nuova dimensione di destinazione di rendering. Verrà scelta una nuova dimensione di destinazione di rendering, che soddisfa o supera le dimensioni di destinazione di rendering richieste. Questa API modifica le dimensioni del buffer di destinazione di rendering, che richiede la riallocazione della memoria nella GPU. Le implicazioni di questo includono: le dimensioni della destinazione di rendering possono essere ridimensionate per ridurre la pressione della memoria sulla GPU e questo metodo non deve essere chiamato ad alta frequenza.
Le app possono comunque modificare le dimensioni del riquadro di visualizzazione nello stesso modo in cui hanno fatto per HoloLens 1. Non è presente alcuna riallocazione della memoria aggiunta nella GPU, quindi può essere modificata ad alta frequenza, ma non può essere usata per ridurre la pressione della memoria sulla GPU.
Le dimensioni più basse supportate del viewport in HoloLens 2 sono 634x412, un viewportScaleFactor di circa 0,44 quando la dimensione predefinita della destinazione di rendering è in uso.
Se viene fornita una dimensione della destinazione di rendering inferiore alla dimensione del riquadro di visualizzazione supportata più bassa, il fattore di scala del riquadro di visualizzazione verrà ignorato.
Qualsiasi elemento inferiore a 540p non è consigliato a causa della riduzione visiva, ma può essere usato per identificare i colli di bottiglia nella frequenza di riempimento dei pixel.