Abécédaire AR/VR¶

Ce tutoriel vous donne un tremplin vers le monde de la AR et de la VR dans le moteur de jeu Godot.

Une nouvelle architecture a été introduite dans Godot 3, le serveur AR/VR. En plus de cette architecture, des implémentations spécifiques sont disponibles sous forme d'interfaces, dont la plupart sont des plugins basés sur GDNative. Ce tutoriel se concentre uniquement sur les éléments fondamentaux abstraits de l'architecture de base. Cette architecture possède suffisamment de fonctionnalités pour vous permettre de créer une expérience de VR complète qui peut ensuite être déployée pour différentes interfaces. Cependant, chaque plateforme possède souvent des caractéristiques uniques qui sont impossibles à abstraire. Ces caractéristiques seront documentées sur les interfaces pertinentes et n'entrent pas dans le cadre de ce guide.

Serveur AR/VR¶

Au démarrage de Godot, chaque interface disponible se fera connaître du serveur AR/VR. Les interfaces GDNatives sont configurées comme des singletons ; tant qu'elles sont ajoutées à la liste des singletons GDNatives dans votre projet, elles se feront connaître du serveur.

Vous pouvez utiliser la fonction get_interfaces() pour obtenir une liste des interfaces disponibles, mais pour ce tutoriel, nous allons utiliser la fonction interface VR mobile native dans nos exemples. Cette interface est une implémentation simple qui utilise les capteurs 3DOF de votre téléphone pour l'orientation et produit une image stéréoscopique sur l'écran. Il est également disponible dans le noyau Godot et les sorties à afficher sur le bureau, ce qui le rend idéal pour le prototypage ou un tutoriel comme celui-ci.

Pour activer une interface, vous devez exécuter le code suivant :

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;
}

Ce code trouve l'interface que nous souhaitons utiliser, l'initialise et, si cela réussit, lie le viewport principal à l'interface. Cette dernière étape donne un certain contrôle sur le viewport de l'interface, qui permet automatiquement des choses comme le rendu stéréoscopique sur le viewport.

Pour notre interface VR mobile, et toute interface où l'entrée principale est directement affichée à l'écran, le viewport principal doit être la fenêtre où arvr est réglé sur true. Mais pour les interfaces qui rendent sur un périphérique externe, vous pouvez utiliser un le viewport secondair. Dans ce dernier cas, une fenêtre qui affiche sa sortie à l'écran montrera une version non déformée de l'œil gauche, tout en montrant la sortie stéréoscopique entièrement traitée sur l'appareil.

Enfin, vous ne devez initialiser une interface qu'une seule fois ; la commutation de scènes et la réinitialisation des interfaces ne feront qu'introduire beaucoup de surcharge. Si vous souhaitez désactiver temporairement le casque, désactivez simplement la fenêtre ou définissez arvr sur false dans la fenêtre. Cependant, dans la plupart des scénarios, vous ne désactiveriez pas le casque une fois en VR, cela peut être déconcertant pour le joueur.

Nouveaux nœuds AR/VR¶

Trois nouveaux types de nœuds ont été ajoutés pour prendre en charge la AR et la VR dans Godot et un type de nœud supplémentaire spécialement pour la AR. Ceux-ci sont :

ARVROrigin - notre point d'origine dans le monde
ARVRCamera - une sous-classe spéciale de la caméra, qui est suivie de manière positionnelle
ARVRController - une nouvelle classe spatiale, qui suit la location d'un contrôleur
ARVRAnchor - un point d'ancrage pour la mise en œuvre d'un système de AR qui permet de cartographier un lieu du monde réel dans votre monde virtuel

Les deux premiers doivent exister dans votre scène pour que la AR/VR fonctionne et ce tutoriel se concentre uniquement sur eux.

ARVROrigin est un nœud important, vous devez en avoir un et un seul quelque part dans votre scène. Ce nœud cartographie le centre de votre espace de suivi du monde réel à un endroit de votre monde virtuel. Tout le reste est suivi en fonction de ce point. L'endroit où se trouve exactement ce point diffère d'une implémentation à l'autre, mais le meilleur exemple pour comprendre le fonctionnement de ce nœud est de jeter un œil à l'échelle d'une pièce. Bien que nous disposions de fonctions permettant d'ajuster le point pour le centrer sur le joueur par défaut, le point d'origine sera l'emplacement central de la pièce dans laquelle vous vous trouvez. Lorsque vous vous déplacez physiquement dans la pièce, l'emplacement du HMD est suivi par rapport à cette position centrale et le suivi se fait en miroir dans le monde virtuel.

Pour simplifier les choses, lorsque vous vous déplacez physiquement dans votre pièce, le point d'origine de l'ARVR reste où il est, la position de la caméra et des contrôleurs sera ajustée en fonction de vos mouvements. Lorsque vous vous déplacez dans le monde virtuel, que ce soit par l'intermédiaire d'une entrée de contrôleur ou lorsque vous mettez en place un système de téléportation, c'est la position du point d'origine que vous devrez ajuster.

ARVRCamera est le deuxième nœud qui doit toujours faire partie de votre scène et il doit toujours être un nœud enfant de votre nœud origin. C'est une sous-classe de la caméra normale de Godot. Cependant, sa position est automatiquement mise à jour à chaque trame en fonction de l'orientation et de la position physique du HMD. De plus, en raison de la précision requise pour le rendu vers un HMD ou le rendu d'une superposition AR sur une caméra du monde réel, la plupart des propriétés standard des caméras sont ignorées. Les seules propriétés de la caméra qui sont utilisées sont les réglages du plan proche et lointain. Le FOV, le rapport hauteur/largeur et le mode de projection sont tous ignorés.

Notez que, pour notre implémentation native de la VR mobile, il n'y a pas de suivi de position, seulement l'orientation du téléphone et par extension, le HMD est suivi. Cette implémentation place artificiellement la caméra à une hauteur (Y) de 1,85.

Conclusion : votre configuration minimale dans votre scène pour faire fonctionner l'AR ou la VR devrait ressembler à ceci :

Et c'est tout ce dont vous avez besoin pour commencer à utiliser l'interface mobile native. Bien sûr, vous devez ajouter quelque chose de plus dans votre scène, pour qu'il y ait quelque chose à voir, mais après cela, vous pouvez exporter le jeu vers le téléphone de votre choix, le faire apparaître dans une visionneuse et c'est parti.

Plugins et ressources officiels¶

Comme mentionné précédemment, Godot ne prend pas en charge les différents SDK VR et AR de base, vous avez besoin d'un plugin pour le SDK spécifique que vous souhaitez utiliser. Il existe plusieurs plugins officiels disponibles dans le Répertoire GodotVR.

Godot OpenXR : Il s'agit du plugin XR officiel depuis Godot 3.4. Il prend en charge OpenXR, une norme ouverte pour la conception et la construction de logiciels VR et AR multiplateformes. Testé avec les runtimes SteamVR, Monada et Oculus OpenXR (bureau et mobile).
- Voir Plugin OpenXR.
Godot Oculus Mobile fournit un support pour le Meta Quest.
- Note : Ce plugin a été déprécié à partir de Godot 3.4. Nous recommandons de migrer vers le plugin Godot OpenXR à la place.
Godot OpenVR (à ne pas confondre avec OpenXR) supporte le SDK OpenVR utilisé par Steam.
Godot Oculus prend en charge le kit de développement Oculus (casques pour ordinateur de bureau seulement).
- Note : Ce plugin a été déprécié à partir de Godot 3.4. Nous recommandons de migrer vers le plugin Godot OpenXR à la place.
Godot OpenHMD supporte OpenHMD, une API open source et des pilotes pour les casques.

Ces plugins peuvent être téléchargés à partir de GitHub ou de Godot Asset Library.

En plus des plugins, il existe plusieurs démos officielles.

Démo Godot Oculus.
Godot OpenVR FPS (le tutoriel pour ce projet est Tutoriel pour commencer en VR partie 1).
Godot XR tools, qui montre des implémentations pour des fonctionnalités de VR telles que le mouvement et la ramassage d'objets.

Autres éléments à prendre en considération¶

Il y a quelques autres sujets qu'il est important de connaître et que nous devons aborder brièvement dans cet abécédaire.

Les premiers sont nos unités. Dans les jeux 3D normaux, il n'est pas nécessaire de penser beaucoup aux unités. Tant que tout est à la même échelle, une boîte de la taille d'une unité par une unité par une unité peut avoir n'importe quelle taille, d'un cube que vous pouvez tenir dans votre main à quelque chose de la taille d'un bâtiment. Dans la AR et la VR, cela change parce que les choses de votre monde virtuel sont mises en correspondance avec les choses du monde réel. Si vous avancez d'un mètre dans le monde réel, mais que vous n'avancez que d'un centimètre dans votre monde virtuel, vous avez un problème. Il en va de même pour la position de vos contrôleurs ; s'ils n'apparaissent pas dans le bon espace relatif, cela brise l'immersion pour le joueur. La plupart des plateformes de VR, y compris notre serveur de VR/AR, supposent qu'une unité = un mètre. Le serveur AR/VR a cependant une propriété qui, par commodité, est également exposée sur le nœud ARVROrigin appelé échelle mondiale. Par exemple, en réglant cette valeur sur 10, nous modifions notre système de coordonnées de sorte que 10 unités = 1 mètre.

La performance est une autre chose qui doit être soigneusement prise en compte. La VR, en particulier, taxe votre jeu bien plus que la plupart des gens ne le pensent. Pour la VR mobile, il faut être très prudent, mais même pour les jeux de bureau, il y a trois facteurs qui rendent la vie très difficile :

Vous rendez de façon stéréoscopique, deux pour le prix d'un. Bien que la charge de travail ne soit pas exactement doublée, et compte tenu de certaines choses en cours d'élaboration comme la prise en charge de la nouvelle extension OpenGL MultiView, le rendu des images pour les deux yeux représente tout de même une charge de travail supplémentaire
Un jeu normal se fonctionne à 30fps et, idéalement, à 60 fps. Cela vous donne une grande marge de manœuvre entre le matériel bas de gamme et le matériel haut de gamme. Cependant, pour toute application HMD d'AR ou de VR, 60fps est le minimum absolu et vous devez viser à ce que vos jeux fonctionne à 90fps stable afin de vous assurer que vos utilisateurs ne souffrent pas du mal des transports dès le début.
Le FOV élevé, liés à l’effet de distorsion des lentilles exigent de la part de nombreuses expériences VR de rendre au double de la résolution. Oui, un VIVE ne peut avoir qu'une résolution de 1080x1200 par œil, mais donc nous rendons les deux yeux à 2160x2400. Ce problème est moins important pour la plupart des applications AR.

Dans l'ensemble, la charge de travail de votre GPU est bien plus importante que celle d'un jeu 3D normal. Bien que des améliorations soient en cours, comme le MultiView et le rendu fovéal, elles ne sont pas prises en charge par tous les appareils. C'est pourquoi vous voyez beaucoup de jeux de VR qui utilisent un style plus artistique et si vous faites attention aux jeux de VR qui vont dans le sens du réalisme, vous remarquerez probablement qu'ils sont un peu plus conservateurs sur les effets ou qu'ils utilisent une bonne vieille astuce optique.