Создание поставщика входных системных данных — 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.