Создание поставщика входных системных данных — MRTK2
Система ввода Смешанная реальность Toolkit — это расширяемая система для включения поддержки устройств ввода. Чтобы добавить поддержку новой аппаратной платформы, может потребоваться пользовательский поставщик входных данных.
В этой статье описывается создание настраиваемых поставщиков данных, также называемых диспетчерами устройств, для системы ввода. Пример кода, показанный здесь, из WindowsMixedRealityDeviceManager.
Полный код, используемый в этом примере, можно найти в папке MRTK/Providers/WindowsMixedReality.
Структура пространства имен и папок
Поставщики данных могут распространяться как надстройка стороннего производителя или как часть Microsoft Смешанная реальность Toolkit. Процесс утверждения для передачи новых поставщиков данных в MRTK будет отличаться в зависимости от конкретного случая и будет сообщаться во время первоначального предложения.
Важно!
Если поставщик входных системных данных отправляется в репозиторий Смешанная реальность Toolkit, пространство имен должно начинаться с Microsoft.MixedReality.Toolkit (например, Microsoft.MixedReality.Toolkit.WindowsMixedReality), а код должен находиться в папке под MRTK/Providers (например, MRTK/Providers/WindowsMixedReality).
Пространство имен
Поставщики данных должны иметь пространство имен для устранения потенциальных конфликтов имен. Рекомендуется, чтобы пространство имен было включено в следующие компоненты.
- Название организации
- Область применения компонента
Например, поставщик входных данных, созданный компанией Contoso, может быть "Contoso.MixedReality.Toolkit.Input".
Рекомендуемая структура папок
Рекомендуется разместить исходный код для поставщиков данных в иерархии папок, как показано на следующем рисунке.
Если ContosoInput содержит реализацию поставщика данных, папка Editor содержит инспектор (и любой другой код для редактора Unity), папка Textures содержит изображения поддерживаемых контроллеров, а папка Profiles — один или несколько готовых профилей.
Примечание
Некоторые распространенные образы контроллеров можно найти в папке 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> .
Для элементов управления цифровым типом (кнопка) вызовите события 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 Profiler
Производительность критически важна в приложениях смешанной реальности. Каждый компонент добавляет некоторые издержки, которые приложения должны учитывать. Для этого важно, чтобы все поставщики входных данных содержали инструментирование Unity Profiler во внутреннем цикле и часто используемых путях кода.
Рекомендуется реализовать шаблон, используемый 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 - необязательное примечание"
Рекомендуется, чтобы поставщики пользовательских данных следовали аналогичному шаблону, чтобы упростить идентификацию конкретных компонентов и методов при анализе трассировок.
Создание профиля и инспектора
В Смешанная реальность Toolkit поставщики данных настраиваются с помощью профилей.
Поставщики данных с дополнительными параметрами конфигурации (например, 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 о типе ресурса, к которому применяется инспектор.
Создание определений сборок
Смешанная реальность Toolkit использует файлы определения сборки (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
Регистрация поставщика данных
После создания поставщика данных можно зарегистрировать в системе ввода и использовать в приложении.
Упаковка и распространение
Поставщики данных, распространяемые как сторонние компоненты, имеют конкретные сведения об упаковке и распространении, оставленные на выбор разработчика. Скорее всего, наиболее распространенным решением будет создание пакета unitypackage и распространение через хранилище активов Unity.
Если поставщик данных отправляется и принимается как часть пакета Microsoft Смешанная реальность Toolkit, команда Microsoft MRTK упаковает и распространяет его в рамках предложений MRTK.