Primer AR/VR¶

Este tutorial fornece será sua porta de entrada para o mundo de AR e VR no Godot game engine.

Uma nova arquitetura foi introduzida no Godot 3 chamada AR/VR Server. Além dessa arquitetura, implementações específicas estão disponíveis como interfaces, a maioria dos quais são plugins baseados em GDNative. Este tutorial se concentra exclusivamente nos elementos centrais abstraídos pela arquitetura central. Essa arquitetura possui funcionalidades suficientes para você criar uma experiência de RV completa que pode ser implantada em várias interfaces. No entanto, cada plataforma geralmente possui alguns recursos exclusivos que são impossíveis de abstrair. Tais funcionalidades serão documentados nas interfaces relevantes e estão fora do escopo deste manual.

Servidor AR/VR¶

Quando Godot for iniciado, cada interface disponível se tornará conhecida pelo servidor AR/VR. As interfaces GDNative são configuradas como singletons; contanto que eles sejam adicionados à lista de singletons GDNative em seu projeto, eles se tornarão conhecidos do servidor.

Você pode usar a função get_interfaces() para retornar uma lista de interfaces disponíveis, mas para este tutorial, vamos usar a native mobile VR interface em nosso exemplos. Essa interface é uma implementação direta que usa os sensores 3DOF em seu telefone para orientação e exibe uma imagem estereoscópica na tela. Ele também está disponível no núcleo Godot e é exibido na tela da área de trabalho, o que o torna ideal para prototipagem ou um tutorial como este.

Para habilitar uma interface, você executa o seguinte código:

var arvr_interface = ARVRServer.find_interface("Native mobile")
if arvr_interface and arvr_interface.initialize():
    get_viewport().arvr = true

var arvrInterface = ARVRServer.FindInterface("Native mobile");
if (arvrInterface != null && arvrInterface.Initialize())
{
    GetViewport().Arvr = true;
}

Esse código encontra a interface que desejamos usar, inicializa-a e, se for bem-sucedida, vincula a viewport principal à interface. Esta última etapa dá algum controle sobre a viewport para a interface, que permite automaticamente coisas como renderização estereoscópica na viewport.

Para nossa interface de VR mobile e qualquer interface onde a entrada principal é exibida diretamente na tela, a viewport principal precisa ser a viewport onde arvr é definido como true. Mas para interfaces que renderizam em um dispositivo conectado externamente, você pode usar uma viewport secundária. No último caso, uma viewport que mostra sua saída na tela mostrará uma versão não distorcida do olho esquerdo, enquanto mostra a saída estereoscópica totalmente processada no dispositivo.

Finalmente, você só deve inicializar uma interface uma vez; alternar cenas e reinicializar interfaces apenas apresentará muita sobrecarga. Se você quiser desligar o fone de ouvido temporariamente, apenas desative a viewport ou defina arvr como false na viewport. Na maioria dos cenários, porém, você não desativaria o fone de ouvido quando estiver em VR, isso pode ser desconcertante para o jogador.

Novos nós de AR/VR¶

Três novos tipos de nó foram adicionados para suportar AR e VR no Godot e um tipo de nó adicional especialmente para AR. Estes são:

ARVROrigin - nosso ponto de origem no mundo
ARVRCamera - uma subclasse especial da câmera, que é rastreada posicionalmente
ARVRController - uma nova classe espacial, que rastreia a localização de um controlador
ARVRAnchor - um ponto de ancoragem para uma implementação AR mapeando uma localização do mundo real em seu mundo virtual

Os dois primeiros devem existir em sua cena para que o AR/VR funcione e este tutorial se concentra exclusivamente neles.

ARVROrigin é um nó importante, você deve ter um e apenas um deles em algum lugar em sua cena. Este nó mapeia o centro de seu espaço de rastreamento do mundo real para um local em seu mundo virtual. Todo o resto é rastreado posicionalmente em relação a este ponto. Onde esse ponto está exatamente difere de uma implementação para outra, mas o melhor exemplo para entender como esse nó funciona é dar uma olhada em um local em escala de sala. Embora tenhamos funções para ajustar o ponto para centralizá-lo no player por padrão, o ponto de origem será o local central da sala em que você está. Conforme você anda fisicamente pela sala, a localização do HMD é rastreada em relação a esta posição central e o rastreamento é espelhado no mundo virtual.

Para manter as coisas simples, quando você se move fisicamente em sua sala, o ponto ARVR Origin permanece onde está, a posição da câmera e dos controladores será ajustada de acordo com seus movimentos. Quando você se move pelo mundo virtual, seja pela entrada do controlador ou quando implementa um sistema de teletransporte, é a posição do ponto de origem que você terá que ajustar.

ARVRCamera é o segundo nó que deve sempre fazer parte da sua cena e deve ser sempre um nó filho do seu nó de origem. É uma subclasse da câmera normal de Godot. No entanto, sua posição é atualizada automaticamente a cada quadro com base na orientação física e na posição do HMD. Também devido à precisão necessária para renderizar para um HMD ou renderizar uma sobreposição de AR sobre uma câmera do mundo real, a maioria das propriedades padrão da câmera é ignorada. As únicas propriedades da câmera que são usadas são as configurações dos planos próximo e distante. O FOV, proporção e modo de projeção são todos ignorados.

Note that, for our native mobile VR implementation, there is no positional tracking, only the orientation of the phone and by extension, the HMD is tracked. This implementation artificially places the camera at a height (Y) of 1.85.

Conclusão: sua configuração mínima em sua cena para fazer AR ou VR funcionar deve ser assim:

And that's all you need to get started with the native mobile interface. Obviously, you need to add something more into your scene, so there is something to see, but after that, you can export the game to your phone of choice, pop it into a viewer and away you go.

Plugins e recursos oficiais¶

As mentioned earlier, Godot does not support the various VR and AR SDKs out of the box, you need a plugin for the specific SDK you want to use. There are several official plugins available in the GodotVR Repository.

Godot OpenXR: This is the official XR plugin starting with Godot 3.4. It supports OpenXR, an open standard for designing and building cross-platform VR and AR software. Tested with SteamVR, Monada and Oculus OpenXR (desktop and mobile) runtimes.
- Veja Plugin OpenXR.
Godot Oculus Mobile fornece suporte para a Meta Quest.
- Note: This plugin has been deprecated starting with Godot 3.4. We recommend migrating to the Godot OpenXR plugin instead.
Godot OpenVR (não confundir com OpenXR) suporta o OpenVR SDK usado pela Steam.
Godot Oculus suporta o Oculus SDK (somente para desktop headsets).
- Note: This plugin has been deprecated starting with Godot 3.4. We recommend migrating to the Godot OpenXR plugin instead.
Godot OpenHMD suporta OpenHMD, uma API de código aberto e drivers para headsets.

These plugins can be downloaded from GitHub or the Godot Asset Library.

In addition to the plugins, there are several official demos.

Godot Oculus Demo.
Godot OpenVR FPS (the tutorial for this project is Tutorial inicial de VR parte 1).
Godot XR tools, which shows implementations for VR features such as movement and picking up objects.

Other things to consider¶

There are a few other subjects that we need to briefly touch upon in this primer that are important to know.

A primeira são as nossas unidades. Em jogos 3D normais, você não precisa pensar muito sobre as unidades. Contanto que tudo esteja na mesma escala, uma caixa com o tamanho de 1 por 1 por 1 unidade pode ser de qualquer tamanho, desde um filho que você pode segurar na mão até algo do tamanho de um edifício. Em AR e VR, isso muda porque as coisas em seu mundo virtual são mapeadas para coisas no mundo real. Se você avança 1 metro no mundo real, mas só avança 1 cm no mundo virtual, você tem um problema. O mesmo com a posição de seus controladores; se não aparecerem no espaço relativo correto, quebra a imersão para o jogador. A maioria das plataformas VR, incluindo nosso servidor AR/VR, assume que 1 unidade = 1 metro. O servidor AR/VR, no entanto, possui uma propriedade que, por conveniência, também é exposta no nó ARVROrigin chamada de escala mundial. Por exemplo, definir isso para um valor de 10 muda nosso sistema de coordenadas, então 10 unidades = 1 metro.

Performance is another thing that needs to be carefully considered. Especially VR taxes your game a lot more than most people realize. For mobile VR, you have to be extra careful here, but even for desktop games, there are three factors that make life extra difficult:

You are rendering stereoscopic, two for the price of one. While not exactly doubling the work load and with things in the pipeline such as supporting the new MultiView OpenGL extension in mind, there still is an extra workload in rendering images for both eyes
A normal game will run acceptably on 30fps and ideally manages 60fps. That gives you a big range to play with between lower end and higher end hardware. For any HMD application of AR or VR, however, 60fps is the absolute minimum and you should target your games to run at a stable 90fps to ensure your users don't get motion sickness right off the bat.
The high FOV and related lens distortion effect require many VR experiences to render at double the resolution. Yes a VIVE may only have a resolution of 1080x1200 per eye, we're rendering each eye at 2160x2400 as a result. This is less of an issue for most AR applications.

All in all, the workload your GPU has in comparison with a normal 3D game is a fair amount higher. While things are in the pipeline to improve this, such as MultiView and foveated rendering, these aren't supported on all devices. This is why you see many VR games using a more art style and if you pay close attention to those VR games that go for realism, you'll probably notice they're a bit more conservative on the effects or use some good old optical trickery.