Criar um fornecedor de dados do sistema de entrada – MRTK2
O sistema de entrada Mixed Reality Toolkit é um sistema extensível para ativar o suporte de dispositivos de entrada. Para adicionar suporte para uma nova plataforma de hardware, poderá ser necessário um fornecedor de dados de entrada personalizado.
Este artigo descreve como criar fornecedores de dados personalizados, também denominados gestores de dispositivos, para o sistema de entrada. O código de exemplo mostrado aqui é de WindowsMixedRealityDeviceManager.
O código completo utilizado neste exemplo pode ser encontrado na pasta MRTK/Providers/WindowsMixedReality.
Espaço de nomes e estrutura de pastas
Os fornecedores de dados podem ser distribuídos como um suplemento de terceiros ou como parte do Microsoft Mixed Reality Toolkit. O processo de aprovação da submissão de novos fornecedores de dados ao MRTK irá variar caso a caso e será comunicado no momento da proposta inicial.
Importante
Se um fornecedor de dados do sistema de entrada estiver a ser submetido para o repositório Mixed Reality Toolkit, o espaço de nomes tem de começar por Microsoft.MixedReality.Toolkit (por exemplo: Microsoft.MixedReality.Toolkit.WindowsMixedReality) e o código deve estar localizado numa pasta abaixo de MRTK/Providers (por exemplo: MRTK/Providers/WindowsMixedReality).
Espaço de Nomes
Os fornecedores de dados têm de ter um espaço de nomes para mitigar potenciais colisões de nomes. Recomenda-se que o espaço de nomes inclua os seguintes componentes.
- Nome da empresa
- Área de funcionalidades
Por exemplo, um fornecedor de dados de entrada criado pela empresa Contoso pode ser "Contoso.MixedReality.Toolkit.Input".
Estrutura de pastas recomendada
Recomenda-se que o código fonte dos fornecedores de dados seja distribuído numa hierarquia de pastas, conforme mostrado na imagem seguinte.
Quando ContosoInput contém a implementação do fornecedor de dados, a pasta Editor contém o inspetor (e qualquer outro código específico do editor do Unity), a pasta Texturas contém imagens dos controladores suportados e os Perfis contêm um ou mais perfis pré-criados.
Nota
Algumas imagens comuns do controlador podem ser encontradas na pasta MixedRealityToolkit\StandardAssets\Textures.
Implementar o fornecedor de dados
Especificar a herança da interface e/ou da classe base
Todos os fornecedores de dados do sistema de entrada têm de implementar a IMixedRealityInputDeviceManager interface, que especifica a funcionalidade mínima exigida pelo sistema de entrada. A base do MRTK inclui a BaseInputDeviceManager classe que fornece uma implementação predefinida desta funcionalidade necessária. Para dispositivos que se baseiam na classe UInput do Unity, a UnityJoystickManager classe pode ser utilizada como uma classe base.
Nota
As BaseInputDeviceManager classes e UnityJoystickManager fornecem a implementação necessária IMixedRealityInputDeviceManager .
public class WindowsMixedRealityDeviceManager :
BaseInputDeviceManager,
IMixedRealityCapabilityCheck
{ }
IMixedRealityCapabilityChecké utilizado peloWindowsMixedRealityDeviceManagerpara indicar que fornece suporte para um conjunto de capacidades de entrada, especificamente; mãos articuladas, mãos de voz de gesto de olhar e comandos de movimento.
Aplicar o atributo MixedRealityDataProvider
Um passo fundamental para criar um fornecedor de dados do sistema de entrada é aplicar o MixedRealityDataProvider atributo à classe . Este passo permite definir o perfil e as plataformas predefinidos para o fornecedor, quando selecionados no perfil do sistema de entrada.
[MixedRealityDataProvider(
typeof(IMixedRealityInputSystem),
SupportedPlatforms.WindowsUniversal,
"Windows Mixed Reality Device Manager")]
public class WindowsMixedRealityDeviceManager :
BaseInputDeviceManager,
IMixedRealityCapabilityCheck
{ }
Implementar os métodos IMixedRealityDataProvider
Assim que a classe tiver sido definida, o passo seguinte é fornecer a implementação da IMixedRealityDataProvider interface.
Nota
A BaseInputDeviceManager classe, através da BaseService classe , fornece apenas implementações vazias para IMixedRealityDataProvider métodos. Geralmente, os detalhes destes métodos são específicos do fornecedor de dados.
Os métodos que devem ser implementados pelo fornecedor de dados são:
Destroy()Disable()Enable()Initialize()Reset()Update()
Implementar a lógica do fornecedor de dados
O próximo passo é adicionar a lógica para gerir os dispositivos de entrada, incluindo quaisquer controladores a serem suportados.
Implementar as classes de controlador
O exemplo do WindowsMixedRealityDeviceManager define e implementa as seguintes classes de controlador.
O código fonte para cada uma destas classes pode ser encontrado na pasta MRTK/Providers/WindowsMixedReality.
- WindowsMixedRealityArticulatedHand.cs
- WindowsMixedRealityController.cs
- WindowsMixedRealityGGVHand.cs
Nota
Nem todos os gestores de dispositivos suportarão vários tipos de controlador.
Aplicar o atributo MixedRealityController
Em seguida, aplique o MixedRealityController atributo à classe . Este atributo especifica o tipo de controlador (por exemplo: mão articulada), a mão (por exemplo: esquerda ou direita) e uma imagem de controlador opcional.
[MixedRealityController(
SupportedControllerType.WindowsMixedReality,
new[] { Handedness.Left, Handedness.Right },
"StandardAssets/Textures/MotionController")]
{ }
Configurar os mapeamentos de interação
O próximo passo é definir o conjunto de mapeamentos de interação suportados pelo controlador. Para os dispositivos que recebem os respetivos dados através da classe Input do Unity, a ferramenta de mapeamento do controlador é um recurso útil para confirmar os mapeamentos de eixos e botões corretos a atribuir a interações.
O exemplo seguinte é abreviado da GenericOpenVRController classe , localizada na pasta 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),
};
Nota
A ControllerMappingLibrary classe fornece constantes simbólicas para o eixo de entrada do Unity e definições de botões.
Gerar eventos de notificação
Para permitir que as aplicações respondam à entrada do utilizador, o fornecedor de dados gera eventos de notificação correspondentes às alterações de estado do controlador, conforme definido nas IMixedRealityInputHandler interfaces e IMixedRealityInputHandler<T> .
Para controlos digitais (botão), crie os eventos OnInputDown e 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);
}
Para controlos analógicos (por exemplo, posição do touchpad), o evento InputChanged deve ser gerado.
InputSystem?.RaisePositionInputChanged(InputSource, ControllerHandedness, interactionMapping.MixedRealityInputAction, interactionSourceState.touchpadPosition);
Adicionar instrumentação do Unity Profiler
O desempenho é fundamental nas aplicações de realidade mista. Cada componente adiciona alguma quantidade de sobrecarga para as aplicações que têm de ter em conta. Para tal, é importante que todos os fornecedores de dados de entrada contenham instrumentação do Unity Profiler no ciclo interno e caminhos de código frequentemente utilizados.
Recomenda-se implementar o padrão utilizado pelo MRTK ao instrumentar fornecedores personalizados.
private static readonly ProfilerMarker GetOrAddControllerPerfMarker = new ProfilerMarker("[MRTK] WindowsMixedRealityDeviceManager.GetOrAddController");
private async void GetOrAddController(InteractionSourceState interactionSourceState)
{
using (GetOrAddControllerPerfMarker.Auto())
{
// Code to be measured.
}
}
Nota
O nome utilizado para identificar o marcador do gerador de perfis é arbitrário. O MRTK utiliza o seguinte padrão.
"[product] className.methodName - nota opcional"
Recomenda-se que os fornecedores de dados personalizados sigam um padrão semelhante para ajudar a simplificar a identificação de componentes e métodos específicos ao analisar rastreios.
Criar o perfil e o inspetor
No Mixed Reality Toolkit, os fornecedores de dados são configurados com perfis.
Os fornecedores de dados com opções de configuração adicionais (por exemplo, InputSimulationService) devem criar um perfil e um inspetor para permitir que os clientes modifiquem o comportamento de acordo com as necessidades da aplicação.
O código completo do exemplo nesta secção pode ser encontrado no MRTK. Pasta Serviços/InputSimulation.
Definir o perfil
Os conteúdos do perfil devem espelhar as propriedades acessíveis do observador (por exemplo, intervalo de atualização). Todas as propriedades configuráveis do utilizador definidas em cada interface devem estar contidas no perfil.
[CreateAssetMenu(
menuName = "Mixed Reality Toolkit/Profiles/Mixed Reality Simulated Input Profile",
fileName = "MixedRealityInputSimulationProfile",
order = (int)CreateProfileMenuItemIndices.InputSimulation)]
public class MixedRealityInputSimulationProfile : BaseMixedRealityProfile
{ }
O CreateAssetMenu atributo pode ser aplicado à classe de perfil para permitir que os clientes criem uma instância de perfil com o menu Criar > Recursos > Mixed Reality Perfis do Toolkit>.
Implementar o inspetor
Os inspetores de perfis são a interface de utilizador para configurar e visualizar conteúdos de perfil. Cada inspetor de perfis deve expandir a classe "BaseMixedRealityToolkitConfigurationProfileInspector .
[CustomEditor(typeof(MixedRealityInputSimulationProfile))]
public class MixedRealityInputSimulationProfileInspector : BaseMixedRealityToolkitConfigurationProfileInspector
{ }
O CustomEditor atributo informa o Unity do tipo de recurso ao qual o inspetor se aplica.
Criar definições de assemblagem
Mixed Reality Toolkit utiliza ficheiros de definição de assemblagem (.asmdef) para especificar dependências entre componentes, bem como para ajudar o Unity a reduzir o tempo de compilação.
Recomenda-se que os ficheiros de definição de assemblagem sejam criados para todos os fornecedores de dados e os respetivos componentes de editor.
Ao utilizar a estrutura de pastas no exemplo anterior, haveria dois ficheiros .asmdef para o fornecedor de dados ContosoInput.
A primeira definição de assemblagem é para o fornecedor de dados. Para este exemplo, será denominado ContosoInput e estará localizado na pasta ContosoInput do exemplo. Esta definição de assemblagem tem de especificar uma dependência em Microsoft.MixedReality.Toolkit e em quaisquer outras assemblagens de que dependa.
A definição de assemblagem ContosoInputEditor especificará o inspetor de perfis e qualquer código específico do editor. Este ficheiro tem de estar localizado na pasta raiz do código do editor. Neste exemplo, o ficheiro estará localizado na pasta ContosoInput\Editor. Esta definição de assemblagem irá conter uma referência à assemblagem ContosoInput, bem como:
- Microsoft.MixedReality.Toolkit
- Microsoft.MixedReality.Toolkit.Editor.Inspectors
- Microsoft.MixedReality.Toolkit.Editor.Utilities
Registar o fornecedor de dados
Depois de criado, o fornecedor de dados pode ser registado no sistema de entrada e ser utilizado na aplicação.
Empacotamento e distribuição
Os fornecedores de dados distribuídos como componentes de terceiros têm os detalhes específicos de empacotamento e distribuição deixados à preferência do programador. Provavelmente, a solução mais comum será gerar um .unitypackage e distribuir através do Unity Asset Store.
Se um fornecedor de dados for submetido e aceite como parte do pacote Microsoft Mixed Reality Toolkit, a equipa do Microsoft MRTK irá empacotá-lo e distribuí-lo como parte das ofertas do MRTK.