La première fois que j’ai déployé un build VR sur un casque, je n’avais aucune idée de la quantité de travail qui se passe en dehors du casque. On passe peut-être un cinquième de son temps dans les lunettes et le reste à se battre avec les mappings d’entrée, l’échelle de rendu et les conflits de versions de SDK. Voici donc le guide que j’aurais aimé qu’on me donne : comment les pièces s’assemblent, quoi installer, et comment faire tourner un cube qu’on peut attraper sur du vrai matériel avant la fin de l’après-midi.
Ce dont vous avez réellement besoin
Il vous faut trois choses. Un casque, un moteur, et un runtime qui fait la traduction entre les deux. C’est cette dernière partie que les débutants sautent avant de se demander pourquoi rien ne fonctionne. Le runtime est la couche qui possède l’affichage, le tracking et les contrôleurs, et votre moteur lui parle à travers une API.
Côté matériel, presque n’importe quel casque autonome moderne fera l’affaire. Un Meta Quest 2 ou 3 est le point d’entrée le moins cher et sert à la fois de casque relié au PC et de cible Android autonome. Si vous avez un PC de jeu, un Valve Index ou n’importe quel casque Windows Mixed Reality fonctionne aussi. Achetez d’occasion si vous le pouvez. Le matériel évolue vite et vous n’avez pas besoin de la dernière dalle pour apprendre.
OpenXR est ce qu’il faut apprendre, pas un SDK propriétaire
Pendant des années, chaque fabricant de casque livrait son propre SDK, et porter une application d’un appareil à un autre signifiait réécrire son code d’entrée et de rendu. OpenXR a réglé ça. C’est un standard ouvert de Khronos, le même groupe derrière Vulkan, et il vous donne une seule API qui cible le Quest, SteamVR, Windows Mixed Reality et la plupart des appareils à venir.
Mon conseil ferme : développez sur OpenXR dès le premier jour. Unity et Unreal le supportent tous deux comme un plugin de première classe. Vous irez parfois chercher une extension propriétaire pour le suivi des mains ou le passthrough, mais la boucle de base des poses, des frames et des entrées reste portable. J’ai déplacé des projets du Quest vers le PCVR presque sans changer une ligne grâce à ça, et la seule fois où j’ai bâti sur un SDK propriétaire, je l’ai payé plus tard.
Unity ou Unreal
C’est la question que tout le monde pose et la réponse honnête est que les deux conviennent. Voici comment je tranche.
- Choisissez Unity si vous voulez une itération plus rapide, un modèle de script plus doux en C#, et le plus large vivier de tutoriels et d’assets VR. Le XR Interaction Toolkit vous donne la préhension, la téléportation et l’interaction avec les interfaces sans rien coder. La plupart des projets VR indé et entreprise sortent sur Unity.
- Choisissez Unreal s’il vous faut un rendu visuel de premier ordre, que vous êtes à l’aise avec le C++ ou les Blueprints, et que votre cible est un PC puissant ou un casque autonome haut de gamme. Le rendu d’Unreal est superbe mais vous lutterez davantage pour tenir le framerate sur du matériel mobile comme le Quest.
Je prends Unity pour la plupart de mes prototypes parce que je peux changer une valeur, lancer le mode play, et tester dans le casque en quelques secondes. Pour une pièce PCVR cinématique et lourde visuellement, j’envisagerais Unreal. Aucun des deux choix n’est mauvais, alors ne passez pas une semaine à hésiter.
Configurer un projet Unity pour la VR
Voici le chemin qui fonctionne de manière fiable à l’heure où j’écris. Créez un nouveau projet avec le template 3D core. Ouvrez le gestionnaire de paquets et installez le package XR Plugin Management, puis le OpenXR Plugin, puis le XR Interaction Toolkit. Dans les paramètres du projet sous XR Plugin Management, activez OpenXR pour votre plateforme cible et ajoutez un profil d’interaction qui correspond à vos contrôleurs, comme le profil Oculus Touch ou le profil des contrôleurs Index.
Pour une cible Quest, passez la plateforme de build sur Android et réglez la compression de texture sur ASTC. Pour le PCVR vous restez sur la plateforme Windows. C’est franchement l’essentiel de la configuration. Les profils d’interaction sont la partie que les gens oublient, et sans eux vos contrôleurs ne rapportent aucune entrée du tout.
Votre premier objet attrapable
Le XR Interaction Toolkit fait le gros du travail, mais ça aide de voir à quoi ressemble une petite interaction personnalisée en code. Voici un script simple qui ramène un objet à sa position de départ quand on le lâche, pratique pour les outils que vous ne voulez pas voir disparaître dans le vide.
using UnityEngine;
using UnityEngine.XR.Interaction.Toolkit;
[RequireComponent(typeof(XRGrabInteractable))]
public class ReturnToHolster : MonoBehaviour
{
Vector3 startPos;
Quaternion startRot;
XRGrabInteractable grab;
void Awake()
{
startPos = transform.position;
startRot = transform.rotation;
grab = GetComponent<XRGrabInteractable>();
grab.selectExited.AddListener(OnReleased);
}
void OnReleased(SelectExitEventArgs args)
{
// Retour a la base apres un court delai pour garder le lance physique
Invoke(nameof(ResetTransform), 1.5f);
}
void ResetTransform()
{
var rb = GetComponent<Rigidbody>();
if (rb != null) { rb.velocity = Vector3.zero; rb.angularVelocity = Vector3.zero; }
transform.SetPositionAndRotation(startPos, startRot);
}
}Posez ça sur un mesh avec un collider et un Rigidbody, ajoutez un rig XR Origin à la scène, et vous avez quelque chose que vous pouvez attraper et lancer. Voir ses propres mains déplacer un vrai objet dans l’espace 3D est le moment où la VR fait tilt pour la plupart des gens, alors arrivez-y le plus vite possible.
La boucle de rendu n’est pas comme sur écran plat
La VR rend la scène deux fois, une par œil, à chaque frame, et elle doit tenir un budget de temps strict. Sur un Quest vous visez 72 ou 90 images par seconde, et rater cette cible n’est pas seulement laid, ça donne la nausée. Ça change la façon de penser la performance. Les draw calls, l’overdraw et la complexité des shaders comptent bien plus que sur un moniteur où une frame perdue est une gêne mineure.
Deux techniques vous sauvent ici. Le fixed foveated rendering baisse la résolution sur les bords de la lentille où l’œil ne voit de toute façon pas les détails. Le single-pass instanced rendering soumet la géométrie une seule fois pour les deux yeux au lieu de deux. Activez les deux tôt. J’ai sauvé des projets qui saccadaient à 50 images juste en activant ça et en coupant quelques lumières temps réel.
Tester sur le matériel tôt et souvent
L’aperçu de l’éditeur vous ment. L’échelle se ressent différemment dans un vrai casque, un mouvement fluide sur un aperçu plat peut être nauséeux dans les lunettes, et un texte lisible sur votre moniteur devient illisible à travers les lentilles. Buildez sur l’appareil constamment. Avec un Quest vous pouvez utiliser le hub développeur Oculus ou simplement sideloader en USB, et en PCVR vous pouvez jouer directement dans un casque relié depuis l’éditeur.
Le confort est une discipline à part entière, et c’est là que la plupart des premiers projets VR échouent. J’en ai fait un article séparé parce que ça mérite de la place. Si vous avez dépassé l’étape de la configuration, lisez les principes d’UX en VR avant de concevoir le moindre système de déplacement, parce que vos choix de locomotion et d’interaction décideront si les gens supportent ce que vous avez construit.
Un premier projet réaliste
N’essayez pas encore de faire un jeu. Faites une pièce. Posez quelques objets attrapables sur une table, ajoutez un bouton au mur qui allume une lumière, et faites un système de téléportation simple pour vous déplacer. Cette petite scène met en jeu le rendu, les entrées, l’interaction et la locomotion, qui sont les quatre piliers de toute application VR. Une fois que cette pièce se sent bien dans le casque, vous en comprenez assez pour commencer quelque chose de vrai.
Le développement VR récompense la patience et punit les raccourcis, mais la récompense n’a rien à voir avec le travail sur écran plat. La première fois qu’un testeur tend la main pour toucher quelque chose qui n’existe pas et sursaute, vous comprendrez pourquoi les gens continuent de créer pour ce médium. Commencez petit, testez sur du vrai matériel, et respectez le confort du joueur dès le début.
