Condividi tramite


Gestione di condizioni eccezionali

Nella maggior parte dei casi, WLT può rilevare e correggere gli errori di rilevamento senza coinvolgere l'applicazione.

Tuttavia, alcune condizioni eccezionali portano a errori a cui l'applicazione potrebbe voler adattarsi.

La perdita di rilevamento è un esempio di tale condizione.

Il rilevamento potrebbe essere perso in qualsiasi momento, per diversi motivi. I sensori potrebbero essere coperti, l'illuminazione potrebbe essere inadeguata o potrebbero non esserci caratteristiche visibili intorno alla fotocamera per tracciare.

Le discussioni più complete su queste condizioni eccezionali a livello concettuale, incluse le funzionalità di WLT volte a attenuarle, sono contenute altrove in questa documentazione.

In questo caso verrà illustrato come lo sviluppatore di applicazioni può (facoltativamente) sfruttare tali funzionalità per personalizzare il comportamento dell'applicazione durante queste condizioni eccezionali.

AttachmentPoints

Come illustrato più in dettaglio qui, un punto di allegato è il contratto tra WLT e l'applicazione, per notificare che si sono verificate condizioni eccezionali, insieme ai dati appropriati che l'applicazione può usare per rispondere.

Componenti di Regolazione

Un'implementazione di tali risposte dell'applicazione è disponibile sotto forma di componenti "regolatore". Il principale di questi è il componente AdjusterFixed .

L'oggetto AdjusterFixed può essere usato così com'è, ma capire cosa può fare può essere utile, soprattutto per uno sviluppatore che vuole personalizzare ulteriormente il comportamento.

È importante riconoscere che i componenti di Adjuster servono due ruoli:

  1. Gestiscono l'oggetto AttachmentPoint sottostante.
  2. Forniscono implementazioni delle risposte dell'applicazione a condizioni eccezionali.

Gestione attachmentPoint

L'analisi dei Start() membri e OnDestroy() acquisisce la maggior parte della gestione di AttachmentPoint necessaria.

In Start()viene creato l'oggetto AttachmentPoint sottostante, assegnando le funzioni membro di AdjusterFixed come callback (vedere di seguito).

In OnDestroy()queste connessioni di callback vengono interrotte e attachmentPoint rilasciato.

Gestione delle condizioni dei callback

I due callback implementano il comportamento desiderato dell'applicazione durante queste condizioni eccezionali.

Gestione dello stato di rilevamento

In HandleStateAdjust()il componente AdjusterFixed disabilita gli oggetti contenuti in un frammento che non viene attualmente rilevato.

        protected virtual void HandleAdjustState(AttachmentPointStateType state)
        {
            bool visible = state == AttachmentPointStateType.Normal;
            if (visible != gameObject.activeSelf)
            {
                gameObject.SetActive(visible);
            }
        }

Anche se questo comportamento semplice è perfetto per molte applicazioni, è facile immaginare casi in cui non sarebbe sufficiente.

  1. L'oggetto deve essere nascosto, ma non disabilitato (deve continuare l'aggiornamento).
  2. È preferibile un metodo alternativo per nascondere l'oggetto ,ad esempio spostandolo oltre il piano di ritaglio lontano.
  3. Invece di nascondere l'oggetto, deve essere sottoposto a rendering con un materiale diverso (ad esempio, materiale a raggi X).
  4. Anziché nascondere l'oggetto, è necessario eseguire il rendering di un oggetto alternativo.
  5. Altro.

Fortunatamente, lo sviluppatore di applicazioni è libero di implementare uno di questi comportamenti o altri comportamenti solo limitati dall'immaginazione.

Il modo più semplice per specificare il comportamento personalizzato consiste nell'implementare un componente personalizzato derivato da AdjusterFixed. La gestione attachmentPoint può quindi essere ereditata e i gestori sottoposti a override per creare il comportamento personalizzato.

Gestione del riposizionamento

Come descritto nella documentazione concettuale, il sistema WLT può decidere che un oggetto può essere mantenuto al meglio nella sua posizione nel mondo fisico riposizionandolo nello spazio bloccato. Informerà l'applicazione di tale situazione tramite il meccanismo AttachmentPoint.

L'applicazione, naturalmente, è libera di ignorare tali rettifiche. Tuttavia, il comportamento fornito dal componente AdjusterFixed (e AdjusterMoving) consiste nell'applicare immediatamente tale trasformazione di riposizionamento.

        protected virtual void HandleAdjustLocation(Pose adjustment)
        {
            Pose pose = gameObject.transform.GetGlobalPose();
            pose = adjustment.Multiply(pose);
            gameObject.transform.SetGlobalPose(pose);
        }

Questo è quasi sempre ciò che l'applicazione vuole. La domanda potrebbe essere posta, quindi, del motivo per cui chiunque vuole eseguire l'override della HandlePositionAdjust() funzione AdjusterFixed.

La risposta, naturalmente, è che l'applicazione potrebbe voler eseguire altre azioni oltre a correggere la posizione. Un effetto materiale temporaneo può aiutare a informare l'utente che è stata apportata una modifica. Il riposizionamento potrebbe essere distribuito in pochi secondi. In alternativa, se un riposizionamento è troppo drastico, l'applicazione potrebbe preferire rimuovere l'oggetto anziché spostarlo.

AdjusterFixed e AdjusterMoving

Un'analisi più approfondita del componente AdjusterMoving mostra che è quasi identica al componente AdjusterFixed da cui deriva.

La differenza tra i due è che AdjusterMoving presuppone che la destinazione venga costantemente spostata nell'ambiente. Pertanto, ogni aggiornamento notifica al sistema WLT della nuova pose.

Il costo di AdjusterMoving deriva principalmente dall'aggiunta di una funzione Update(), anziché dal lavoro svolto all'interno della funzione. Tuttavia, per un oggetto che è "principalmente" stazionario e viene spostato raramente dallo script, può essere vantaggioso usare un componente AdjusterFixed e chiamare AdjusterFixed.UpdatePosition() dopo ogni spostamento dell'oggetto.

Personalizzare il comportamento, ma solo se si vuole

Anche in questo caso, il modello è auspicabilmente coerente in tutti gli strumenti di blocco globale. WLT offre un comportamento di base semplice ma generalmente utile. Si spera che questa implementazione sia:

  1. Soddisfare le esigenze dell'applicazione.
  2. Fornire un'implementazione di base da migliorare.
  3. Fornire un'implementazione di esempio da cui è possibile passare in modo selvaggio.

Vedi anche