Создание поставщика входных системных данных — MRTK2

Входная система Смешанная реальность Toolkit — это расширяемая система для поддержки устройств ввода. Чтобы добавить поддержку новой аппаратной платформы, может потребоваться настраиваемый поставщик входных данных.

В этой статье описывается создание настраиваемых поставщиков данных, также называемых диспетчерами устройств, для системы ввода. Пример кода, показанный здесь, из WindowsMixedRealityDeviceManager.

Полный код, используемый в этом примере, можно найти в папке MRTK/Providers/WindowsMixedReality.

Пространство имен и структура папок

Поставщики данных могут распространяться как сторонние надстройки или как часть набора средств Microsoft Смешанная реальность Toolkit. Процесс утверждения отправки новых поставщиков данных в MRTK будет зависеть от конкретного случая и будет сообщаться во время первоначального предложения.

Важно!

Если поставщик входных системных данных отправляется в репозиторий набора средств Смешанная реальность, пространство имен должно начинаться с Microsoft.MixedReality.Toolkit (например, Microsoft.MixedReality.Toolkit.WindowsMixedReality) и код должен находиться в папке под MRTK/Providers (например, MRTK/Providers/WindowsMixedReality).

Пространство имен

Поставщики данных должны иметь пространство имен для устранения потенциальных конфликтов имен. Рекомендуется, чтобы пространство имен включает следующие компоненты.

  • Название организации
  • Область применения компонента

Например, поставщик входных данных, созданный компанией Contoso, может быть Contoso.MixedReality.Toolkit.Input.

Рекомендуется разместить исходный код для поставщиков данных в иерархии папок, как показано на следующем рисунке.

Example folder structure

Если ContosoInput содержит реализацию поставщика данных, папка editor содержит инспектор (и любой другой код редактора Unity), папка Textures содержит изображения поддерживаемых контроллеров, а профили содержат один или несколько предварительно созданных профилей.

Примечание

Некоторые распространенные образы контроллеров можно найти в папке MixedRealityToolkit\StandardAssets\Textures.

Реализация поставщика данных

Указание наследования интерфейса и (или) базового класса

Все поставщики входных системных данных должны реализовать IMixedRealityInputDeviceManager интерфейс, который указывает минимальную функциональность, необходимую входной системе. Основа MRTK включает BaseInputDeviceManager класс, который предоставляет реализацию по умолчанию этой необходимой функциональности. Для устройств, которые основываются на UInput класса Unity, UnityJoystickManager класс можно использовать в качестве базового класса.

Примечание

Классы BaseInputDeviceManager и UnityJoystickManager классы обеспечивают необходимую IMixedRealityInputDeviceManager реализацию.

public class WindowsMixedRealityDeviceManager :
    BaseInputDeviceManager,
    IMixedRealityCapabilityCheck
{ }

IMixedRealityCapabilityCheck используется WindowsMixedRealityDeviceManager для указания того, что он обеспечивает поддержку набора возможностей ввода, в частности, сформулированных рук, жестов взгляда и голосовых рук и контроллеров движения.

Применение атрибута MixedRealityDataProvider

Ключевым шагом создания поставщика входных системных данных является применение атрибута MixedRealityDataProvider к классу. Этот шаг позволяет задать профиль и платформы по умолчанию для поставщика при выборе в профиле системы ввода.

[MixedRealityDataProvider(
    typeof(IMixedRealityInputSystem),
    SupportedPlatforms.WindowsUniversal,
    "Windows Mixed Reality Device Manager")]
public class WindowsMixedRealityDeviceManager :
    BaseInputDeviceManager,
    IMixedRealityCapabilityCheck
{ }

Реализация методов IMixedRealityDataProvider

После определения класса следующим шагом является предоставление реализации IMixedRealityDataProvider интерфейса.

Примечание

Класс BaseInputDeviceManager через BaseService класс предоставляет только пустые реализации для IMixedRealityDataProvider методов. Подробные сведения об этих методах обычно относятся к поставщику данных.

Ниже приведены методы, которые должны быть реализованы поставщиком данных.

  • Destroy()
  • Disable()
  • Enable()
  • Initialize()
  • Reset()
  • Update()

Реализация логики поставщика данных

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

Реализация классов контроллера

WindowsMixedRealityDeviceManager Пример определяет и реализует следующие классы контроллера.

Исходный код для каждого из этих классов можно найти в папке MRTK/Providers/WindowsMixedReality.

  • WindowsMixedRealityArticulatedHand.cs
  • WindowsMixedRealityController.cs
  • WindowsMixedRealityGGVHand.cs

Примечание

Не все диспетчеры устройств поддерживают несколько типов контроллеров.

Применение атрибута MixedRealityController

Затем примените MixedRealityController атрибут к классу. Этот атрибут задает тип контроллера (например, сформулированную руку), руку (например, слева или справа) и необязательный образ контроллера.

[MixedRealityController(
    SupportedControllerType.WindowsMixedReality,
    new[] { Handedness.Left, Handedness.Right },
    "StandardAssets/Textures/MotionController")]
{ }

Настройка сопоставлений взаимодействия

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

Следующий пример сокращен из GenericOpenVRController класса, расположенного в папке MRTK/Providers/OpenVR.

public override MixedRealityInteractionMapping[] DefaultLeftHandedInteractions => new[]
{
    // Controller Pose
    new MixedRealityInteractionMapping(0, "Spatial Pointer", AxisType.SixDof, DeviceInputType.SpatialPointer, MixedRealityInputAction.None),
    // Left Trigger Squeeze
    new MixedRealityInteractionMapping(1, "Trigger Position", AxisType.SingleAxis, DeviceInputType.Trigger, ControllerMappingLibrary.AXIS_9),
    // Left Trigger Press (Select)
    new MixedRealityInteractionMapping(2, "Trigger Press (Select)", AxisType.Digital, DeviceInputType.TriggerPress, KeyCode.JoystickButton14),
};

Примечание

Класс ControllerMappingLibrary предоставляет символьные константы для оси ввода Unity и определений кнопок.

Создание событий уведомлений

Чтобы разрешить приложениям реагировать на входные данные от пользователя, поставщик данных создает события уведомлений, соответствующие изменениям состояния контроллера, как определено в IMixedRealityInputHandler интерфейсах и IMixedRealityInputHandler<T> интерфейсах.

Для элементов управления цифровыми типами (button) вызовите события OnInputDown и OnInputUp.

// inputAction is the input event that is to be raised.
if (interactionSourceState.touchpadPressed)
{
    InputSystem?.RaiseOnInputDown(InputSource, ControllerHandedness, inputAction);
}
else
{
    InputSystem?.RaiseOnInputUp(InputSource, ControllerHandedness, inputAction);
}

Для аналоговых элементов управления (например, положение сенсорной панели) должно быть поднято событие InputChanged.

InputSystem?.RaisePositionInputChanged(InputSource, ControllerHandedness, interactionMapping.MixedRealityInputAction, interactionSourceState.touchpadPosition);

Добавление инструментирования Профилировщика Unity

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

Рекомендуется реализовать шаблон, используемый MRTK при инструментировании настраиваемых поставщиков.

        private static readonly ProfilerMarker GetOrAddControllerPerfMarker = new ProfilerMarker("[MRTK] WindowsMixedRealityDeviceManager.GetOrAddController");

        private async void GetOrAddController(InteractionSourceState interactionSourceState)
        {
            using (GetOrAddControllerPerfMarker.Auto())
            {
                // Code to be measured.
            }
        }

Примечание

Имя, используемое для идентификации маркера профилировщика, является произвольным. MRTK использует следующий шаблон.

"[product] className.methodName — необязательное примечание"

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

Создание профиля и инспектора

В наборе средств Смешанная реальность поставщики данных настраиваются с помощью профилей.

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

Полный код для примера в этом разделе можно найти в MRTK. Папка Services/InputSimulation.

Определение профиля

Содержимое профиля должно отражать доступные свойства наблюдателя (например, интервал обновления). Все настраиваемые пользователем свойства, определенные в каждом интерфейсе, должны содержаться в профиле.

[CreateAssetMenu(
    menuName = "Mixed Reality Toolkit/Profiles/Mixed Reality Simulated Input Profile",
    fileName = "MixedRealityInputSimulationProfile",
    order = (int)CreateProfileMenuItemIndices.InputSimulation)]
public class MixedRealityInputSimulationProfile : BaseMixedRealityProfile
{ }

Атрибут CreateAssetMenu можно применить к классу профиля, чтобы позволить клиентам создавать экземпляр профиля с помощью меню "Создание > ресурсов > Смешанная реальность наборов средств>".

Реализация инспектора

Инспекторы профилей — это пользовательский интерфейс для настройки и просмотра содержимого профиля. Каждый инспектор профилей должен расширить класс BaseMixedRealityToolkitConfigurationProfileInspector .

[CustomEditor(typeof(MixedRealityInputSimulationProfile))]
public class MixedRealityInputSimulationProfileInspector : BaseMixedRealityToolkitConfigurationProfileInspector
{ }

Атрибут CustomEditor сообщает Unity о типе ресурса, к которому применяется инспектор.

Создание определений сборок

Набор средств Смешанная реальность использует файлы определения сборки (ASMDEF) для указания зависимостей между компонентами, а также для упрощения Unity в сокращении времени компиляции.

Рекомендуется создавать файлы определения сборки для всех поставщиков данных и их компонентов редактора.

Используя структуру папок в предыдущем примере, для поставщика данных ContosoInput будет два ASMDEF-файла.

Первое определение сборки предназначено для поставщика данных. В этом примере он будет называться ContosoInput и будет расположен в папке ContosoInput примера. Это определение сборки должно указывать зависимость от Microsoft.MixedReality.Toolkit и любых других сборок, от которых она зависит.

Определение сборки ContosoInputEditor будет указывать инспектор профилей и любой конкретный код редактора. Этот файл должен находиться в корневой папке кода редактора. В этом примере файл будет расположен в папке ContosoInput\Editor. Это определение сборки будет содержать ссылку на сборку ContosoInput, а также:

  • Microsoft.MixedReality.Toolkit
  • Microsoft.MixedReality.Toolkit.Editor.Inspectors
  • Microsoft.MixedReality.Toolkit.Editor.Utilities

Регистрация поставщика данных

После создания поставщик данных можно зарегистрировать в системе ввода и использовать в приложении.

Registered input system data providers

Упаковка и распространение

Поставщики данных, распространяемые как сторонние компоненты, имеют конкретные сведения о упаковке и распределении, оставленные на предпочтение разработчика. Скорее всего, наиболее распространенным решением будет создание пакета unitypackage и распространение через хранилище активов Unity.

Если поставщик данных отправляется и принимается в составе пакета Microsoft Смешанная реальность Toolkit, команда Microsoft MRTK упаковает и распространяет его в рамках предложений MRTK.

См. также статью