Guia de configuração do perfil MRTK2
Mixed Reality Toolkit centraliza a maior parte da configuração necessária para gerir o toolkit possível (exceto para verdadeiro runtime "coisas").
Este guia é uma instruções simples para cada um dos ecrãs de perfil de configuração atualmente disponíveis para o toolkit.
O perfil de configuração principal Mixed Reality Toolkit
O perfil de configuração principal, anexado ao MixedRealityToolkit GameObject na sua Cena, fornece o ponto de entrada principal para o Toolkit no seu projeto.
Nota
Mixed Reality Toolkit "bloqueia" os ecrãs de configuração predefinidos para garantir que tem sempre um ponto de partida comum para o seu projeto e é incentivado a começar a definir as suas próprias definições à medida que o seu projeto evolui. A configuração do MRTK não é editável durante o modo de reprodução.
Todos os perfis "predefinidos" do Mixed Reality Toolkit podem ser encontrados no projeto SDK na pasta Assets/MRTK/SDK/Profiles.
Importante
DefaultHoloLens2ConfigurationProfile está otimizado para HoloLens 2. Veja Perfis para obter os detalhes.
Quando abrir a Mixed Reality Perfil de Configuração do Toolkit principal, verá o seguinte ecrã no inspetor:
Se selecionar um recurso MixedRealityToolkitConfigurationProfile sem o MixedRealityToolkit na cena, perguntar-lhe-á se pretende que o MRTK configure automaticamente a cena. Isto é opcional; No entanto, tem de existir um objeto MixedRealityToolkit ativo na cena para aceder a todos os ecrãs de configuração.
Esta ação aloja a configuração do runtime ativo atual para o projeto.
A partir daqui, pode navegar para todos os perfis de configuração do MRTK, incluindo:
- O perfil de configuração principal Mixed Reality Toolkit
- Definições de experiência
- Definições da câmara
- Definições do sistema de entrada
- Definições de visualização de limites
- Seleção do sistema de teletransporte
- Definições de deteção espacial
- Definições de diagnóstico
- Definições do sistema de cenários
- Definições de serviços adicionais
- Definições de ações de entrada
- Regras de ações de entrada
- Configuração do ponteiro
- Configuração de gestos
- Comandos de voz
- Configuração do mapeamento do controlador
- Definições de visualização do controlador
- Utilitários do Editor
- Alterar perfis no runtime
- Ver também
Estes perfis de configuração são detalhados abaixo nas secções relevantes:
Definições de experiência
Localizada na página de configuração principal Mixed Reality Toolkit, esta definição define a operação predefinida da escala de ambiente Mixed Reality para o projeto.
Definições da câmara
As definições da câmara definem como a câmara será configurada para o seu projeto de Mixed Reality, definindo as definições genéricas de recorte, qualidade e transparência.
Definições do sistema de entrada
O Mixed Reality Project fornece um sistema de entrada robusto e bem preparado para encaminhar todos os eventos de entrada em torno do projeto que está selecionado por predefinição.
Por trás do Sistema de Entrada fornecido pelo MRTK estão vários outros sistemas, estes ajudam a impulsionar e gerir as complexas inter-tecelagem necessárias para abstrair as complexidades de uma arquitetura de realidade mista/multiplataformas.
Cada um dos perfis individuais está detalhado abaixo:
- Definições de Foco
- Definições de ações de entrada
- Regras de ações de entrada
- Configuração do ponteiro
- Configuração de gestos
- Comandos de voz
- Configuração do mapeamento do controlador
- Definições de visualização do controlador
Definições de visualização de limites
O sistema de limites traduz o limite percebido comunicado pelo sistema guardião/limite das plataformas subjacentes. A configuração do Visualizador de limites permite-lhe mostrar automaticamente o limite registado na cena em relação à posição do utilizador. O limite também reagirá/atualizará com base no local onde o utilizador teletransporta dentro do cenário.
Seleção do sistema de teletransporte
O Mixed Reality Project fornece um sistema de Teletransporte completo para gerir eventos de teletransporte no projeto que está selecionado por predefinição.
Definições de deteção espacial
O Mixed Reality Project fornece um sistema de sensibilização espacial reconstruído para trabalhar com sistemas de análise espacial no projeto que está selecionado por predefinição.
Mixed Reality configuração de deteção espacial do Toolkit permite-lhe personalizar a forma como o sistema é iniciado, quer seja automaticamente quando a aplicação é iniciada ou posterior programaticamente, bem como definir as extensões do campo de vista.
Também lhe permite configurar as definições de malha e superfície, personalizando ainda mais a forma como o projeto compreende o ambiente à sua volta.
Isto só é aplicável a dispositivos que possam fornecer um ambiente analisado.
Definições de diagnóstico
Uma funcionalidade opcional, mas altamente útil do MRTK, é a funcionalidade de diagnóstico do plug-in.
O perfil de diagnóstico fornece vários sistemas simples para monitorizar enquanto o projeto está em execução, incluindo um botão ativado/desligado útil para ativar/desativar o painel de apresentação no cenário.
Definições do sistema de cenários
O MRTK fornece este serviço opcional para o ajudar a gerir o carregamento/descarregamento de cenários de adição complexos. Para decidir se o Sistema de Cenários seria uma boa opção para o seu projeto, leia o Guia de Introdução do Sistema de Cenas.
Definições de serviços adicionais
Uma das áreas mais avançadas do Mixed Reality Toolkit é a implementação do padrão do localizador de serviços que permite o registo de qualquer "Serviço" com a arquitetura. Isto permite que a arquitetura seja expandida com novas funcionalidades/sistemas facilmente, mas também permite que os projetos tirem partido destas capacidades para registar os seus próprios componentes de runtime.
Qualquer serviço registado ainda obtém a vantagem total de todos os eventos do Unity, sem a sobrecarga e o custo de implementar padrões MonoBehaviour ou singleton desajeitados. Isto permite componentes C# puros sem sobrecarga de cena para executar processos em primeiro plano e em segundo plano, por exemplo, sistemas de desova, lógica de jogo de runtime ou praticamente qualquer outra coisa.
Definições de ações de entrada
As ações de entrada fornecem uma forma de abstrair quaisquer interações físicas e entradas de um projeto de runtime. Todas as entradas físicas (de controladores/mãos/rato/etc.) são traduzidas para uma ação de entrada lógica para utilização no seu projeto de runtime. Isto garante que, independentemente da origem da entrada, o seu projeto implementa simplesmente estas ações como "Coisas a fazer" ou "Interagir" nos seus cenários.
Para criar uma nova ação de entrada, basta clicar no botão "Adicionar uma nova Ação" e introduzir um nome de texto amigável para o que representa. Em seguida, só precisa de selecionar um eixo (o tipo de dados) que a ação se destina a transmitir ou, no caso dos controladores físicos, o tipo de entrada física ao qual pode ser anexada, por exemplo:
| Restrição do Eixo | Tipo de Dados | Descrição | Utilização de exemplo |
|---|---|---|---|
| Nenhuma | Sem dados | Utilizado para uma ação ou evento vazio | Acionador de Eventos |
| Não processado (reservado) | objeto | Reservado para utilização futura | N/D |
| Digital | bool | Um valor booleano sobre ou desativar dados do tipo | Um botão de controlador |
| Eixo Único | float | Um único valor de dados de precisão | Uma entrada num intervalo, por exemplo, um acionador |
| Eixo Duplo | Vetor2 | Uma data de tipo de bóia dupla para vários eixos | Um Dpad ou Thumbstick |
| Posição De Três Dof | Vetor3 | Dados de tipo posicional de com 3 eixos flutuantes | Controlador apenas de estilo de posição 3D |
| Rotação de Três Dof | Quaternion | Entrada rotativa apenas com 4 eixos flutuantes | Um controlador de estilo três graus, por exemplo, controlador Oculus Go |
| Seis Dof | Mixed Reality Pose (Vector3, Quaternion) | Uma entrada de estilo de posição e rotação com componentes Vector3 e Quaternion | Um controlador de movimento ou Ponteiro |
Os eventos que utilizam ações de entrada não se limitam a controladores físicos e ainda podem ser utilizados no projeto para que os efeitos de runtime gerem novas ações.
Nota
As ações de entrada são um dos poucos componentes que não são editáveis no runtime, são apenas uma configuração de tempo de design. Este perfil não deve ser trocado enquanto o projeto estiver em execução devido à dependência da arquitetura (e dos seus projetos) no ID gerado para cada ação.
Regras de ações de entrada
As regras de ação de entrada fornecem uma forma de traduzir automaticamente um evento gerado para uma ação de entrada em diferentes ações com base no respetivo valor de dados. Estes são geridos de forma totalmente integrada na arquitetura e não incorrem em custos de desempenho.
Por exemplo, converter o evento de entrada de eixo duplo único de um DPad em para as 4 ações correspondentes "Dpad Up" /"DPad Down" / "Dpad Left" /"Dpad Right" (conforme mostrado na imagem abaixo).
Isto também pode ser feito no seu próprio código. No entanto, visto que este era um padrão muito comum, a arquitetura fornece um mecanismo para o fazer "fora da caixa"
As Regras de ação de entrada podem ser configuradas para qualquer um dos eixos de entrada disponíveis. No entanto, as ações de entrada de um tipo de eixo podem ser traduzidas para outra ação de entrada do mesmo tipo de eixo. Pode mapear uma ação de eixo duplo para outra ação de eixo duplo, mas não para uma ação digital ou nenhuma.
Configuração do ponteiro
Os ponteiros são utilizados para impulsionar a interatividade na cena a partir de qualquer dispositivo de entrada, dando uma direção e um teste de impacto com qualquer objeto numa cena (que tenha um colisor ligado ou seja um componente de IU). Por predefinição, os ponteiros são configurados automaticamente para controladores, auscultadores (olhar/foco) e entrada de rato/toque.
Os ponteiros também podem ser visualizados na cena ativa com um dos muitos componentes de linha fornecidos pelo Mixed Reality Toolkit ou qualquer um dos seus se implementarem a interface IMixedRealityPointer do MRTK.
- Extensão apontadora: determina a extensão de apontamento global para todos os ponteiros, incluindo o olhar.
- Máscaras de Camada raycast a apontar: determina em que camadas os ponteiros serão colocados em raycast.
- Depurar Draw Pointing Rays: um auxiliar de depuração para visualizar os raios utilizados para raycasting.
- Depurar Cores de Raios Apontados de Desenho: um conjunto de cores a utilizar para visualização.
- Prefab do cursor de olhar: facilita a especificação de um cursor de olhar global para qualquer cena.
Existe um botão auxiliar adicional para ir rapidamente para o Fornecedor de Gaze para substituir alguns valores específicos do Gaze, se necessário.
Configuração de gestos
Os gestos são uma implementação específica do sistema que lhe permite atribuir ações de entrada aos vários métodos de entrada "Gesto" fornecidos por vários SDKs (por exemplo, HoloLens).
Nota
A implementação de Gestos atual destina-se apenas ao HoloLens e será melhorada para outros sistemas, uma vez que são adicionados ao Toolkit no futuro (ainda não existem datas).
Comandos de voz
Tal como os gestos, algumas plataformas de runtime também fornecem funcionalidades inteligentes de "Conversão de Voz em Texto" com a capacidade de gerar comandos que podem ser recebidos por um projeto do Unity. Este perfil de configuração permite-lhe configurar o seguinte:
- Definições Gerais – "Comportamento de Início" definido como Início Automático ou Início Manual determina se deve inicializar KeywordRecognizer no arranque do sistema de entrada ou permitir que o projeto decida quando inicializar o KeywordRecognizer. O "Nível de Confiança de Reconhecimento" é utilizado para inicializar a API KeywordRecognizer do Unity
- Comandos de Voz – regista "palavras" e traduz-as em ações de entrada que podem ser recebidas pelo seu projeto. Também podem ser anexadas a ações de teclado, se necessário.
Importante
Atualmente, o sistema só suporta voz ao ser executado em plataformas Windows 10, por exemplo, HoloLens e Windows 10 ambiente de trabalho e será melhorado para outros sistemas, uma vez que são adicionados ao MRTK no futuro (ainda não existem datas).
Configuração de mapeamento do controlador
Um dos principais ecrãs de configuração do Mixed Reality Toolkit é a capacidade de configurar e mapear os vários tipos de controladores que podem ser utilizados pelo seu projeto.
O ecrã de configuração abaixo permite-lhe configurar qualquer um dos controladores atualmente reconhecidos pelo toolkit.
O MRTK fornece uma configuração predefinida para os seguintes controladores/sistemas:
- Rato (incluindo suporte de rato espacial 3D)
- Telemóveis com
- Comandos Xbox
- controladores de Windows Mixed Reality
- Gestos do HoloLens
- Controladores de varinha HTC Vive
- Controladores Oculus Touch
- Controlador Oculus Remote
- Dispositivos OpenVR genéricos (apenas utilizadores avançados)
Clicar na Imagem de qualquer um dos sistemas de controlador pré-criados permite-lhe configurar uma única ação de entrada para todas as entradas correspondentes, por exemplo, veja o ecrã de configuração do controlador Oculus Touch abaixo:
Também existe um ecrã avançado para configurar outros controladores de entrada OpenVR ou Unity que não estão identificados acima.
Definições de visualização do controlador
Além do mapeamento do controlador, é fornecido um perfil de configuração separado para personalizar a forma como os controladores são apresentados nos seus cenários.
Isto pode ser configurado num "Global" (todas as instâncias de um controlador para uma mão específica) ou específico para um tipo/mão de controlador individual.
O MRTK também suporta modelos de controlador SDK nativos para Windows Mixed Reality e OpenVR. Estes são carregados como GameObjects na sua cena e posicionados com o controlo do controlador da plataforma.
Se a representação do controlador na cena precisar de ser compensada da posição do controlador físico, basta definir esse desvio em relação à pré-base do modelo do controlador (por exemplo, definir a posição de transformação da pré-base do controlador com uma posição de deslocamento).
Utilitários do Editor
Os seguintes utilitários só funcionam no editor e são úteis para melhorar a produtividade do desenvolvimento.
Inspetores de serviços
Os Inspetores de Serviços são uma funcionalidade apenas de editor que gera objetos no local que representam serviços ativos. A seleção destes objetos apresenta inspetores que oferecem ligações de documentação, controlo sobre visualizações do editor e informações sobre o estado do serviço.
Pode ativar os inspetores de serviços ao verificar Utilizar Inspetores de Serviço emDefinições do Editor no Perfil de Configuração.
Compositor de memória intermédia de profundidade
Partilhar a memória intermédia de profundidade com algumas plataformas de realidade mista pode melhorar a estabilização do holograma. Por exemplo, a plataforma Windows Mixed Reality pode modificar a cena composta por pixel para ter em conta os movimentos subtis da cabeça durante o tempo que demorou a compor uma moldura. No entanto, estas técnicas requerem memórias intermédias de profundidade com dados precisos para saber onde e até onde está a geometria do utilizador.
Para garantir que uma cena compõe todos os dados necessários para a memória intermédia de profundidade, os programadores podem alternar a funcionalidade Memória Intermédia de Profundidade de Composição em Definições do Editor no Perfil de Configuração. Esta ação irá colocar a memória intermédia de profundidade atual e torná-la como cor na vista de cena ao aplicar um efeito pós-processamento, DepthBufferRenderer, à câmara principal.
O cilindro azul no local tem um material com ZWrite desativado para que não sejam escritos dados de profundidade
Alterar perfis no runtime
É possível atualizar perfis no runtime e, geralmente, existem dois cenários e horas diferentes nos quais isto é útil:
- Comutador de perfil de inicialização pré-MRTK: no arranque, antes de o MRTK ser inicializado e o perfil ficar ativo, substitua o perfil ainda não em utilização para ativar/desativar diferentes funcionalidades com base nas capacidades do dispositivo. Por exemplo, se a experiência estiver em execução em VR que não tenha hardware de mapeamento espacial, provavelmente não faz sentido ter o componente de mapeamento espacial ativado.
- Comutador de perfil ativo: após o arranque, após o MRTK ser inicializado e um perfil ficar ativo, trocando o perfil atualmente em utilização para alterar o comportamento de determinadas funcionalidades. Por exemplo, pode haver uma sub-experiência específica na aplicação que quer ponteiros de mãos distantes completamente removidos.
Comutador de perfil de inicialização pré-MRTK
Isto pode ser conseguido ao anexar um MonoBehaviour (exemplo abaixo) que é executado antes da inicialização do MRTK (ou seja, Acordado()). Tenha em atenção que o script (ou seja, chamar para SetProfileBeforeInitialization) tem de ser executado mais cedo do que o script, o MixedRealityToolkit que pode ser alcançado ao definir as definições da Ordem de Execução do Script.
using Microsoft.MixedReality.Toolkit;
using UnityEngine;
/// <summary>
/// Sample MonoBehaviour that will run before the MixedRealityToolkit object, and change
/// the profile, so that when MRTK initializes it uses the profile specified below
/// rather than the one that is saved in its scene.
/// </summary>
/// <remarks>
/// Note that this script must have a higher priority in the script execution order compared
/// to that of MixedRealityToolkit.cs. See https://docs.unity3d.com/Manual/class-MonoManager.html
/// for more information on script execution order.
/// </remarks>
public class PreInitProfileSwapper : MonoBehaviour
{
[SerializeField]
private MixedRealityToolkitConfigurationProfile profileToUse = null;
private void Awake()
{
// Here you could choose any arbitrary MixedRealityToolkitConfigurationProfile (for example, you could
// add some platform checking code here to determine which profile to load).
MixedRealityToolkit.SetProfileBeforeInitialization(profileToUse);
}
}
Em vez de "profileToUse", é possível ter um conjunto arbitrário de perfis que se aplicam a plataformas específicas (por exemplo, um para HoloLens 1, um para VR, um para HoloLens 2, etc. É possível utilizar vários outros indicadores (por exemplo https://docs.unity3d.com/ScriptReference/SystemInfo.html, , ou se a câmara é ou não opaca/transparente), para descobrir qual o perfil a carregar.
Comutador de perfil ativo
Isto pode ser feito ao definir a MixedRealityToolkit.Instance.ActiveProfile propriedade para um novo perfil, substituindo o perfil ativo.
MixedRealityToolkit.Instance.ActiveProfile = profileToUse;
Tenha em atenção que, ao definir ActiveProfile durante o runtime, a destruição dos serviços atualmente em execução ocorrerá após o último LateUpdate() de todos os serviços e a instanciação e inicialização dos serviços associados ao novo perfil ocorrerá antes da primeira Atualização() de todos os serviços.
Pode ocorrer uma hesitação de aplicação percetível durante este processo. Também qualquer script com maior prioridade do que o script pode introduzir a MixedRealityToolkit respetiva Atualização antes de o novo perfil ser configurado corretamente. Veja Definições da Ordem de Execução de Scripts para obter mais informações sobre a prioridade do script.
No processo de mudança de perfil, a câmara de IU existente permanecerá inalterada, garantindo que os componentes da IU do Unity que necessitam de tela continuam a funcionar após a mudança.