Поделиться через


Обработка исключительных условий

В большинстве случаев WLT может обнаруживать и устранять ошибки отслеживания без вмешательства приложения.

Но некоторые исключительные условия приводят к ошибкам, к которым приложению может потребоваться приспособиться.

В качестве примера такого условия можно назвать утрату отслеживания.

Отслеживание может быть потеряно в любой момент времени по ряду причин. Возможно, будут закрыты датчики, освещение станет недостаточным, или вокруг камеры не будет видимых объектов, которые камера может использовать для отслеживания.

Более полное обсуждение этих исключительных условий на концептуальном уровне, включая функции WLT, направленные на их устранение, приведено в других частях этой документации.

Здесь мы рассмотрим, как разработчик приложения может (при желании) использовать преимущества этих функций для настройки поведения приложения во время этих исключительных условий.

AttachmentPoints

Как уже говорилось здесь, точка прикрепления — это контракт между WLT и приложением об уведомлении о возможных исключительных условиях, а также соответствующие данные, которые приложение может использовать для ответа.

Компоненты корректировки

Реализация таких ответов приложений доступна в форме компонентов корректировки. Основным из них является компонент AdjusterFixed.

AdjusterFixed можно использовать "как есть", но понимание принципов его работы будет полезным, особенно для разработчиков, желающих выполнить дальнейшую настройку поведения.

Важно понимать, что компоненты корректировки выполняют две роли:

  1. они управляют базовым объектом AttachmentPoint;
  2. они предоставляют реализации ответов приложения на исключительные условия.

Управление AttachmentPoint

Для практически всего необходимого управления AttachmentPoint достаточно изучить члены Start() и OnDestroy().

В Start() создается базовый объект AttachmentPoint, предоставляя функции-члены AdjusterFixed в качестве обратных вызовов (см. ниже).

В OnDestroy() эти соединения обратного вызова отсекается, и AttachmentPoint освобождается.

Обратные вызовы, обрабатывающие условия

Два обратных вызова реализуют требуемое поведение приложения во время этих исключительных условий.

Обработка состояния отслеживания

В HandleStateAdjust() компонент AdjusterFixed отключает объекты, содержащиеся в фрагменте, который в настоящее время не отслеживается.

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

Хотя это простое поведение идеально подходит для многих приложений, легко представить ситуации, когда его не будет достаточно.

  1. Объект должен быть скрытым, но не отключенным (должен продолжать обновляться).
  2. Предпочтительнее использовать альтернативный метод скрытия объекта (например, перемещение его за пределы дальней плоскости усечения).
  3. Вместо скрытия объекта его следует визуализировать с другим материалом (например, с помощью ренгтеновского материала).
  4. Вместо того, чтобы скрывать объект, нужно визуализировать альтернативный объект.
  5. Прочее

К счастью, разработчик приложения может реализовать любое из этих поведений, или другие поведения, ограниченные лишь воображением.

Самым простым способом указания пользовательского поведения является реализация пользовательского компонента, производного от AdjusterFixed. Управление AttachmentPoint может быть унаследовано, а обработчики переопределяются для создания пользовательского поведения.

Обработка изменения расположения

Как описано в концептуальной документации, система WLT может решить, что объект лучше удерживать в его положении в физическом мире, изменив его расположение в замороженном пространстве. Она сообщит приложению эту ситуацию через механизм AttachmentPoint.

Конечно, приложение может игнорировать такие изменения. Однако поведение, предоставляемое компонентом AdjusterFixed (и AdjusterMoving), — немедленно применить преобразование изменения расположения.

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

Это почти всегда то, что требуется приложению. Тогда может возникнуть следующий вопрос: зачем какому-либо пользователю переопределять функцию HandlePositionAdjust() компонента AdjusterFixed?

Ответ заключается в том, что приложению может потребоваться выполнить другие действия в дополнение к исправлению этого положения. Временный эффект материала может помочь уведомить пользователя о внесении изменений. Изменение расположения может выполняться в течение нескольких секунд. Или, если изменение расположения слишком значительно, приложение может предпочесть отбросить объект, а не перемещать его.

AdjusterFixed и AdjusterMoving

Более подробное рассмотрение компонента AdjusterMoving показывает, что он почти идентичен компоненту AdjusterFixed, от которого он наследуется.

Различие между ними заключается в том, что AdjusterMoving предполагает, что его цель постоянно перемещается. Поэтому каждое обновление уведомляет систему WLT о своем новом положении.

Затраты на AdjusterMoving в основном связаны с добавлением функции Update(), а не от работы, выполняемой в функции. Однако для объекта, который является в основном стационарным и перемещается редко и только из сценария, можно использовать компонент AdjusterFixed и вызывать AdjusterFixed.UpdatePosition() после каждого перемещения объекта.

Настройте поведение, но только если необходимо

Опять же, этот подходит, будем надеяться, подойдет для всех частей World Locking Tools. WLT предоставляет простое, но чаще всего полезное базовое поведение. В большинстве случаев эта реализация:

  1. удовлетворит потребности вашего приложения;
  2. предоставит базовую реализацию для улучшения;
  3. подаст пример реализации, с которым можно экспериментировать.

См. также