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

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

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

Полный код, используемый в этом примере, можно найти в папке МРТК/providers/Виндовсмикседреалити.

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

поставщики данных могут распространяться как надстройки сторонних производителей или как часть набор средств Microsoft Mixed Reality. Процесс утверждения для отправки новых поставщиков данных в МРТК будет изменяться в зависимости от конкретного случая и будет передан на момент начального предложения.

Важно!

если поставщик входных системных данных отправляется в репозиторий смешанной реальности набор средств, пространство имен должно начинаться с Microsoft. микседреалити. набор средств (например: Microsoft. микседреалити. набор средств. Виндовсмикседреалити), и код должен находиться в папке под именем МРТК/providers (например, МРТК/providers/Виндовсмикседреалити).

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

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

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

Например, поставщик входных данных, созданный компанией Contoso, может иметь значение contoso. Микседреалити. набор средств. Входные данные ".

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

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

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

Примечание

Некоторые образы общих контроллеров можно найти в папке Микседреалититулкит\стандардассетс\текстурес

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

Укажите наследование интерфейса и/или базового класса

Все поставщики входных системных данных должны реализовывать IMixedRealityInputDeviceManager интерфейс, который указывает минимальную функциональность, необходимую для входной системы. МРТК Foundation включает класс, BaseInputDeviceManager который предоставляет реализацию по умолчанию для необходимых функциональных возможностей. Для устройств, построенных на основе класса Уинпут Unity, UnityJoystickManager класс можно использовать в качестве базового класса.

Примечание

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

public class WindowsMixedRealityDeviceManager :
    BaseInputDeviceManager,
    IMixedRealityCapabilityCheck
{ }

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

Применение атрибута Микседреалитидатапровидер

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

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

Реализация методов Имикседреалитидатапровидер

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

Примечание

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

Поставщик данных должен реализовать следующие методы:

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

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

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

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

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

Исходный код для каждого из этих классов можно найти в папке МРТК/providers/Виндовсмикседреалити.

  • Виндовсмикседреалитяртикулатедханд. CS
  • Виндовсмикседреалитиконтроллер. CS
  • Виндовсмикседреалитиггвханд. CS

Примечание

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

Применение атрибута Микседреалитиконтроллер

Затем примените MixedRealityController атрибут к классу. Этот атрибут указывает тип контроллера (например, с назначением руки), правой или левой (пример: Left или right) и необязательный образ контроллера.

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

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

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

Приведенный ниже пример является сокращенным из GenericOpenVRController класса, расположенного в папке мртк/providers/опенвр.

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> интерфейсах и.

Для элементов управления типа Digital (Button) создайте события Онинпутдовн и Онинпутуп.

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

Полный код для примера в этом разделе можно найти в МРТК. Папка Services/Инпутсимулатион.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Microsoft. Микседреалити. набор средств
  • Microsoft. Микседреалити. набор средств. Редактор. Инспекторы
  • Microsoft. Микседреалити. набор средств. Редактор. Utilities

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

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

Зарегистрированные поставщики входных системных данных

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

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

если поставщик данных отправлен и принят как часть пакета microsoft Mixed Reality набор средств, группа microsoft мртк будет упаковывать и распространять ее в рамках предложений мртк.

См. также раздел