DivideConcept.net

le blog de divide.

Oculus Rift : quelques idées d’intégrations

Oculus Rift, le projet de Palmer Luckey qui fait le buzz ces derniers jours, propose de renouer avec la réalité virtuelle, depuis trop longtemps mise de coté !

YouTube Preview Image

Grâce à la miniaturisation des écrans (merci les smartphones), les lunettes VR reviennent à la mode en 2012 (notamment via Sony, Google et Sensics). Si Oculus Rift est le projet le plus prometteur de tous, notamment grâce à son large champs de vision et son coup de production très faible (300$), ce n’est pas encore pour autant un système parfait comme le raconte en détail LeGreg sur le forum wefrag, qui a pu tester un prototype à la QuakeCon (veinard !).
Pourtant on en a jamais été aussi proche, et la version finale de ce système arrivera courant 2013 avec une meilleure résolution et un form-factor plus adapté. En attendant, voici quelques pistes de réflexion pour tenter de résoudre quelques problèmes autour de ce projet :

Réduire la latence sur les moteurs de dernière génération

Un point critique pour éviter la nausée dans ce genre de système est de réduire au maximum le temps de réponse entre les mouvements de tête du joueur et l’image affichée. Si ça passe certainement très bien pour le moteur de Doom 3, qui a été développé en 2004 et donc tourne maintenant sans problème à 120fps, je doute qu’il en sera de même sur le CryEngine 3 et l’Unreal Engine 4, pourtant les mieux à même de nous immerger dans un univers virtuel.
Comment alors pourrait-on artificiellement réduire leur latence malgrès tout ?

shift

Les mouvements de rotation de la tête étant ceux qui causent le plus de changement visuel, un thread asynchrone à 120fps pourrait s’occuper d’afficher en permanence le dernier buffer rendu (sans le HUD), il décalerait ce dernier buffer rendu en fonction des dernières informations de rotation qui lui sont parvenus et comblerait les trous periphériques avec les couleurs les plus proches. L’oeil ayant une vision périphérique de moindre accuité, et ce vide ne durant au pire qu’un vingtième de seconde avant qu’un nouveau rendu mieux positionné arrive, l’illusion passerait inaperçue.

Intégrer un rendu Oculus Rift sans recoder les moteurs

Pour que la vision stéréoscopique d’Oculus Rift puisse fonctionner, elle a besoin d’un rendu très particulier: il s’agit d’un rendu side-by-side dont la géométrie a été déformée pour correspondre aux optiques des lunettes.
Cela nécessite à priori un recodage partiel de tous les moteurs censés devoir supporter le système.

On pourrait toutefois imaginer un détournement des systèmes stéréoscopiques pré-existants:
3D Vision et iZ3D (qui vient malheureusement de cesser son activité) émulent un support stéréoscopique sur un nombre très important de jeux; et des logiciels comme FRAPS sont capables de capturer ces sorties stéréoscopique, il est donc apparement facile d’accéder aux buffers stéréo générés. On pourrait dès lors imaginer un module externe qui capturerait ces buffers stéréos, les déformeraient pour correspondre aux optiques d’Oculus Rift, et enverrait la vue side-by-side correspondante sur une autre sortie écran ou seraient branchés les lunettes. Comme il ne s’agit pas d’enregistrer les images sur le disque dur (contrairement à FRAPS), cela n’incluerait pas nécessairement une réduction du nombre de FPS.

Intégrer un tracking 4 axes sans recoder les moteurs

Pour certains jeux de courses, de simulateurs de vol et pour des FPS comme Arma 2, la solution est toute trouvée puisqu’il existe déjà un protocole standard pour gérer 3 à 6 axes de libertés : Track-IR, et son pendant libre Free Track.
Ces protocoles permettent de gérer indépendament la vue et l’axe de visée, c’est un cas idéal pour de la réalité virtuelle.
Ces jeux restent hélas une exception, et il faut bien trouver une solution pour l’ensemble des autres jeux (ne serait-ce que pour pouvoir en profiter dans Crysis, Battlefield et Skyrim !).

Pour les rotations de tête, la solution est toute trouvée: pour peu qu’on accepte de viser les ennemis en tournant sa tête, il suffit d’émuler des mouvements de souris via une calibration préalable (qui pourrait facilement être établie par les joueurs en capturant les informations souris pour une rotation à 360 degrées horizontal, 180 degrées vertical). On aurait donc 2 axes de libertés en rotations sur tous les jeux, pas si mal !

Pour les translation de tête et les déplacements, il faut faire intervenir un périphérique supplémentaire : les accéléromètres sont trop imprécis pour retranscrire la position (double intégration sur un signal avec du bruit, impossible d’avoir un résultat fiable). Kinect ayant trop de latence (300ms+, n’oublions pas les phénomènes de nausée en réalité virtuelle) et la Wiimote ne gérant pas les 3 axes spatiaux, le PS Move semble la solution la plus adaptée: 130ms de latence et un positionnement précis sur les 3 axes spatiaux. Couplé au casque, on aurait ainsi une information précise et rapide de la position de la tête.
Maintenant comment intégrer ça au gameplay ?

D’une manière similaire aux rotations, on pourrait émuler des mouvements joystick: ceux-ci permettent différents niveaux de vitesse (contrairement aux flèches d’un clavier), on pourrait donc calibrer le jeu (en regardant le sol) sur des déplacements de 1m, en capturant les entrées joystick.
Comme le joueur moyen ne dispose pas chez lui d’une sphère géante ou d’un tapis roulant high-tech, l’émulateur pourrait être paramétré de la manière suivante:
On définit un point central dans l’espace (position de repos du joueur), et quand le joueur bouge sa tête dans un rayon de 20cm autour de ce point cela serait traduit en une translation simple (via des signaux joystick donc). Si le joueur place sa tête au dela de ce rayon, il s’agirait d’un ordre de déplacement (signal joystick continue) et dès que le joueur veut s’arrêter, il revient autour du point central.
Bien sur, seul les 2 axes du plan horizontal peuvent ainsi être retranscrit de manière précise. On pourrait néanmoins rajouter les positions d’accroupissement et de saut en définissant des seuils de hauteur (puisqu’après tout, on dispose des 3 informations de position, autant en profiter !).

Le reste des controles (tir, changements d’armes, etc) seraient assurés par un pad XBox. Cela permettrait par la même occasion de court circuiter si nécessaire les opérations de déplacement et rotation si il y a besoin d’une recalibration en cours de jeu.

8 commentaires pour “Oculus Rift : quelques idées d’intégrations”

  1. Darkstryder dit :

    Intéressant. Ton idée pour intégrer Oculus Rift sans rien recoder n’est elle pas en contradiction avec le premier précepte (que j’approuve) de réduire la latence au maximum ?

  2. divide dit :

    Dans l’absolu il y a une certaine contradiction, mais c’est pour explorer a la fois les pistes d’intregation directe quand c’est possible (futurs jeux) et indirectes dans le cas contraire (jeux deja existants qui ne seront jamais recodés).
    Je crains que les discussions en cours avec Epic, Valve, Cryteck et Unity ne débouchent pas immédiatement sur les évolutions nécessaires de leurs moteurs respectifs…

  3. DiNo dit :

    Pour le point 2, un mec est deja en train de modifier un pilote stereoscopique 3D pour inclure la distortion de l’Oculus dans n’importe quel jeu.
    http://www.mtbs3d.com/phpBB/download/file.php?id=1434 (image)

  4. Tuxer dit :

    En vrai, le boulot à faire pour gérer l’aspect stéréoscopique des lunettes est vraiment trivial, c’est un simple pixel/fragment shader de post processing, ce qui s’implémente rapidement (surtout avec les aides qu’il y aura dans le devkit oculus) dans n’importe quel moteur digne de ce nom. Pareil pour l’affichage side-by-side.

    En vrai, c’est pareil pour l’accéléromètre (si je ne me plante pas, il est accompagné d’un magnétomètre, d’ou le 6-axis expliqué dans le kickstarter, ce qui permettrait d’éviter les intégrations, comme tu dis).

    Pour moi, ce qui va rester assez difficile à implémenter, c’est l’aspect 3D du système, dans un grand nombre de moteurs. Il faut faire 2 rendus avec 2 caméras différentes, mais tenter de limiter la perte de puissance. Il faut donc ajouter une passe de rendu (contenant tout le post process, regénération des depth buffers, etc) pour chaque frame, gérer dans sa scène 2 caméras, 2 matrices de projection, etc.

    Ta solution, si je la comprends bien, ne gèrerait pas la 3D?

  5. divide dit :

    Content de voir que l’implémentation pour les jeux déjà existant est effectivement facilement faisable :)
    Le lien viens de quel topic DiNo ?

    Attention aux termes pour les capteurs: le gyroscope sert à détecter les rotations, et dans certains cas ils peuvent être couplés à un magnétomètre comme tu dis. L’accéléromètre sert à mesurer les accélérations dans l’espace; par intégration on peut déduire la vitesse, et par une double intégration la position. Mais avec le manque de précision et le bruit des mesures, on se retrouve avec des positions très peu fiables. Donc il vaut mieux recourir à d’autres sources pour le positionnement spatial.

    Ma solution (théorique) se base sur 3D Vision ou iZ3D au choix, dans le but de récupérer un buffer stéréo (3D). Ces 2 drivers simulent des doubles matrices/buffers et gèrent très bien un grand nombre de jeu, donc autant ne pas perdre de temps à réinventer la roue.

  6. DiNo dit :

    http://www.mtbs3d.com/phpBB/viewtopic.php?f=138&t=14777, attention si tu lis les première pages, le topic date d’avril à la base, pas mal de choses ont changées depuis!

  7. KominAaa dit :

    Ils devraient utiliser un truc avec des champs magnétiques pour la translation comme le Hydra de Razer http://sixense.com/razerhydrapage, ca serait vachement plus précis que des accéléromètres, d’ailleurs un Rift + des Hydra ça doit être le combo ultime pour les FPS (si tant est qu’on puisse avoir des Rift sans câble sans quoi vivre les entortillements…

  8. divide dit :

    Je viens seulement maintenant de voir la Keynote de Carmack (en tout cas la partie VR entre 1h00 et 2h23, qui est super interessante), et il parle justement de ses essais avec TrackIR, Kinect et Sixense Razer Hydra (entre 2h01 et 2h08) :)
    http://www.youtube.com/watch?v=wt-iVFxgFWk

    (Pour l’anecdote à 1h17 il parle des trous noirs entre les départements de Sony, exactement l’experience que j’ai eu entre les VP de Sony Software et Sony Pictures… Zero connection !)

    A voir aussi, la conf avec Carmack et Palmer:
    http://www.youtube.com/watch?v=8gaqQdyfAz8

Laisser un commentaire

Si vous avez un compte sur WeFrag, connectez-vous pour publier un commentaire.

Vous pouvez, entre autres, utiliser les tags XHTML suivant :
<a href="" title="">...</a>,<b>...</b>,<blockquote cite="">...</blockquote>,<code>...</code>,<i>...</i>