Le 16/07/2014 à 12h 25

Vipear a écrit :

Merci infiniment pour les explications ! " />

Même si je trouve cela bizarre que le rendu doit être fait par le casque, une simple duplication de l’écran vers le casque aurait été d’après moi suffisant, c’est gâcher de la ressource matériel pour rien d’après moi, a moins de n’avoir rien compris.


J’ai peut-être mal expliqué cette partie mais le rendu n’est pas fait par le casque.
J’en parlais car cela implique des contraintes au niveau des différents moteurs de jeu existants (certains sont partenaires avec Oculus), et que cela renforce encore plus la nécessité d’avoir le minimum de latence au niveau matériel pour que cela soit viable.

Le 16/07/2014 à 11h 44

Vipear a écrit :

Où se cache le poteau rose ? Dites moi car je ne vois pas comment ça peut prendre autant de temps quand même.


Je te conseille de lire les multiples explications faites par John Carmack, celle-ci par exemple :http://www.altdev.co/2013/02/22/latency-mitigation-strategies/

Vu que le post est un peu long, pour résumer il est très compliqué de créer une simulation immersive et qui ne donne pas la nausée aux ³⁄₄ des utilisateurs au bout de 10mn, principalement à cause de la latence non seulement des capteurs, mais aussi de l’affichage.

En gros pour que système soit considéré comme réactif mais avec une latence perceptible, il faut un délai total de moins de 50ms entre le moment où tu bouges ta tête et où l’affichage est actualisé. Pour que le système soit réactif avec une latence peu perceptible (= acceptable = ce que oculus cherche à faire), il faut que le délai soit de moins de 20ms.

Ce n’est pas un délai simple à atteindre pour plusieurs raison :

• Les capteurs doivent être très réactifs sans pour autant avoir trop de bruit (sinon il y aura des artefacts)
  


• Il n’est pas possible de prendre n’importe quels écrans car par exemple les LCD ont souvent un phénomène de ghosting où l’image resterait affichée trop longtemps (plusieurs dizaines de ms), contrairement à l’OLED ou on est dans l’ordre de la milliseconde
  


• Il faut prendre en compte la synchro verticale (sinon le bas de l’écran n’affichera pas forcément les mêmes infos que le haut)
  


• Il faut que le nombre de FPS soit suffisamment élevé (60fps en constant, ce qui est difficile à obtenir avec la plupart des jeux, surtout à des résolutions assez élevées comme celles qui seront demandées par le rift)
  


• Le rendu de la scène 3D doit être fait deux fois dans le jeu (une fois par oeil), donc cela demandera davantage d’optimisations côté matériel
  


• Il faut sur ces rendus appliquer un shader qui déforme le tout comme sur ce screenshot :http://apixelatedview.com/wordpress/wp-content/uploads/2014/06/omni-rift.jpg
  


• etc… (dans ses posts Carmack explique plus en détail les différents éléments augmentant la latence)
  
  En plus de la latence et du temps de rendu il y a également d’autres contraintes à prendre en compte :
  


• Certains capteurs comme ceux de position ne peuvent pour l’instant pas être mis à l’intérieur du casque, c’est pour cette raison que dans la deuxième version du kit de développement ils ont rajouté des LEDs infrarouges et une webcam.
  


• Le phénomène de “drift” des capteurs : ceux-ci n’étant pas précis à 100%, il est possible qu’après un certain temps d’utilisation il y ait une dérive et que par exemple ce que le casque considère que tu regardes droit devant alors que ce n’est plus le cas. Les LEDs infrarouges et le webcam ajoutés dans la dernière version du kit de développement aident à corriger cela il me semble.
  


• La persistance des images au niveau du cerveau : la première version du rift pouvait donnée une sensation de nausée à cause de cette persistance. Depuis ils utilisent une nouvelle technique qui consiste à ne plus constamment afficher les images sur l’écran. En gros ils les affichent pendant un temps très court le temps que le cerveau les prenne en compte, puis coupent tout jusqu’au prochain rafraîchissement.