Primer AR/VR¶

Este tutorial te da un trampolín al mundo de la RA y la RV en el motor del juego de Godot.

Una nueva arquitectura fue introducida en Godot 3 llamada el Servidor AR/VR. Además de esta arquitectura, existen implementaciones específicas como interfaces, la mayoría de las cuales son plugins basados en GDNative. Este tutorial se centra puramente en los elementos centrales abstractos de la arquitectura central. Esta arquitectura tiene suficientes características para crear una experiencia de RV completa que luego puede ser implementada para varias interfaces. Sin embargo, cada plataforma a menudo tiene algunas características únicas que son imposibles de abstraer. Esas características se documentarán en las interfaces pertinentes y quedan fuera del ámbito de este manual.

Servidor AR/VR¶

Cuando Godot comience, cada interfaz disponible se dará a conocer al servidor AR/VR. Las interfaces GDNative se configuran como singletons; mientras se añadan a la lista de singletons GDNative en su proyecto, se darán a conocer al servidor.

Puedes usar la función get_interfaces() para devolver una lista de las interfaces disponibles, pero para este tutorial, vamos a usar la interfaz de RV móvil nativa en nuestros ejemplos. Esta interfaz es una implementación sencilla que utiliza los sensores 3DOF de su teléfono para orientarse y produce una imagen estereoscópica en la pantalla. También está disponible en el núcleo de Godot y da salida a la pantalla en el escritorio, lo que la hace ideal para la creación de prototipos o un tutorial como este.

Para activar una interfaz, ejecutarás el siguiente 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;
}

Este código buscará la interfaz que deseamos utilizar, la inicializará y, si tiene éxito, enlazará el viewport principal a la interfaz. Este último paso da un cierto control sobre el viewport a la interfaz que permite hacer automáticamente cosas como la representación estereoscópica en el viewport.

Para nuestra interfaz de RV móvil, y cualquier interfaz en la que la entrada principal se muestre directamente en la pantalla, el puerto de vista principal debe ser el puerto de vista donde :ref:arvr<class_Viewport_property_arvr>` se establece en ``true. Pero para las interfaces que se renderizan en un dispositivo externo, puedes usar una vista secundaria. En este último caso, una vista que muestre su salida en pantalla mostrará una versión no distorsionada del ojo izquierdo, mientras que mostrará la salida estereoscópica completamente procesada en el dispositivo.

Finalmente, sólo debes inicializar una interfaz una vez; cambiar de escena y reiniciar las interfaces sólo introducirá una gran cantidad de gastos generales. Si quieres apagar los auriculares temporalmente, sólo tienes que desactivar el viewport o poner arvr a false en el viewport. En la mayoría de los escenarios, sin embargo, no desactivarías el auricular una vez que estás en VR, esto puede ser desconcertante para el jugador.

Nuevo Nodos AR/VR¶

Se han añadido tres nuevos tipos de nodos para soportar AR y VR en Godot y un tipo de nodo adicional especialmente para AR. Estos son:

ARVROrigin - nuestro punto origen en el mundo
ARVRCamera - una subclase especial de la cámara, que es rastreada posicionalmente
ARVRController - una nueva clase espacial, que rastrea la ubicación de un controlador
ARVRAnchor - un punto de anclaje para una implementación de RA mapeando una ubicación del mundo real en su mundo virtual

Los dos primeros deben existir en tu escena para que el AR/VR funcione y este tutorial se centra puramente en ellos.

ARVROrigin es un nodo importante, debes tener uno y sólo uno de estos en algún lugar de tu escena. Este nodo mapea el centro de tu espacio de rastreo en el mundo real a una ubicación en tu mundo virtual. Todo lo demás es rastreado posicionalmente en relación a este punto. Dónde se encuentra este punto difiere exactamente de una implementación a otra, pero el mejor ejemplo para entender cómo funciona este nodo es echar un vistazo a una ubicación a escala de habitación. Aunque tenemos funciones para ajustar el punto para centrarlo en el reproductor de forma predeterminada, el punto de origen será la ubicación central de la habitación en la que se encuentre. Mientras caminas físicamente alrededor de la habitación, la ubicación del HMD es rastreada en relación a esta posición central y el rastreo es espejo en el mundo virtual.

Para simplificar, cuando te mueves físicamente por la habitación, el punto de origen del ARVR se mantiene donde está, la posición de la cámara y los controladores se ajustarán de acuerdo con tus movimientos. Cuando te mueves por el mundo virtual, ya sea a través de la entrada del controlador o cuando implementas un sistema de teleportación, es la posición del punto de origen la que tendrás que ajustar.

ARVRCamera es el segundo nodo que siempre debe ser parte de tu escena y siempre debe ser un nodo hijo de tu nodo de origen. Es una subclase de la cámara normal de Godot. Sin embargo, su posición se actualiza automáticamente cada fotograma basado en la orientación física y la posición del HMD. También debido a la precisión requerida para la renderización a un HMD o la renderización de una superposición AR sobre una cámara del mundo real, la mayoría de las propiedades estándar de la cámara son ignoradas. Las únicas propiedades de la cámara que se utilizan son los ajustes del plano cercano y lejano. El FOV, la relación de aspecto y el modo de proyección son todos ignorados.

Tengan en cuenta que, para nuestra implementación de RV móvil nativa, no hay un seguimiento posicional, sólo la orientación del teléfono y por extensión, el HMD es rastreado. Esta implementación coloca artificialmente la cámara a una altura (Y) de 1,85.

Conclusión: la configuración mínima para hacer que una escena AR o VR funcione, debería verse así:

Y eso es todo lo que necesitas para empezar con la interfaz nativa del móvil. Obviamente, necesitas añadir algo más a tu escena, para que haya algo que ver, pero después de eso, puedes exportar el juego al teléfono que quieras, ponerlo en un visor y listo.

Plugins oficiales y recursos¶

Como se mencionó anteriormente, Godot no admite de forma nativa las diferentes SDK de realidad virtual (VR) y realidad aumentada (AR); necesitas un complemento (plugin) para el SDK específico que deseas utilizar. Hay varios complementos oficiales disponibles en el repositorio GodotVR.

Godot OpenXR: Este es el complemento oficial de XR que comienza con Godot 3.4. Admite OpenXR, un estándar abierto para diseñar y crear software de realidad virtual (VR) y realidad aumentada (AR) multiplataforma. Ha sido probado con las plataformas de ejecución de SteamVR, Monada y Oculus OpenXR (tanto en escritorio como en dispositivos móviles).
- Ver Plugins de OpenXR.
Godot Oculus Mobile ofrece soporte para el Oculus Quest de Meta.
- Nota: Este complemento ha sido declarado obsoleto a partir de Godot 3.4. Recomendamos migrar al complemento Godot OpenXR en su lugar.
Godot OpenVR (no confundir con OpenXR) es compatible con el SDK OpenVR utilizado por Steam.
Godot Oculus admite el SDK de Oculus (solo para cascos de escritorio).
- Nota: Este complemento ha sido declarado obsoleto a partir de Godot 3.4. Recomendamos migrar al complemento Godot OpenXR en su lugar.
Godot OpenHMD admite OpenHMD, una API y controladores de código abierto para cascos de realidad virtual.

Estos plugins pueden ser descargados de GitHub o de la Biblioteca de Recursos de Godot.

Además de los plugins, hay varias demostraciones oficiales.

Godot Oculus Demo.
Godot OpenVR FPS (el tutorial para este proyecto se encuentra en Tutorial VR para principiantes parte 1).
Godot XR tools, que muestra implementaciones de características de VR como movimiento y recoger objetos.

Otras cosas a considerar¶

Hay algunos otros temas que necesitamos tocar brevemente en este manual que son importantes de conocer.

Los primeros son nuestras unidades. En los juegos 3D normales no tienes que pensar mucho en las unidades. Siempre y cuando todo esté a la misma escala, una caja con el tamaño de 1 unidad por 1 unidad por 1 unidad puede ser de cualquier tamaño, desde un cubo que puedes tener en la mano hasta algo del tamaño de un edificio. En AR y VR esto cambia porque las cosas en su mundo virtual están mapeadas a las cosas en el mundo real. Si das un paso hacia adelante en el mundo real, pero sólo te mueves 1 cm hacia adelante en tu mundo virtual, tienes un problema. Lo mismo ocurre con la posición de tus controles, si no aparecen en el espacio relativo correcto, esto rompe la inmersión para el jugador. La mayoría de las plataformas de VR, incluyendo nuestro servidor AR/VR, asumen que 1 unidad = 1 metro. Sin embargo, el servidor AR/VR tiene una propiedad que por conveniencia también está expuesta en el nodo ARVROrigin llamado world scale (escala del mundo). Por ejemplo, si lo establecemos en un valor de 10, cambia nuestro sistema de coordenadas de modo que 10 unidades = 1 metro.

El rendimiento es otra cosa que debe ser considerada cuidadosamente. Especialmente la RV grava tu juego mucho más de lo que la mayoría de la gente se da cuenta. Para la RV móvil, tienes que ser extra cuidadoso aquí, pero incluso para los juegos de escritorio, hay tres factores que hacen la vida extra difícil:

Estáis haciendo una estereoscopía, dos por el precio de uno. Aunque no exactamente doblando la carga de trabajo y con cosas en la tubería como el apoyo a la nueva extensión MultiView OpenGL en mente, todavía hay una carga de trabajo extra en la prestación de imágenes para ambos ojos
Un juego normal funcionará aceptablemente con 30fps y lo ideal es que funcione con 60fps. Eso te da un gran rango para jugar entre el hardware de gama baja y el de gama alta. Sin embargo, para cualquier aplicación HMD de RA o RV, 60fps es el mínimo absoluto y deberías apuntar a que tus juegos funcionen a un nivel estable de 90fps para asegurarte de que tus usuarios no se mareen de inmediato.
El alto FOV y el efecto de distorsión de la lente relacionado requieren muchas experiencias de RV para rendir al doble de la resolución. Sí, un VIVE sólo puede tener una resolución de 1080x1200 por ojo, por lo que estamos renderizando cada ojo a 2160x2400. Esto es menos problemático para la mayoría de las aplicaciones de RA.

En general, la carga de trabajo de tu GPU en comparación con un juego 3D normal es bastante más alta. Mientras que hay cosas en proceso de mejora, como la multivisión y el renderizado fov, no todos los dispositivos los soportan. Por eso se ven muchos juegos de RV con un estilo más artístico y si prestas mucha atención a los juegos de RV que buscan el realismo, probablemente notarás que son un poco más conservadores en los efectos o que utilizan algún buen truco óptico antiguo.