Join Waitlist We will inform you when the product arrives in stock. Just leave your valid email address below.
Email Quantity We won't share your address with anybody else.

Como configurar tudo para criação de um jogo de GearVR com UnrealEngine 4

 Introdução

Nesse tutorial ensinamos passo-a-passo tudo que precisa ser feito para que se possa começar a criar jogos para GearVR usando UE4 (atualmente na versão 4.15.1, mas geralmente o processo não se altera muito) em um PC. Ao final, teremos um projeto vazio que pode ser empacotado com sucesso sobre o qual você pode desenvolver seu jogo.

Requisitos

Hardware         

  1. Celular Samsung compatível com GearVR (Galaxy S7, S7 edge, S6 edge+, S6, S6 edge ou Note5)
  2. Samsung Gear VR.

Software

  1. Unreal Engine 4
  2. Samsung drivers

Instalação

Windows

Nvidia CodeWorks for Android

Navegue até a pasta [UE4.15]\Engine\Extras\AndroidWorks\Win64 e execute o arquivo CodeWorksforAndroid-1R5-windows.exe

Vá pressionando Next (deixe todas as opções como sugere o padrão mesmo) até chegar na lista do que está sendo instalado. Confirme que está instalando o CodeWorks for Android 1R5, não altere nenhum parâmetro da instalação, e então pressione Next

(A documentação original da Unreal exige que seja instalado o 1R4u2, mas está desatualizada e, para a UE4.15, essa versão 1R4u2 não funciona direito)

Clique na seleção Accept All para aceitar os termos da licença de uso e, em seguida, no botão Accept

Será exibida uma nova janela com o progresso da instalação. Aguarde. Essa etapa exige conexão com a internet e pode demorar um pouco. Quando todas as ferramentas necessárias tiverem sido baixadas e instaladas, a seguinte janela será exibida. Pressione Next para continuar

E, finalmente, pressione Finish para concluir a instalação e reinicie seu computador

Android

Habilite o modo desenvolvedor no Android

Vá a Configurações -> Sobre o dispositivo -> Info. software e clique em Número de compilação repetidamente por no mínimo 7 vezes.

Retorne ao menu de configurações. Você deve, agora, ver o menu Opções do desenvolvedor

Nesse menu, altere a opção principal de Desativado para Ativado, assim como habilite a opção Depuração de USB

Quando conectar seu celular ao PC, pressione Ok para confirmar que autoriza a RSA KEY da máquina.

Descubra qual é o device ID de seu aparelho

Confirme que o aparelho está conectado ao PC e que a opção Depuração de USB está habilitada. Abra uma prompt de comando clicando no menu iniciar e digitando cmd. Nela, digite adb devices e será impressa uma lista de dispositivos conectados, mais ou menos assim:

List of devices attached

1234567891011123    device

Baixe o Oculus Signature File (.osig) e coloque-o na UE

Copie apenas o número que você obteve antes (seu device ID), navegue até https://developer.oculus.com/osig/, e cole-o na caixa de diálogo ao lado do botão Download. Clique em Download e um arquivo de extensão .osig será baixado.

Esse arquivo é necessário para que seu aparelho seja capaz de rodar o aplicativo enquanto ainda em desenvolvimento. Coloque-o em [UE4.15]\Engine\Build\Android\Java\assets\ e a Engine cuidará do resto. Caso possua mais de um smartphone, podem haver tantos osig quanto necessário simultaneamente nessa pasta.

Nota: se não puder encontrar a pasta assets, crie uma no diretório especificado.

Unreal Engine

Crie seu projeto

Crie um novo projeto na Unreal com as seguintes opções:

  • Qualquer template de sua escolha (Blueprint ou C++);
  • Target Hardware: Mobile / Tablet;
  • Graphics Level: Scalable 3D or 2D
  • Dê um nome a seu projeto

Crie o package (.apk)

Configuração para empacotamento

Assim que tiver um design mínimo para seu jogo, faça o seguinte:

Abra Plugins

New Project

Então, confira se tem os seguintes habilitados:

New Project

A seguir, abra o Project Settings, vá a Target Hardware e verifique que está como na imagem a seguir:New Project

Finalmente, em packaging:

New Project

Então:

New Project

Defina

New Project

Defina aqui, também, em Android Package Name o nome final do pacote, lembrando que não deve aparecer [ ou ] em qualquer parte desse nome (use o modelo com.YourCompany.nomedopacote)

Especificamente para GearVR:

É importante definir o caminho da sdk, assim como as versões da API. Nesse próximo passo, verifique manualmente o caminho das pastas a seguir em seu PC (as versões podem ser ligeiramente diferentes) e defina o SDK API level como latest ou matchndk. Deixe o API Level como android-19 para GearVR mesmo que não seja a última versão:

Packaging

Agora basta criar o pacote. Para isso, na Engine,  clique em File>Package Project>Android>Android(ETC2)

Erros nessa etapa frequentemente podem ser resolvidos apagando-se as pastas Binaries, Intermediate e Saved na pasta do projeto. A Unreal recria todas elas automaticamente quando o projeto é aberto, e isso resolve muita coisa aparentemente misteriosa.

Instalando o apk no Android

Com o celular conectado e aparecendo devidamente quando se usa o comando adb devices, abra a pasta Android_ETC2, criada no passo anterior, e clique duas vezes em Install_…-armv7-es2.command. Isso desinstalará qualquer versão anterior do app e instalará a última automaticamente.

Caso ocorra algum erro nessa etapa, é normal que o celular apareça como offline até ser reconectado. Se não der certo depois de algumas tentativas, tente reinstalar os drivers do aparelho, reiniciar ambos e instalar novamente.

 

Adaptado de:

https://github.com/akshaybabloo/GearVR-UnrealEngine4

https://docs.unrealengine.com/latest/INT/Platforms/Android/GettingStarted/1/

Criando uma cena 360 de League of Legends na Unreal Engine 4

Aqui estão nossas experiências para montar uma cena de League of Legends na Unreal Engine 4. Como foi um projeto de aprendizagem, muitas das soluções apresentadas podem não ser as melhores maneiras de se resolverem os problemas. Também não é um guia passo a passo de como foi feito tudo e sim mais um resumo das experiências e impressões que tivemos. Outra coisa a ser considerada é que foi utilizado a versão 4.10 da Unreal Engine 4.

O resultado foi esse:

  • Importando o modelo da fase

A princípio encontramos um modelo da fase Summoner em formato .obj (https://sketchfab.com/models/ac0a9c6676e34d1ebb184d8e93443c77), liberado apenas para estudos, com todas as suas texturas. Porém ao importarmos esse modelo para o UE4, percebemos que as normais dos polígonos estavam invertidas. Para inverter essas normais usamos o programa 3D Blender e a ferramenta Flip Direction que se encontra no modo Edit Mode.  Ainda no blender, retiramos algumas partes da fase que não seriam úteis, como algumas partes que serviam de background.

Ao importar o modelo da fase diversos materiais são criados, sendo que cada um possui uma textura de um trajeto ou pedaço específico da fase. Foi necessário configurar o Especular (Specular) e rugosidade (Roughness) desses materiais, pois os mesmos só possuíam a cor difusa ou base color da textura. A técnica de normalMap também foi aplicada, e o artigo mais detalhado sobre isso está neste link

figura0.1normalmaps

Imagem do normal map e a visualização da técnica aplicada no material do piso.

Não foi possível utilizar a técnica de Lightmap por completo, pois é necessário criar uma segunda camada de uv para a malha da fase. Detalhes dessa técnica de lightmap se encontra nesse link.

O background do cenário foi feito a partir do criador de terrenos (landscape) do UE4. As árvores criadas nesse terreno, foram previamente extraídas do modelo da fase e replicadas no modo Foliage.

figura0.2summonermap

Fase Summoner no UE4 com Landscape.

 

  • Como fazer para importar as animações para o Unreal Engine

Tivemos uma certa dificuldade para conseguir os modelos do jogo, pois não sabíamos como converter os arquivos .anm do League of Legends para um arquivo que o UE4 consiga entender. Como a gente fez para exportar todos esses arquivos está discutido em outro artigo e não vou me alongar muito nessa parte.

  • Decidir quais ferramentas utilizar para fazer a cena

Na Unreal Engine tem essa ferramenta chamada Matinee que sua principal função é de compor uma cena de animação. Ela mexe nas câmeras, coloca uns “efeitos especiais” e faz os movimentos dos objetos.

O problema que percebemos é que a Matinee não tem a função de blending para fazer a transição entre as animações. Ela não considera o estado dos campeões, como a velocidade com que estão deslocando para usar como peso para o blending.

Aliás, simular física também é complicado na Matinee. Subir e descer escadas faz essa tarefa ficar muito difícil para animar pois ela simplesmente ignora qualquer tipo de colisão, fazendo com que os personagens atravessem qualquer objeto.

Por esses motivos decidimos que somente a Matinee não daria muito certo para montar a cena. Então pensamos em animar os campeões por blueprints e AI e somente utilizar a Matinee para dar trigger nos eventos.

  • Animando os personagens por blueprints

Essa parte foi um tanto confusa para quem está aprendendo a mexer na Unreal Engine 4. Confuso pois eles não tratam as animações todas em uma única blueprint.

Pelo que entendemos dos exemplos que vimos do Content Examples, eles separam as animações em duas categorias: as ativadas por input de teclado e clique do mouse, que rodam uma vez ao ser ativada e animações ligadas por estado do personagem, como por exemplo andando e pulando. Esses dois tipos ficam em duas blueprints distintas, uma na blueprint do objeto e outra na blueprint animation da mesh respectivamente.

– Animações de Estado

Nessa categoria entram animações que pertencem a um “estado” do personagem, como por exemplo, andando, pulando e nadando. Elas normalmente precisam ficar em loop, então, são melhor representadas por estados do personagem. É precisamente o que a Animation Blueprint faz, cria estados e até mesmo faz o blending de animações com base em variáveis.

No nosso projeto, criamos para a Ashe um Blend Space 1D que faz um bleding de duas animações com base em uma variável. Utilizamos duas animações originais, uma de correndo e outra de parada com a variável Speed. O resultado ficou desse jeito:

Nota do autor: Esse resultado me deixou impressionado na primeira vez que fiz o blending, parece que realmente ela começa a andar com Speed intermediário.

Com essa Blend Space pudemos criar um estado chamado Idle/Running que é alimentado pela variável Speed na blueprint animation. O blueprint animation ficou desse jeito:

BP_Animation_Ashe1

Clicando em Default temos

BP_Animation_Ashe2

E depois em Idle/Running

BP_Animation_Ashe3

E essa blueprint é do Event Graph

BP_Animation_Ashe4

Para testar essa animação, fizemos um copy paste na blueprint de controle do personagem do mapa exemplo ThirdPerson e só troquei o modelo da Ashe e o Blueprint Animation acima.

– Animações Ativadas

Nessa categoria ficam animações que são acionadas e “rodadas” uma vez. Por exemplo ataques com espada e tiro com alguma arma caem nessa categoria.

O blueprint da Ashe que fiz para atirar uma flecha ficou assim:

figura5_BP_Ashe

E como ficou a animação final:

Explicando o blueprint feito:

-> InputActionAttack: O evento que faz o trigger é o clique do mouse esquerdo que está com o nome Attack. Poderia ser qualquer trigger de evento mas pela similaridade com jogos de tiro optamos por colocar como trigger esse input mesmo. Se no seu mapa não tiver essa opção do clique esquerdo do mouse, tem que mexer na configuração em Edit > Project Settings depois ir em Engine > Input e adicionar o input desejado.

-> Deactivate/ToggleActive: Um dos problemas que tive ao fazer a ação de ataque é que a Ashe podia andar enquanto fazia a animação de atirar. Para resolver esse problema resolvemos que enquanto ela está atirando, todos os inputs são ignorados pelo personagem. No final devolvemos o comando com o ToggleActive.

-> Montage Play: Aciona uma animação do tipo Animation Montage . Não sabemos muito bem como funciona esse tipo de função mas sabemos que essa animação é inserida no node Slot lá da blueprint animation. No caso foi inserida a animação de ataque.

-> Delay/SpawnActor Flecha: O delay serve para que o modelo da flecha seja criada no instante em que ela solta. A variável Arrow Socket contém o nome do socket da skeleton da Ashe onde fica a metade do arco, localizando assim onde vai ser criado a flecha.

-> Último Delay: Para que não fique spammando tiros, a Ashe tem que terminar a animação antes que possa atirar novamente. Antes disso podíamos atirar várias flechas como se fosse uma metralhadora.

Talvez por ter um tratamento todo específico, a implantação da animação de ataque na blueprint do objeto foi a melhor abordagem a ser feita.

Essas blueprints ficaram muito modularizadas, utilizamos praticamente 95% delas em todas as outras unidades.

  • Lidando com a Inteligência Artificial e Behavior Trees

Essa parte deu um trabalho grande para implementar. Com as animações prontas tivemos que montar uma IA que fizesse seguir pelo caminho e que fosse comandado para atacar um alvo na hora em que quiséssemos. Tivemos dificuldade para entender como funciona a Behavior Tree, pois não era familiar essa abordagem em árvore.

Para que eles caminhassem pela bottom lane, tivemos que colocar vários target points no mapa e colocar todos eles num array, para que ao chegar num target point ele achava o próximo só aumentando o índice desse array.

Summoners_rift_season_4_map

Para unidades ranged fizemos uma modificação na função MoveTo para que se fosse do tipo ranged, o Acceptance Radius fosse maior fazendo com que a unidade parasse longe da unidade alvo.

Tivemos problemas com a Task MoveTo porque essa task não para de executar enquanto não atingir o ponto ou encontrar um bloqueio no meio do caminho. Logo se eu mandasse ir para um ponto e comandasse para atacar no meio do caminho, ele terminava de percorrer o caminho até o ponto e depois ia fazer o ataque.

Uma solução é tentar fazer com que tenha muito mais target points no caminho mas vimos que os minions dão uma paradinha para cada target point, fazendo com que a movimentação ficasse muito travada. Achamos melhor deixar como está e contornar o problema setando os comandos de ataque um pouco antes deles chegarem no ponto.

A Ai funcionava simulando mais ou menos como o jogo funciona, você tem o alvo e ele ataca ou se move até ele, dependendo se era um TargetPoint ou se era um Pawn ( no caso minions e campeões).

figura5.1_behaviortree

  • Tentativa de integração da AI com a Matinee

Programamos a AI pensando em integrar com a Matinee que ia controlar os eventos de quando atacar e movimentar os personagens. Essa primeira tentativa deu errado pela sua instabilidade, não funcionava muito bem escolhendo personagens aleatórios para as ações e as vezes nem funcionava.

Colocamos umas variáveis booleanas nos campeões para simular mais ou menos como o jogo funciona:

-> IsSelected para avisar que personagem ia fazer uma ação;

-> IsTarget para avisar qual objeto/personagem ia ser o alvo da ação;

figura6_booleans

E criamos dois eventos na Matinee que acionava os eventos de Ataque e Movimento. Ela também setava as duas variáveis para true no momento que chamavam os eventos, sendo tudo mandado para a blueprint do level.

figura7_matineesetando

E a blueprint do level cuidava da lógica necessária para os controladores AI saberem que ações fazer e setava para false os dois booleans.

figura8_setarVariáveisAI

Então funcionava mais ou menos assim:

  1. A Matinee setava IsSelected para true para um campeão que quisessemos fazer uma ação. No caso da figura os red minions foram selecionados.
  2. Também setava IsTarget para true o alvo que ia sofrer a ação. O alvo no caso é a Ashe.
  3. A Matinee dá o trigger do evento de Attack.
  4. No level blueprint ele pega os atores que tem true em IsSelected e IsTarget e coloca na blackboard da AI para que possa executar a ação e depois setava para false os dois.

Para um evento funcionava muito bem, mas conforme colocamos vários eventos ao mesmo tempo em paralelo, não dava tempo para os booleans terminarem de ser setados para false e mesmo a Matinee é meio instável quanto a isso.

Então resolvemos jogar todo esse código fora e fazer tudo no level blueprints mesmo.

  • Fazendo a cena inteira com o level blueprints

Fazendo no level blueprints ficou muito mais fácil a questão de mandar um campeão fazer uma ação, ficando uma função bem mais direta do que estava no código anterior. Colocamos o código empacotado numa função chamada Action.

figura10_função_action

E chamava a função com um delay antes, simulando uma linha do tempo.

(Deveria ter colocado a função Delay dentro do Action porque utilizei em todas as instâncias de Action)

figura9_animação_em_blueprint

Por fim com essa abordagem deu certo e o resultado final foi esse:

  • Gravando em 360

Nessa parte utilizamos esse tutorial para fazer esse tipo de gravação:

Colocamos a PanoCam e PanoCamCapture no mapa e com a Matinee guiamos a sua movimentação por ela. Capturado as cenas, renderizamos no blender pelo Video Editing.

Resumo rápido desse tutorial acima:

Tem que colocar os dois objetos PanoCam e PanoCamCapture no mapa. O PanoCam tira fotos em vários ângulos para montar uma imagem 360 e a PanoCamCapture é o que faz a captura das imagens para salvar. Logo a PanoCam é o que nós movimentamos pela tela e a PanoCamCapture fica em um lugar isolado debaixo do solo.

Depois de alguns ajustes de velocidade da câmera (diminuímos a velocidade em 4x) chegamos na versão final do começo do artigo.

 

Boas práticas no desenvolvimento para VR

A recente evolução nas tecnologias relacionadas à realidade virtual trouxeram grande atenção para o meio. Apesar de uma certa variedade entre os HMDs (head mounted displays), existem certas práticas e cuidados que são pré-requisitos no desenvolvimento voltado para realidade virtual. Este texto baseado no guia de boas práticas do Gear VR (que diz respeito ao Oculus Rift também, mas se aplica a outros dispositivos) listará alguns pontos que devem ser levados em consideração pelo desenvolvedor durante o projeto e construção de seu aplicativo.

O propósito geral das boas práticas no desenvolvimento para VR é evitar o desconforto no usuário causado por discrepâncias do ambiente virtual comparado com um ambiente natural. O não cumprimento destas boas práticas pode causar “simulator sickness” – uma combinação de sintomas que engloba tensão ocular, desorientação e náusea.

No campo da realidade virtual ainda não existem práticas consolidadas, por ser uma área nova, portanto os testes e feedbacks dos usuários são essenciais para o projeto de experiências atraentes e confortáveis.

Renderização

– Para criar uma imagem na tela do HMD que crie a sensação de imersão no usuário, é necessário renderizar uma imagem para cada olho com uma distorção apropriada para compensar a distorção causada pelas lentes. É recomendado utilizar os shaders de distorção do fabricante, usar uma solução própria é arriscado.

Renderização estéreo OculusWorldDemo

– Use a matriz de projeção corretamente e use o head model padrão do fabricante. Qualquer desvio do fluxo óptico que acompanha o movimento da cabeça no mundo real cria problemas oculomotores e desconforto corporal.
– Manter imersão VR do começo ao fim. Não usar splash screen (a não ser que esteja imersa no ambiente virtual também), pode causar desorientação.
– Imagens apresentadas pra cada olho devem diferenciar-se apenas em termos de ponto de vista. Quaisquer outros tipos de pós processamento devem ser consistentemente aplicados aos dois olhos.
– Considerar supersampling ou anti-aliasing para mitigar baixa resolução aparente (fica ruim no centro da tela de cada olho).

Minimizando latência

– O código deve rodar à um framerate igual ou maior que a taxa do display do HMD (90 Hz no caso do Oculus Rift) com v-sync e unbuffered (escrevendo diretamente na tela ao invés de utilizar um buffer secundário antes). Lag e frames incompletos causam trepidação e desconforto em VR.
– Busque 20 ms ou menos de latência motion-to-photon (demora para o movimento da cabeça ser refletido na tela) (pode ser medido com testador de latência no caso do Oculus Rift).
– Organize o código de modo a minimizar o tempo de leitura dos sensores para renderizar.
– Latência do game loop (função principal do game que roda a cada frame) não é uma constante e varia com o tempo. Existem técnicas para proteger o usuário dos efeitos da latência (como predictive tracking, TimeWarp) mas faça o que puder para minimizar variabilidade da latência do loop.
– No caso da SDK da Oculus, é recomendado utilizar o rastreamento preditivo da SDK usando um parâmetro de tempo preciso. O valor de rastreamento preditivo varia de acordo com a latência da aplicação e deve ser afinado para cada aplicação.

Otimização

– Diminua resolução do buffer de renderização pra cada olho para salvar memória e aumentar o framerate.
– Diminuir a resolução do buffer de renderização pra cara olho mas manter a resolução da tela ( ou seja, depois de calcular para cada olho magnifica-se a imagem interpolando pixels ) pode melhorar a performance com menor efeito na qualidade visual do que no caso de diminuir a resolução da tela também.

Head-Tracking e ViewPoint

– Evite visuais que desagradem o senso de estabilidade do usuário no ambiente. Conflitos entre a movimentação real (ou falta de ) do usuário e a movimentação recriada em VR podem ser desconfortáveis.
– A tela deve responder à movimentação do usuário a todo momento (mesmo em menus, game pausado ou cutscenes).
– No caso do Oculus Rift, utilize o rastreador de posição e head model da SDK para garantir que as câmeras se movam consistentemente com o corpo do usuário, discrepâncias são desconfortáveis.

Positional Tracking (Rastreamento posicional)

(As câmeras citadas aqui se referem a câmeras de rastreamento de movimento que trabalham em conjunto com os sensores do HMD para calcular a posição do usuário.)

Oculus rift e a camera de rastreamento de posição.

– A imagem renderizada deve corresponder com os movimentos físicos do usuário, não manipule o ganho de movimento da câmera virtual. Uma única escala global no head model não tem problema (converter pés para metros, aumentar ou diminuir o jogador), mas não escale movimento da cabeça independentemente da distância inter-pupilar do usuário.
– Com positional tracking o usuário pode olhar em lugares que você não esperaria, como embaixo de objetos, atrás de protuberâncias. Considere sua solução para back-face culling.
– Em certas circunstâncias, o usuário pode usar o positional tracking para atravessar objetos “sólidos” no ambiente virtual. É notado que usuários evitam colocar a cabeça através de objetos uma vez que notam a possibilidade, a não ser que haja uma oportunidade de tirar proveito do design do game. Uma solução é disparar uma mensagem informando-os que eles deixaram o volume de rastreamento da câmera.
– É recomendado que não se deixe o ambiente virtual na tela do HMD se o usuário sair do volume de rastreamento da câmera (frustum, ou tronco de piramide). É mais confortável fazer um escurecimento gradual na tela ou atenuar imagem (diminuir brilho e/ou contraste) antes do rastreamento ser perdido.
– Escalonar o movimento ou desabilitar o position tracking é desconfortante. Evite, e escureça a tela caso aconteça ou pelo menos mantenha o rastreamento de orientação usando o head model da SDK quando o rastreamento de posição seja perdido.

Acelerações

– Acelerações causam desencontro nos sentidos visual, vestibular (orientação ou equilíbrio) e de propriocepção (capacidade em reconhecer a localização espacial do corpo, sua posição e orientação, a força exercida pelos músculos e a posição de cada parte do corpo em relação às demais.). É bom diminuir as ocorrências de aceleração e deixá-las o mais curtas (ou instantâneas) possível.
– Aceleração dita aqui é no sentido geral, incluindo mudanças de direção.
– Tenha acelerações iniciadas e controladas pelo usuário sempre que possível. Tremulações, trancos e sacudidas na câmera são desconfortáveis pro jogador.

Velocidade de movimento

– Ver o ambiente virtual de uma posição estacionária é o mais confortável, mas quando movimento pelo ambiente é necessário, o mais confortável são velocidades constantes, próximas de velocidades reais (humanos andam a aproximadamente 1.4 m/s).
– Teleporte entre dois pontos em vez de andar entre eles vale a pena ser experimentado em alguns casos, mas pode ser desorientador. Se teleportar busque dar sinais visuais para que o usuário consiga manter sua orientação.
– Movimentos em direções diferentes da direção de observação podem causar desorientação.
– Evite oscilações lineares verticais (mais desconfortáveis a 0.2 Hz), e rotação fora-do-eixo-vertical (mais desconfortáveis a 0.3 Hz).

Câmeras

– Zoom in ou zoom out com a câmera pode induzir ou piorar o enjoo de simulador (simulator sickness), particularmente se eles alterarem a proporção de movimento entre a cabeça e a câmera para outra que não 1:1. É recomendado evitar o efeito de Zoom até obter-se mais dados sobre o uso confortável desse.
– Evite usar ângulos de Euler, prefira quaterniões sempre que possível. Tente olhar pra cima e para baixo para testar sua câmera, deve estar sempre estável e consistente com a usa orientação.
– Não use efeitos que balancem a cabeça (head bobbing), eles criam uma série de pequenas mas desconfortáveis acelerações.

Gerindo e testando o enjoo de simulador

– Teste seu conteúdo com uma variedade de pessoas não vinculadas com o desenvolvimento do aplicativo para se assegurar que é confortável para uma audiência abrangente.
– A resposta e tolerância das pessoas em relação a enjoo de simulador varia, e enjoo causado por visão ocorre mais prontamente com HMDs de realidade virtual do que com telas de tv. A audiência não vai suportar experiencias intensas além do limite e nem deveriam.
– Considere implementar mecanismos que permitam o usuário ajustar a intensidade da experiencia visual. Isso é relativo ao conteúdo, mas ajustes podem incluir velocidade de movimento, intensidade de aceleração, largura do campo de visão. O valor padrão dessas variáveis deve estar arrumado para menor intensidade de experiencia visual.
– Sempre que possível permita que estas variáveis possam ser ajustadas dentro do jogo, sem reiniciar.
– Um background visual independente que case com o referencial inercial do jogador, que não responda ao input do controle, mas que possa ser escaneado com movimentos do HMD pode reduzir o conflito visual com o sistema vestibular e aumentar a sensação de conforto (e.g. skybox).

Exemplo de skybox, créditos: Alwyn Dippenaar

– Imagens com alta frequência espacial (listras, texturas finas) podem aumentar a percepção de movimento num ambiente virtal, levando ao desconforto. Use (ou ofereça a opção de) texturas uniformes no ambiente, como cores sólidas ao invés de padrões, para proporcionar uma experiência mais confortável para os usuários mais sensíveis.

Exemplo de textura com alta frequência espacial.

Grau de profundidade estereoscópica (“3D-ness”)

– Para um realismo individualizado e um mundo corretamente dimensionado, use os vetores de distância de separação middle-to-eye fornecidos pelo perfil do usuário.
– Esteja ciente que a percepção tridimensional é mais sensível de perto, mas rapidamente diminui com a distância.
– Apesar de ser possível aumentar a sensação de estereopsia (sensação espacial causada pela visão estéreo) aumentando a distância entre as câmeras virtuais, é importante estar ciente dos efeitos colaterais. Isso forçará os usuários a convergir os olhos mais que o normal, o que pode levar a tensão ocular se você não mover objetos pra mais longe das câmeras de acordo. Pode também dar origem a anomalias perceptuais e desconforto se você falhar em dimensionar o movimento da cabeça igualmente com a separação dos olhos.

Interface de usuário (user interface – UI)

– UIs devem ser parte do mundo 3D virtual e estar aproximadamente a 2-3 metros de distância do espectador, mesmo se desenhadas em polígonos chatos, cilindros ou esferas que ficam na frente do usuário. O importante é não ser algo que quebre a imersão do ambiente 3D, como os menus de jogos tradicionais.
– Não exija que o usuário precise girar os olhos em suas órbitas oculares para ver a interface. Dividindo a área visível do usuário em 3 partes verticais, sua UI deve caber na parte do meio. Caso contrário, eles devem ser capazes de enxergar a UI com movimento de cabeça.
– Tome cuidado com elementos da interface que se movem ou se redimensionam com movimentos da cabeça (menu longo que rola pra baixo com o movimento da cabeça). Certifique-se de que eles respondem precisamente aos movimentos do usuário e que são facilmente legíveis sem criar movimentos distrativos ou desconforto.
– Esforce-se para integrar sua interface com o contexto do mundo virtual. Por exemplo, a quantidade de munição pode ser mostrada na própria arma em vez de por símbolos na tela.
– Desenhe uma cruz, retículo ou cursor na mesma profundidade que o objeto que esta sendo mirado. Quando esse não está no plano de profundidade que os olhos estão convergidos, o usuário pode enxergar uma imagem dobrada.

Controlando avatar

– Dispositivos de input do usuário não podem ser vistos quando ele esta usando o HMD. Permita o uso de controles familiares com input padrão ou, caso seja absolutamente necessário usar teclado, mantenha em mente que o usuário dependerá de resposta tátil para encontrar os controles.
– Considere usar movimentos da cabeça como controle direto ou como maneira de introduzir sensibilidade de contexto no seu esquema de controle.

Som

– Tenha em mente que quando o usuário esta com headphones, a fonte de áudio o acompanha, mas não é o caso quando ele está utilizando alto falantes. permita ao usuário escolher a sua fonte de áudio nas configurações do game e certifique-se de que o áudio aparente sair do local correto levando em consideração a posição da cabeça e a fonte do áudio.
– Apresentar falas de NPC sobre o áudio central é uma prática comum porém isso pode quebrar a imersão do usuário em VR. Espacializar o áudio (evidenciar direção de origem, interação com o ambiente simulado, etc), mesmo que grosseiramente, pode melhorar a experiência do usuário.
– Mantenha o rastreamento posicional em mente quando projetar o áudio, por exemplo, o som deve ficar mais forte conforme o usuário vai na direção da fonte.

Conteúdo

– Um metro no mundo real corresponde aproximadamente a uma unidade de distância no Unity.
– A ótica do DK2 Rift torna mais confortável a visualização de objetos que ficam dentro do intervalo de 0.75 a 3.5 metros de distância. Apesar do ambiente virtual englobar qualquer distância, objetos que o usuário vê por períodos prolongados ficam melhor nesse intervalo de distância.
– Convergir os olhos para distâncias menores que o intervalo de distância confortável pode levar as lentes dos olhos a desfocar, tornando borradas as imagens que foram renderizadas nitidamente e causando tensão ocular.
– Imagens claras podem (especialmente em suas periferias ) podem criar flickering (oscilação na intensidade de luz) notável no display para usuários sensíveis, se possível use cores escuras para prevenir desconforto.
– Avatar virtual pode causar imersão maior no ambiente, mas também pode causar sensações incomuns caso haja discrepância. Considere isso quando estiver projetando seu conteúdo.
– Considere o tamanho e textura das suas artes pra um sistema em que aliasing de textura e de resolução são um problema (evite objetos muito finos).
– Acelerações verticais inesperadas podem criar desconforto. Considere achatar superfícies ou estabilizar o ponto de vista do usuário quando viajar por terrenos sinuosos.
– Considere que o seu usuário esta em um nível sem precedente de imersão e conteúdos assustadores ou chocantes podem ter efeitos profundos nos usuários (principalmente os mais sensíveis) de uma maneira que mídias anteriores não poderiam. Certifique-se que os jogadores recebam avisos sobre tais conteúdos anteriormente.
– Não dependa apenas do efeito esterioscópico 3D para prover sensação de profundidade no seu conteúdo. Luz, textura, paralaxe e outros efeitos visuais são igualmente (se não mais) importantes para trazer profundidade e espaço ao usuário.
– Projete ambientes e interações que minimizem a necessidade de movimentação de lateral, passos para trás ou rotação, que podem ser desconfortáveis em VR.
– Pessoas moverão a cabeça para olhar coisas que estejam com deslocamento angular de 15 a 20 graus do ponto em que estão olhando atualmente. Evite forçar o usuário a fazer grandes movimentos para evitar fadiga muscular e desconforto.
– Como o usuário pode ver em qualquer direção a qualquer momento, certifique-se que não haverá nada que quebre a imersão (como gambiarras técnicas).

Aparência do avatar

– Quando for representar o próprio jogador no ambiente virtual, mãos e um corpo muito diferente da pessoa podem causar uma quebra de imersão. Por exemplo, se uma mulher olhar para baixo e ver mãos e corpo de um homem a sensação de imersão pode ser quebrada, isso pode ser melhorado dramaticamente tornando possível customização das mãos e do corpo. Caso o custo desta customização seja muito grande, podem ser tomadas medidas para mitigar esse problema, como o uso de luvas e roupas unissex. Corpos não muito masculinos ou femininos também ajudam a manter a ambiguidade em aspectos da identidade do avatar, como gênero, tipo de corpo e cor de pele.

Saúde e segurança

– EVITE usar quaisquer imagens piscantes de alto-contraste ou cores alternantes que mudam com uma frequência no espectro de 1 a 30 Hertz. ISSO PODE DESENCADEAR UMA CONVULSÃO EM USUÁRIOS COM EPILEPSIA FOTOSSENSÍVEL.
– Evite gradeamentos de alta frequência espacial ou alto contraste ( listras branco e pretas finas ) pois esses também podem induzir epilepsia fotossensível.

O site do Oculus Rift disponibiliza um PDF  com informações mais completas sobre saúde e segurança.

*****************************************

Link do guia original