Gestione di condizioni eccezionali

Nella maggior parte dei casi, WLT è in grado di rilevare e correggere gli errori di rilevamento senza il coinvolgimento dell'applicazione.

Tuttavia, alcune condizioni eccezionali causano errori a cui l'applicazione potrebbe volersi adattare.

La perdita di rilevamento è un esempio di tale condizione.

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

Discussioni più complete su queste condizioni eccezionali a livello concettuale, incluse le funzionalità del 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 descritto 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 di "regolazione". Il principale di questi è il componente AdjusterFixed .

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

È importante riconoscere che i componenti di Rettificatore fungono da due ruoli:

  1. Gestiscono l'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 attachmentPoint sottostante, assegnando le funzioni membro di AdjusterFixed come callback (vedere di seguito).

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

Callback di gestione delle condizioni

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 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 potrebbe 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 eliminare 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 sua 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" fisso 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 è probabilmente coerente in tutti gli strumenti di blocco mondiale. WLT offre un comportamento di base semplice ma generalmente utile. Si spera che questa implementazione:

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

Vedi anche