Réalité Virtuelle : LE topic (avec un sondage tiens)

[Guig Esprit du Sage]

Pas besoin de s'insuiéter pour une légère latence, le cerveau est capable de s'y adapter en quelques minutes, il y a des tests sur internet que le prouvent, mais faudrait les retrouver.
Les mouvement dans l'espace sont en effet actuellement limités à ceux que permettent une souris normale (pour cause de logiciel). Le problème dans ce domaine est aussi le manque de sensibilité de leur système car ils utilisent un accéléromètre (Hillcrest + freepie), ce qui fait que ça ne capte pas les faibles mouvements.

[Sedjem]

Oui mais non ça a beau être ma fiancée la neuropsy, là tu parle de trucs que tu maitrises pas du tout.

La difficulté de ce genre de dispositif est bien de tromper complétement l'oreille interne.
Inutile de compter sur de supers facultés cérébrales pour corriger le tir.

J'admets que j'emploie des termes médicales un peu à tout va, mais c'est dans le but d'imager afin de mieux me faire comprendre. Et je ne prétend pas maitriser la neurologie.

Cependant, je m'y connais suffisamment pour dire que leurrer l'oreille interne ne te servira à rien et je me demande comment tu pourrais t-y prendre pour leurrer une oreille interne.

L'oreille auditive, l'oreille interne, un oeil ne sont que de simple capteur qui envoient des informations de grandeurs physiques tel qu'une onde sonore, une localisation spatiale ou la lumière; sous forme de signaux nerveux à destination du cerveau. Ils ne font que ça et interviennent dans aucun autre processus hors de ce pourquoi ils ont la charge.
Tout est centralisé au cerveau et tout ce passe dans le cerveau, comme les émotions ou la douleur même si tu la ressent au pied, elle se situe dans le cerveau. Le mal de mer est aussi généré par le cerveau. Donc c'est bien le cerveau qu'il faut leurrer.

D’ailleurs comme exemple, lorsqu'on est soumis à une illusion d'optique, on ne dit pas que ce sont les yeux qui sont leurrés, mais bien le cerveau.

[Erokh]

Un moyen simple d'éviter envie de gerbe, c'est de laisser l'oeil de la personne voir l'extérieur, afin qu'il ait un vrai référentiel, non? Dans ce cas, ne serai-il pas possible de laisser une petite ouverture pour que le cerveau puisse capter des images de l’environnement extérieur et ainsi ne pas se sentir mal? En plus ça permettrait de limiter les possibilités des casse ou quoi (vu qu'on voit rien de l'extérieur, un accident est vite arrivé...).

Ça pose des questions bien sûr, comme l'immersion, la nécessité d'avoir une ouverture d'une certaine taille pour qu'elle soit "vue" par le cerveau, l'utilité du machin ,quand on est en plein jeu, et qu'on ne pense plus qu'à ce qui se passe sur l'écran,... Enfin le mieux reste de réduire la latence au max, mais bon, à défaut, doit y avoir moyen de trouver des solutions.

[LaVaBo]

Un moyen simple d'éviter envie de gerbe, c'est de laisser l'oeil de la personne voir l'extérieur, afin qu'il ait un vrai référentiel, non? Dans ce cas, ne serai-il pas possible de laisser une petite ouverture pour que le cerveau puisse capter des images de l’environnement extérieur et ainsi ne pas se sentir mal? En plus ça permettrait de limiter les possibilités des casse ou quoi (vu qu'on voit rien de l'extérieur, un accident est vite arrivé...).

Ça pose des questions bien sûr, comme l'immersion, la nécessité d'avoir une ouverture d'une certaine taille pour qu'elle soit "vue" par le cerveau, l'utilité du machin ,quand on est en plein jeu, et qu'on ne pense plus qu'à ce qui se passe sur l'écran,... Enfin le mieux reste de réduire la latence au max, mais bon, à défaut, doit y avoir moyen de trouver des solutions.

Je ne pense pas que ça soit une solution. Quelqu'un sujet au mal des transport en voiture voit l'extérieur, et si je ne m'abuse, c'est le décalage entre l'intérieur de la voiture qui ne bouge pas, et l'extérieur qui défile, qui donne la gerbe.

[Sedjem]

J'ai du mal à vous comprendre pourquoi vous faites une fixation sur cette latence, alors que les derniers posts de MrPapillon et Guig Esprit du Sage ; que je remercie en passant pour me soutenir de défendre l'idée de la capacité d'adaptation du cerveau, laissent entrevoir que finalement ce mal de mer ne se manifeste pas si facilement.

Comme Lavabo, je doute de l’efficacité de laisser une ouverture pour voir le monde réel et que surtout, cette solution casserait l'immersion. tu ne serais plus "dans l'image".

Je pense qu'il est plus important de s'inquiéter sur les faibles résolutions des écrans et de la fidélité du head-tracking. Et histoire d'être un pieu chiant, si je ne le suis pas déjà, un head-tracking avec 6 Dof. Les possesseurs de Track-Ir ou Freetrack me comprendront.

[MrPapillon]

- Si on fait une ouverture sur l'extérieur, de la lumière va s'engouffrer dedans et ça risque d'être gênant voire infaisable suivant leur techno. Et de toutes façons ça va à l'encontre du principe du casque VR.
- La latence reste un problème parce que les démos présentées du Rift étaient dans des conditions idéales à chaque fois, soient 60fps constants. J'ai pas envie d'avoir la gerbe dans un jeu parce qu'il y a du streaming à un moment donné qui fait chuter le framerate pendant quelques secondes.
- 6 dof ça suffit pas. Il faut pouvoir positionner avec précision dans l'espace. Le 6 dof te dit juste que tu peux te déplacer sur les 3 axes de translation, mais il n'y a pas d'autres garanties.

[olih]

Je ne pense pas que ça soit une solution. Quelqu'un sujet au mal des transport en voiture voit l'extérieur, et si je ne m'abuse, c'est le décalage entre l'intérieur de la voiture qui ne bouge pas, et l'extérieur qui défile, qui donne la gerbe.

Quand tu as le mal des transport, fixer la route (à l'avant) peu aider.

[Erokh]

- 6 dof ça suffit pas. Il faut pouvoir positionner avec précision dans l'espace. Le 6 dof te dit juste que tu peux te déplacer sur les 3 axes de translation, mais il n'y a pas d'autres garanties.

je comprends pas... 6DOF c'est 6 degrés de liberté, donc 3 axes de translation et 3 axes de rotation. Il est où le problème après pour se positionner dans l'espace à partir de ces 6 données? La précision?

D'ailleurs, je ne suis pas sûr qu'un bon gyroscope ne serait pas suffisant pour un système VR: en quoi le fait d'avancer/reculer la tête apporterait un plus pour un jeu en VR?

Quelqu'un sujet au mal des transport en voiture voit l'extérieur, et si je ne m'abuse, c'est le décalage entre l'intérieur de la voiture qui ne bouge pas, et l'extérieur qui défile, qui donne la gerbe.

Pas vraiment. En fait c'est la différence entre le "non-mouvement" perçu par les yeux et le mouvement perçu par l'oreille interne qui file la gerbe. Quand on roule/conduit, on regarde l'extérieur, donc tes yeux voient le déplacement => pas de problème. Quand tu lis (une carte ou un bouquin ou quoi) dans un voiture, tes yeux et ton cerveau sont si concentrés sur ce que tu lis que le cerveau ne voit pas que l'extérieur bouge. Du coup pour les yeux le monde est fixe, mais pour l'oreille interne ça bouge => gerbe

[Sedjem]

- Si on fait une ouverture sur l'extérieur, de la lumière va s'engouffrer dedans et ça risque d'être gênant voire infaisable suivant leur techno. Et de toutes façons ça va à l'encontre du principe du casque VR.

Oui, pour une fois, je suis complètement d'accords avec toi.

- La latence reste un problème parce que les démos présentées du Rift étaient dans des conditions idéales à chaque fois, soient 60fps constants. J'ai pas envie d'avoir la gerbe dans un jeu parce qu'il y a du streaming à un moment donné qui fait chuter le framerate pendant quelques secondes.

Je commence à me poser la question si tu ne confonds pas la réactivité du système complet de l'action du joueur jusqu'à l'affichage à la rémanence des écrans qui n'est dut qu'à la qualité des écrans choisit pour l'oculus.

Je m'explique :

Lorsque je joue à un simulateur de vol en 3D Vision avec le track-Ir, on peut considérer cet ensemble est très proche de l'oculus.

Et je peux t'assurer qu'il n'y a ni freeze, ni ralentissement ou chute fps même avec des mouvements brusque de la tête ou de la souris indépendamment de ce qu'il y a afficher à l'écran.

Alors, encore une fois, pourquoi il en serait différent pour l'oculus hormis un choix d'écrans qui n'auraient pas suffisamment de réactivité pour cette utilisation ?
Surtout qu'en plus les résolutions de l'oculus sont beaucoup plus faibles que nos écrans 3D.

je comprends pas... 6DOF c'est 6 degrés de liberté, donc 3 axes de translation et 3 axes de rotation. Il est où le problème après pour se positionner dans l'espace à partir de ces 6 données? La précision?

D'ailleurs, je ne suis pas sûr qu'un bon gyroscope ne serait pas suffisant pour un système VR: en quoi le fait d'avancer/reculer la tête apporterait un plus pour un jeu en VR?

Ta signature indique que tu joue à Lock on, je m'etonne que tu pose cette question.
Avancer la tête te permet de t'approcher de tes instruments pour pouvoir les lire plus facilement, un peu comme un zoom.

Le 6 DoF n'est pas nécessaire pour du fps classique, mais serait bien plus confortable pour la cohérence de tes mouvements de tête volontaires ou non, par rapport à l'affichage.

Là, le problème est purement hardware embarqué à l'oculus et je ne sais pas quelle solution ils ont retenus. L'accéléromètre et gyroscope me paraissent la meilleure solution technologique. Mais j'imagine qu'il ne doit pas être simple et couteux d'incorporer cette technologie à l'oculus. Surtout si on veut un 6 DoF. Soit au minimum 3 accéléromètres et 3 gyroscopes. Là, problématique du prix, de la place, du poix, de la qualité des capteurs pour leurs résolutions. Bref, du 6 Dof, c'est pas gagné.

[LaVaBo]

T'es sûr d'être obligé d'avoir un accéléromètre et un gyroscope par axe ? Je pensais qu'il en existait qui géraient les 3 dimensions, mais j'y connais que dalle.

[Sedjem]

Non, tu as raison, je suppose seulement. Mea culpa.
Après un petit tour sur radiospare pour vérifier, tu as tout bon pour les accéléromètres et même les giroscopes. Ils peuvent gérer 3 axes.

Remarque tu fais bien de me corriger, ça relance dans mon petit coeur de geek, un espoir du support natif du 6 DoF.

[weedkiller]

Ca existe depuis quelques temps, les 6DoF en un seul package. Tu peux acheter un modules 9 axes qui fait 1cm par 1cm si tu veux :
http://www.st.com/internet/analog/product/253162.jsp

C'est plus ton alim qui va prendre de la place . (il y a la photo dans le datasheet)

[Sedjem]

Ce serais vraiment l'idéal.

Reste à savoir son prix.

Pour l'alim, l'USB devrait suffire à moins qu'il consomme plus 500 mA. Le gros du travail serait de traduire ce module pour le protocole USB et de faire le driver pour pouvoir l'exploiter par les jeux. Je pense à Freetrack éventuellement si son code est open source.

Sérieusement, s' ils abandonnent le projet, avec tout ce qu'on peut trouver clé en main dans le commerce, envisager de prendre la relève ne me semble pas si fantaisiste que ça.

[MrPapillon]

je comprends pas... 6DOF c'est 6 degrés de liberté, donc 3 axes de translation et 3 axes de rotation. Il est où le problème après pour se positionner dans l'espace à partir de ces 6 données? La précision?

6dof ça veut dire que tu prends les translations sur les 3 axes. Par contre ça te dit juste que ça te donne de la data sur un axe, mais sans en préciser la nature. Là pour le coup c'est du relatif, de l'accélération si tu veux. Le problème c'est qu'on a pas une précision infinie et qu'à force de cumuler des accélérations pour avoir la position dans l'espace relative à la position à t=0, tu vas finir par accumuler des erreurs et au final tu ne sais plus où tu te trouves. Il y a le même problème pour les rotations, mais :
- pour les rotations de gauche à droite, on n'en a pas vraiment besoin pour le gameplay, on peut se contenter d'un peu d'imprécision, c'est pas grave.
- pour les rotations en penchant la tête sur les côtés et en regardant bas/haut, on recorrige avec une donnée supplémentaire : la gravité.

Sinon rajouter un 6dof ne sert à rien puisqu'il y en aura déjà un dessus. En plus il faut en prendre un avec une bonne latence et bonne précision de toutes façons.

Je commence à me poser la question si tu ne confonds pas la réactivité du système complet de l'action du joueur jusqu'à l'affichage à la rémanence des écrans qui n'est dut qu'à la qualité des écrans choisit pour l'oculus.

Non je n'ai jamais parlé de rémanence et je ne vois pas ce qui a pu te faire penser à ça.

Lorsque je joue à un simulateur de vol en 3D Vision avec le track-Ir, on peut considérer cet ensemble est très proche de l'oculus.
Et je peux t'assurer qu'il n'y a ni freeze, ni ralentissement ou chute fps même avec des mouvements brusque de la tête ou de la souris indépendamment de ce qu'il y a afficher à l'écran.

Comme j'ai dit avant, si tu as une machine qui fait tourner tous les jeux à >= 60fps constants 100% du temps avec de l'AA de maouf, y compris quand tu te trouves dans des zones de jeu qui streament de la data du disque dur, des zones chargées en mobs, etc... Si en plus ta machine est si puissante qu'elle arrive à réduire la latence à < 5ms pour tous ces jeux, par je ne sais quelle sorcellerie, ça sera parfait. Si t'as tout ça, alors c'est bon pour toi. Je parle pour les autres qui n'ont pas ce matos. La différence entre le Rift et ton système track IR + 3D Vision est que ça ne tape pas directement dans ton oreille interne ou ton appréciation du réalisme du monde qui t'entoure, sinon j'en aurais rien eu à foutre de la latence.
Je rappelle quand même que Carmack avait dit que pour avoir une vision réaliste du monde aperçu, il faut une latence de bout en bout de <= 20ms. et qu'actuellement avec son Doom3 super optimisé latence (qui tourne à 60fps constants bien entendu, mais là on en est plus à ce niveau), on a au total 50/60ms de latence totale.

[Sedjem]

6dof ça veut dire que tu prends les translations sur les 3 axes. Par contre ça te dit juste que ça te donne de la data sur un axe, mais sans en préciser la nature. Là pour le coup c'est du relatif, de l'accélération si tu veux. Le problème c'est qu'on a pas une précision infinie et qu'à force de cumuler des accélérations pour avoir la position dans l'espace relative à la position à t=0, tu vas finir par accumuler des erreurs et au final tu ne sais plus où tu te trouves. Il y a le même problème pour les rotations, mais :
- pour les rotations de gauche à droite, on n'en a pas vraiment besoin pour le gameplay, on peut se contenter d'un peu d'imprécision, c'est pas grave.
- pour les rotations en penchant la tête sur les côtés et en regardant bas/haut, on recorrige avec une donnée supplémentaire : la gravité.

Sinon rajouter un 6dof ne sert à rien puisqu'il y en aura déjà un dessus. En plus il faut en prendre un avec une bonne latence et bonne précision de toutes façons.

Tout système de head-tracking à un décalage à cause effectivement des erreurs de capteurs, même le Track-Ir.

Cependant, il suffit de se mettre bien droit et d'appuyer sur une touche qui recalibrera en position bien droite la situation virtuelle. Ca se fait en une fraction de seconde et c'est assez intuitif. Il y a de grandes chances que ce soit pareil pour le Rift car je ne vois pas comment faire autrement.

Non je n'ai jamais parlé de rémanence et je ne vois pas ce qui a pu te faire penser à ça.

C'est du fait de votre fixation sur cette satané latence dont je n'éprouve pas, mais ça y est, j'ai compris , c'est le paragraphe suivant.

Comme j'ai dit avant, si tu as une machine qui fait tourner tous les jeux à >= 60fps constants 100% du temps avec de l'AA de maouf(je joue sans AA, pas besoin de AA), y compris quand tu te trouves dans des zones de jeu qui streament de la data du disque dur, des zones chargées en mobs, etc... Si en plus ta machine est si puissante(I5 750@2.66+GTX570)qu'elle arrive à réduire la latence à < 5ms pour tous ces jeux, par je ne sais quelle sorcellerie(Driver de la carte graphique), ça sera parfait. Si t'as tout ça, alors c'est bon pour toi. Je parle pour les autres qui n'ont pas ce matos. La différence entre le Rift et ton système track IR + 3D Vision est que ça ne tape pas directement dans ton oreille interne(Quel rapport ? ) ou ton appréciation du réalisme du monde qui t'entoure(l'écran couvre le plus gros du chant de vision et les lunettes me cache les côtés), sinon j'en aurais rien eu à foutre de la latence.
Je rappelle quand même que Carmack avait dit que pour avoir une vision réaliste du monde aperçu, il faut une latence de bout en bout de <= 20ms. et qu'actuellement avec son Doom3 super optimisé latence (qui tourne à 60fps constants bien entendu, mais là on en est plus à ce niveau), on a au total 50/60ms de latence totale.

Depuis le départ, je dis qu'effectivement je n'éprouve aucune latence en jouant en 3D Vision. Ca sous-entendait les jeux compatibles avec les drivers stéréoscopiques qui sont principalement les jeux DirectX. Hors, Doom3 n'est pas un jeu DirectX mais OpenGL, les drivers ne passent donc pas en stéréoscopie. Voilà pourquoi Carmack a été obligé de recoder son jeu pour que ces fameux 60 fps par oeil, soient générés nativement par le moteur du jeu au lieu d'être générés par le driver de la carte graphique. En gros, il s'est drôlement compliquer la tache, tout ça parce que Doom3, c'est son jeu à lui. il aurait fait sa démo avec un jeu DirectX, il n'y aurais pas eut cette importance sur la latence. Tout s'explique.
A y réfléchir, c'est quand de même étonnant qu'il a fait une tel bourde. Choisir son jeu pour la démo, alors qu'il devait savoir qu'il n'était pas adapté par rapport à sa librairie graphique alors qu'avec un jeu directX et les drivers, c'est prêt à l'emploi. Y a quasiment rien à modifier.

Après pourquoi le driver est plus efficace qu'un jeu nativement stéréo, j'en sais rien.

Il me semble qu'il y a eu un autre jeu qui a été codé stéréo via son moteur mais qu'au final, c'était pas top. Je me demande si c'est pas Crysis.

Donc pour résumer, les jeux DirectX passeront normalement sans trop de soucis et suivant leur degrés de compatibilité puisque les drivers de cartes graphiques le font très bien et je répéte qu'il n' y pas de latence, du moins perceptible.
Pour les jeux OpenGL, je doute qu'ils vont recoder les jeux comme Carmak pour les rendent compatible avec la stéréoscopie.

[MrPapillon]

Cependant, il suffit de se mettre bien droit et d'appuyer sur une touche qui recalibrera en position bien droite la situation virtuelle. Ca se fait en une fraction de seconde et c'est assez intuitif. Il y a de grandes chances que ce soit pareil pour le Rift car je ne vois pas comment faire autrement.

L'erreur semble gênante avec la plupart des technos testées par Carmack et Palmer. Donc ce n'est pas une solution réglée pour l'instant. Et recalibrer à la main toutes les 10s, ça risque d'être emmerdant. Il y a plein de solutions bizarres pour arriver à ne pas avoir à recalibrer et c'est en réflexion pour l'instant.

...

Je crois que t'as rien pigé de tout ce que j'ai raconté avant. Je suis mort dès le "(je joue sans AA, pas besoin de AA)", et tout le reste c'est dans la même veine. Pas envie de réexpliquer et réexpliquer à la même personne. Pour résumer, Carmack n'a pas recodé son jeu pour mettre de la stéréo, mais surtout pour réduire la latence. À partir du moment où ton CPU et ton GPU calcule des choses, que ça soit par le driver ou par ton code à toi, ça prend du temps et donc ça augmente la durée entre l'input et le buffer prêt pour être affiché. Comme on est sur un système passif et qu'on a un seul buffer pour les deux yeux, les deux yeux doivent être prêts au moment du rafraîchissement (Dans mon sens à moi passif veut dire pas d'alternance).

[tenshu]

Cependant, je m'y connais suffisamment pour dire que leurrer l'oreille interne ne te servira à rien et je me demande comment tu pourrais t-y prendre pour leurrer une oreille interne.

L'oreille auditive, l'oreille interne, un oeil ne sont que de simple capteur qui envoient des informations de grandeurs physiques tel qu'une onde sonore, une localisation spatiale ou la lumière; sous forme de signaux nerveux à destination du cerveau. Ils ne font que ça et interviennent dans aucun autre processus hors de ce pourquoi ils ont la charge.
Tout est centralisé au cerveau et tout ce passe dans le cerveau, comme les émotions ou la douleur même si tu la ressent au pied, elle se situe dans le cerveau. Le mal de mer est aussi généré par le cerveau. Donc c'est bien le cerveau qu'il faut leurrer.

Waoh, facepalm un peu.

Pour éviter la gerbe il faut presque parfaitement que la perception du cheminement dans l'espace retranscrit, soit identique à la captation qu'en fait l'oreille interne.
C'est ça que je désignais par "tromper l'oreil interne".

Tout cheminement dans l'espace peut s'avérer vomitif : monter des escalier, descendre un relief, marcher, courir, tourner la tête etc.
Si pour les déplacements, on peu relativement dire que c'est pas trop un problème.
Ca le devient quand le mouvement de la tête ne correspondent pas à ce que l'ooreille interne perçoit.
Ou que la position du corps dans l'espace est incohérente, genre houle sur un bateau, ou ce journaliste qui teste le rift et qui dit je bouge, je dois être sur un escalier. Il regarde au sol et il dit oh non il est plat, ça me rend malade cet effet.

[Sedjem]

Pour résumer, Carmack n'a pas recodé son jeu pour mettre de la stéréo, mais surtout pour réduire la latence.

Alors, tu crois vraiment que l'ordinateur est capable de deviner de devoir calculer de lui-même, de son propre chef, deux points de vues différents à un débit de frames constant quel que soit la charge graphique, sans instruction spécifique et tout, rien que part une optimisation poussée du code dans le seul but de réduire la latence ?
Alors faudras que tu m'explique comment fait l'ordinateur pour deviner cela sans que finalement le code du jeu ne le lui dise. Ce qui revient à dire que Carmak a bien recodé son jeu pour le rende stéréo.

À partir du moment où ton CPU et ton GPU calcule des choses, que ça soit par le driver ou par ton code à toi, ça prend du temps et donc ça augmente la durée entre l'input et le buffer prêt pour être affiché. Comme on est sur un système passif et qu'on a un seul buffer pour les deux yeux, les deux yeux doivent être prêts au moment du rafraîchissement (Dans mon sens à moi passif veut dire pas d'alternance).

Alors oui, prendre en compte les entrées du joueur, calculer la scène 3D par le CPU, puis traduire cette scène en image par la carte graphique et l'envoyer à un écran et ce, pour toutes les images de chaque oeil, ça prend du temps.

Alors que les systèmes à technologie de lunettes actives, on prend les entrées du joueur, le CPU calcule la scène 3D mais là, la carte graphique traduit toute seule les deux images pour chaque oeil.



Pour résumer le temps de calcul pour les deux images de chaque oeil :

méthode Carmak => deux saisies des entrées du joueur, deux calculs de la scène 3D par le CPU et deux calculs d'images

méthode driver carte vidéo => une seule saisie du joueur, un seul calcul de la scène 3D par le CPU et deux images par la carte graphique.

Alors qui tient la barre des 120 fps ? Et il faut pas oublier l'écart de résolution des écrans, ce qui enfonce le clou pour Carmak. T'imagine si le rift avait des écrans 1920*1080 avec son jeu Doom3 le temps de latence en plus avec ça méthode ?


Et je rapelle que cette technologie correspond très bien pour le Rift : débit de 2*60 fps natif, un système "d'aiguillage" pour amener l'image à l'oeil concerné (l'émetteur infra-rouge pour obscurcir l'oeil non concerné pour l'image affichée pour ceux qui se posent la question).

Alors que la technologie passive, les images sont entrelacées, pas franchement logique pour devoir les séparés ligne par ligne pour ensuite les adresser à leur écran respectif. Il y aura toujours le problème de la résolution tronquée sur la hauteur et surtout, comment savoir quelle image va à quel oeil.



Ce que j'essais de te dire, c'est que ce problème de latence qui te tient tant à coeur de cette démo n'est pas représentatif de ce que ce périphérique peut offrir, même en l'état actuel. La démo, d'un point de vue performances techniques est fortement contestable du fait quelle à été réaliser avec un jeu difficilement compatible pour ce genre de périphérique. Et viens pas me dire que le head-tracking à quel que chose à voir sur la vitesse d'exécution du jeu. Le driver du head-tracking va traduire ses coordonnés pour qu'elles soit directement exploitable par le jeu et cela en temps masqué par rapport à l’exécution du jeu comme tout périphérique de saisie. Alors dire que ce problème de latence sera générique à tous jeux, certainement pas.

En exemple, le HMZ T1 de sony.
Alors, oui il fout la gerbe parcequ'il n'a pas de head-traking intégré.
Oui, ces caractéristiques d'affichages qui nous conviennent pas pour nous, joueurs.
Mais lui, il est bien capable d'aficher en 3D avec une résolution plus importante que le Rift et avec moins de puissance de calcul puisqu'il est destiné aussi pour le marché de la playstation.

Je m'en fous de "contredire" Carmak Dieu le père, je ne prends pas tout ce qu'il dit pour parole d'évangile.

J'ai juste analysé avec mes faibles connaissances plutôt que de prendre tout pour argent comptant et même si ça m'a pris du temps et ça ma permit de mettre le doigt sur cette "bêtise" d'avoir pris un jeu qui si prête le moins pour la démo techniquement. Après, je me doute qu'il avait ses raisons, comme de connaitre le code et surtout d'avoir le droit de le modifier contrairement à un autre jeu dont il n'aurait pas la licence l'y autorisant.

[Erokh]

Ta signature indique que tu joue à Lock on, je m'etonne que tu pose cette question.
Avancer la tête te permet de t'approcher de tes instruments pour pouvoir les lire plus facilement, un peu comme un zoom.

Le 6 DoF n'est pas nécessaire pour du fps classique, mais serait bien plus confortable pour la cohérence de tes mouvements de tête volontaires ou non, par rapport à l'affichage.

Ouias, c'est vrai que j'avais oublié les simu (ça fiat longtemps que je n'y ai plus touché) et que je ne pensais plus qu'aux FPS. Ceci dit, j'avais aussi l'optique "éviter la gerbe" en tête. Et du coup je me demandais si un système captant uniquement la rotation de la tronche ne suffisait pas (en jeu, on bougera rarement en translation, et encore moins de manière répétée).

6dof ça veut dire que tu prends les translations sur les 3 axes. Par contre ça te dit juste que ça te donne de la data sur un axe, mais sans en préciser la nature. Là pour le coup c'est du relatif, de l'accélération si tu veux. Le problème c'est qu'on a pas une précision infinie et qu'à force de cumuler des accélérations pour avoir la position dans l'espace relative à la position à t=0, tu vas finir par accumuler des erreurs et au final tu ne sais plus où tu te trouves. Il y a le même problème pour les rotations, mais :
- pour les rotations de gauche à droite, on n'en a pas vraiment besoin pour le gameplay, on peut se contenter d'un peu d'imprécision, c'est pas grave.
- pour les rotations en penchant la tête sur les côtés et en regardant bas/haut, on recorrige avec une donnée supplémentaire : la gravité.

Ouais donc il manque un système de point de référence, quoi... Comme Sedjem je militerais pour un bouton "remise à zéro des positions". En jeu avec un trackIR tu doit le faire 1 fois par demi-heure, donc c'est largement gérable. Sur Wii motionplus, on est plus proche du système probable du Rift: 1 accéléromètre+1 gyroscope, et on n'a besoin d'initialiser qu'une fois... à voir, donc.

Sinon rajouter un 6dof ne sert à rien puisqu'il y en aura déjà un dessus. En plus il faut en prendre un avec une bonne latence et bonne précision de toutes façons.

Précision et latence, ok. ceci dit les capteurs en-eux même ne doivent pas trop peiner niveau latence. C'est surtout les traitements derrière qui risquent d'en ajouter à mon avis (à moins que le traitement soit "intégré au capteur").

La différence entre le Rift et ton système track IR + 3D Vision est que ça ne tape pas directement dans ton oreille interne ou ton appréciation du réalisme du monde qui t'entoure, sinon j'en aurais rien eu à foutre de la latence.

@Sedjem: on n'a pas de contrainte de latence sur un TIR+3Dvision car notre cervau perçoit largement ce qu'il se passe à l'extérieur de l'écran, et prend cette extérieur comme référence pour l'oreille interne. La preuve: on peut faire du 1:2 avec le TIR au niveau sensibilité des axes (et en pratique on fait souvent plus) sans être malades. A mon avis tu tente ça avec un Rift, c'est le gerbotron assuré dans les 10 minutes...

Le problème du Rift est qu'on ne voit rien d'autre que l'écran du Rift, d'où la nécessité de concordance entre l'oreille interne et les écrans. Alors forcément nous qui avons l'habitude de jouer sur écran, avec un référentiel extérieur (ne serait-ce que le cadre du moniteur) dont on n'est même plus conscients (mais que notre cerveau voit), on peut avoir du mal à se représenter les contraintes du truc

Alors, tu crois vraiment que l'ordinateur est capable de deviner de devoir calculer de lui-même, de son propre chef, deux points de vues différents à un débit de frames constant quel que soit la charge graphique, sans instruction spécifique et tout, rien que part une optimisation poussée du code dans le seul but de réduire la latence ?
Alors faudras que tu m'explique comment fait l'ordinateur pour deviner cela sans que finalement le code du jeu ne le lui dise. Ce qui revient à dire que Carmak a bien recodé son jeu pour le rende stéréo.

Nan mais évidemment Carmack a recodé son doom pour la stéréo si ce dernier n'en était pas capable avant. Mais finalement c'est pas grand chose à faire.

Par contre, optimiser un moteur afin de chercher non plus les FPS max mais la latence min, ça demande une re-conception du moteur en entier, et c'est déjà d'un autre niveau.

Alors oui, prendre en compte les entrées du joueur, calculer la scène 3D par le CPU, puis traduire cette scène en image par la carte graphique et l'envoyer à un écran et ce, pour toutes les images de chaque oeil, ça prend du temps.

Alors que les systèmes à technologie de lunettes actives, on prend les entrées du joueur, le CPU calcule la scène 3D mais là, la carte graphique traduit toute seule les deux images pour chaque oeil.



Pour résumer le temps de calcul pour les deux images de chaque oeil :

méthode Carmak => deux saisies des entrées du joueur, deux calculs de la scène 3D par le CPU et deux calculs d'images

méthode driver carte vidéo => une seule saisie du joueur, un seul calcul de la scène 3D par le CPU et deux images par la carte graphique.

Alors qui tient la barre des 120 fps ? Et il faut pas oublier l'écart de résolution des écrans, ce qui enfonce le clou pour Carmak. T'imagine si le rift avait des écrans 1920*1080 avec son jeu Doom3 le temps de latence en plus avec ça méthode ?


Et je rapelle que cette technologie correspond très bien pour le Rift : débit de 2*60 fps natif, un système "d'aiguillage" pour amener l'image à l'oeil concerné (l'émetteur infra-rouge pour obscurcir l'oeil non concerné pour l'image affichée pour ceux qui se posent la question).

Alors que la technologie passive, les images sont entrelacées, pas franchement logique pour devoir les séparés ligne par ligne pour ensuite les adresser à leur écran respectif. Il y aura toujours le problème de la résolution tronquée sur la hauteur et surtout, comment savoir quelle image va à quel oeil.



Ce que j'essais de te dire, c'est que ce problème de latence qui te tient tant à cœur de cette démo n'est pas représentatif de ce que ce périphérique peut offrir, même en l'état actuel. La démo, d'un point de vue performances techniques est fortement contestable du fait quelle à été réaliser avec un jeu difficilement compatible pour ce genre de périphérique. Et viens pas me dire que le head-tracking à quel que chose à voir sur la vitesse d'exécution du jeu. Le driver du head-tracking va traduire ses coordonnés pour qu'elles soit directement exploitable par le jeu et cela en temps masqué par rapport à l’exécution du jeu comme tout périphérique de saisie. Alors dire que ce problème de latence sera générique à tous jeux, certainement pas.

En exemple, le HMZ T1 de sony.
Alors, oui il fout la gerbe parcequ'il n'a pas de head-traking intégré.
Oui, ces caractéristiques d'affichages qui nous conviennent pas pour nous, joueurs.
Mais lui, il est bien capable d'aficher en 3D avec une résolution plus importante que le Rift et avec moins de puissance de calcul puisqu'il est destiné aussi pour le marché de la playstation.

Je m'en fous de "contredire" Carmak Dieu le père, je ne prends pas tout ce qu'il dit pour parole d'évangile.

J'ai juste analysé avec mes faibles connaissances plutôt que de prendre tout pour argent comptant et même si ça m'a pris du temps et ça ma permit de mettre le doigt sur cette "bêtise" d'avoir pris un jeu qui si prête le moins pour la démo techniquement. Après, je me doute qu'il avait ses raisons, comme de connaitre le code et surtout d'avoir le droit de le modifier contrairement à un autre jeu dont il n'aurait pas la licence l'y autorisant.

Je crois que tu ne comprends tout simplement pas bien le problème, et je pense que tu mélange différents trucs, là...
Le problème n'est pas de pouvoir calculer la 3D ou pas, ou de vitesse d'affichage ou quoi. Le problème c'est qu'en l'état actuel de l'art, aucun jeu ne garantit une latence inférieure aux recommandations, parce que tout simplement sur un écran normal les contraintes sur celle-ci sont largement moindres que sur un VR. Chaque jeu favorise donc les FPS, ce qui implique parfois une latence plus élevée.

Le problème n'est pas le nombre de FPS (enfin pas que...), ni la gestion ou non de la 3D stereo: on pourrait essayer de tourner avec un jeu 3D classique que le problème serait le même.

Ce qui pose problème avec les casques de VR, c'est le décalage réallité-écran dû à la latence parce qu'aucun jeu ne garantit la latence suffisante à l'heure actuelle.

Pour la latence, on va représenter la chaine de traitement sur le PC:
mouvement de tête -> captage et prétraitement par les capteurs->envoi au PC->gestion par les drivers->envoi au jeu->interprétation des données par le jeu->calcul de la scène->rendu->affichage.

Chacune de ces étapes implique de la latence. Ce n'est donc pas que sur le rendu qu'il faut bosser mais bien sur toute la chaine. Après comme toute chaine, c'est sur la maillon faible qu'il faut taper. Si le nombre de FPS est trop bas, c'est le moteur de rendu qu'on va tuner; si le jeu met trop de temps à traiter les données, ou utilise des pipes super longs pour ses traitements, c'est le moteur de jeu qu'on va bidouiller; si le traitement des données du capteur prend trop de temps, c'est les drivers qu'il faudra optimiser,... Cette problématique n'a donc rien à voir avec "3D ou pas 3D", et finalement a peu à voir avec le nombre de FPS.

Et au contraire, Carmack a plutôt eu raison de prendre Doom 3, car le jeu n'étant plus très jeune, on sait que les traitements et les rendus seront fait de manière relativement rapides, ce qui renforce d'autant plus la chaine. Quand en plus c'est un jeu qui tourne sur un moteur qu'il a créé et qu'il connait par cœur, il a tout intérêt à prendre celui-ci afin de l'optimiser à mort dans le sens qu'il veut.

Ah! et effectivement la latence a très peu à voir avec les performances du Rift en lui-même, on le voit bien en regardant la "chaine de latence" décrite plus haut.

[Sedjem]

.../...

Je voudrais redire ma vision de la chaine de traitement et là je pense que tu vas comprendre ou je veux en venir.

Ta description de chaine me plait plus que la mienne, donc on va la reprendre.
On va juste imaginer que toi et moi, on va suivre cette chaine, étape par étape en admétant quelles durent une même durée et que l'on évolue dans cette chaine suivant un top d'horloge.
La différence c'est que toi, tu vas suivres trait pour trait cette chaine qui correspond à la "méthode Carmak".
Moi je vois suivre la chaine suivant le mode de "stéréo à technologie active".
On oublie l'étape mouvement de tête, car pour ce que je veux, elle à aucune raison d'être et c'est externe au système de toute façons.
Par contre, on va appeler A l'image de gauche et B l'image de droite et les frames de 1 en 1.

Donc on commence "acquisition du mouvement de tête" et top, on monte à l'étape "envoi au pc", puis top à nouveau, "gestion driver", top, "envoie au jeu", top, "interprétation par le jeu",top, "calcul de la scéne", top, "rendu ".

Jusque là, on est synchrone, mais toi tu ne calcul que l'image 1A alors que moi, je calcul les images 1A et 1B. Top suivant. "Affichage".

On envoient tous les deux l'image 1A à son écran et moi je stock l'image 1B en mémoire. Top en reviens à l'acquisition du mouvement de tête". Top, "envoi au pc", top, "gestion driver", top,"envoi au jeu".

Moi je peux déjà rafraichir ces données mais pas toi. Toi du dois reprendre ceux du cycle précédent pour calculer la deuxième image 1B à partir du même point de vue que la 1A .

Rien que déjà à cette étape, j'ai un rafraichissement des données du head-tracking en avance sur toi.

Top. "interprétation par le jeu".
L'affichage des images 1A sont finit pour toi et moi. Mais moi, il me reste la 1B en mémoire, j'en profite pour l'envoyer en temps masqué pour l'écran B.

Top, "calcul de la scéne". Là je suis déjà en train de calculer la scène pour la frame 2 alors que toi tu est toujours sur la 1.

Top. "rendu". Calcul de l'image 1B pour toi alors que moi j'en suis déjà à la 2A et 2B.
Top. "affichage". tu envoie la 1B, moi la 2A.
Top et bis répitita jusqu'a létape "enjoie au jeu".

Là on rafraichit les même données du head-tracking tous les deux. Sauf que toi tu as loupé une étape par rapport à moi. Tu pourrais avoir plus l'impression que ton head-treaking "s'accade" plus que moi. etc...

tu vas rafraichir deux fois moins souvent le head-tracking que moi et tu auras une avancée de calcul de frames deux fois moins vite que moi. Le système à technologie active ne profite pas qu'au fps.


Après vous pouvez me dire les développeurs vont optimisé à mort le jeu pour qu'il puisse s’exécuter le plus vite possible pour évité ce retard par rapport à ma méthode "carte graphique", mais vu qu'ils ont déjà du mal à bouclé leur jeu en temps et en heure avec une tripoté de bugs à la clé, je doute qu'ils vont consacrer du temps pour cela.


Franchement, le système à technologie active est pour moi le système le plus adapter à la réalité virtuel. Inconvénient majeur, OpenGl, ça passe mal, atout, pas de grande modif à faire dans les jeux DirectX.


D'un point de vue matériel, je vois vraiment l'oculus comme un système à "carte graphique", vraiment, tout s'y prête.


Si vraiment ma vision sur le sujet n'est pas bon, je voudrais bien une définition compléte et précise de la latence parce que j'ai vraiment du mal avec cette notion où j'ai aucun souvenir d'avoir subit cette fameuse latence.
Si il y a d' autre pratiquants d'écran 3D qui passent par là, veuillez témoigner de cette latence ou non latence s'il vous plait car la seule chose qui me viens à l'esprit sont les freezes mais je doute que ce soit la même chose.

[tenshu]

Désolé mais TL;DR, pourtant le sujet est passionnant.

[olih]

...

Opengl peut faire de la stéréoscopie (ça fait partie de la norme) depuis un sacré bout de temps.
Et tes deux images quelque soit ton mode de rendu, tu les calcules l'une à la suite de l'autre, en changeant simplement la caméra et sans prendre en compte de changement de position.

[MrPapillon]

Sedjem tu racontes des trucs de plus en plus nawak.

Ouais donc il manque un système de point de référence, quoi... Comme Sedjem je militerais pour un bouton "remise à zéro des positions". En jeu avec un trackIR tu doit le faire 1 fois par demi-heure, donc c'est largement gérable. Sur Wii motionplus, on est plus proche du système probable du Rift: 1 accéléromètre+1 gyroscope, et on n'a besoin d'initialiser qu'une fois... à voir, donc.

Non ça ça marcherait si on avait un système merveilleux avec une très grande précision. Sauf que les gens sur le forum mtbs, Carmack et Palmer ont tous un soucis avec les capteurs actuels, il ne semble pas se dégager de solution pour l'instant. Par contre ce qui est quasi sûr c'est qu'on aura toujours des soucis avec des systèmes uniquement relatifs parce que la précision ne sera pas assez bonne, ou alors il faudra recalibrer à intervalle régulier. On peut utiliser le truc optique de la wiimote par exemple pour ça, mais c'est horrible au niveau du code et ça ne fonctionne que pour des cas super spécifiques. On peut imaginer un système optique (kinect, plusieurs caméras, etc...) ou d'autres solutions.

Précision et latence, ok. ceci dit les capteurs en-eux même ne doivent pas trop peiner niveau latence. C'est surtout les traitements derrière qui risquent d'en ajouter à mon avis (à moins que le traitement soit "intégré au capteur").

Là je n'en sais rien, ça dépend du type de capteurs et du type de cpu qui va se charger des calculs. Niveau capteur, peut-être qu'un accéléromètre est basé sur un système mécanique en interne et donc ça peut créer de la latence. J'en sais pas grand chose, si quelqu'un a des précisions sur ça ça m'intéresserait.

Et au contraire, Carmack a plutôt eu raison de prendre Doom 3, car le jeu n'étant plus très jeune, on sait que les traitements et les rendus seront fait de manière relativement rapides, ce qui renforce d'autant plus la chaine. Quand en plus c'est un jeu qui tourne sur un moteur qu'il a créé et qu'il connait par cœur, il a tout intérêt à prendre celui-ci afin de l'optimiser à mort dans le sens qu'il veut.

Justement oui, il a pu bloquer le framerate à 60fps et se concentrer sur la latence.

Et tes deux images quelque soit ton mode de rendu, tu les calcules l'une à la suite de l'autre, en changeant simplement la caméra et sans prendre en compte de changement.

J'imagine qu'on peut même faire un "injector" pour les jeux déjà sortis qui court-circuite le driver pour dupliquer les certaines commandes au gpu en changeant la matrice de cam au passage. Par contre pour les vertex shaders, faut une solution au cas par cas j'imagine. On va peut-être perdre quelques optims sur une solution 100% driver, mais ça m'étonnerait qu'on soit tant que ça à la ramasse. Et de toutes façons on s'en tape, parce que c'est pas le nerf de la guerre.

[Sedjem]

Opengl peut faire de la stéréoscopie (ça fait partie de la norme) depuis un sacré bout de temps.
Et tes deux images quelque soit ton mode de rendu, tu les calcules l'une à la suite de l'autre, en changeant simplement la caméra et sans prendre en compte de changement de position.

L' OpenGl peut faire de la stéréoscopie, oui bien sûr, mais pas par le biais de la méthode "driver carte graphique" représenté par 3D Vision pour Nvidia et HD3D ou Tridef pour AMD.

Ce procédé stéréoscopique intercepte "des données dans le flux de rendu Direct3D". J'ai mis entre guillemets car je ne me rapelle plus du terme exacte et je n'arrive pas à le retrouver.

L'interception de ces données, c'est ce qui permet à la carte de déterminer les deux images pour les deux yeux sans avoir à gérer deux caméras sur l'ensemble de la chaine de traitement.
En gros, la carte, elle se débrouille toute seule, elle n'a pas besoin d'aide du CPU.

Pourquoi est ce impossible de faire pareil avec l'OpenGl, je ne le sais pas.
Peut-être que ce procédé prend trop de temps avec l'OpenGl et que du coup, les 120 images secondes seraient compromises.
Peut-être que ces coordonnées sont trop diluées avec d'autres données et que de les triées par la carte seraient trop complexe/long. J'en sais rien, tout ceci ne sont que des suppositions.
Tout ce que je sais, c'est que ça ne marche pas.

Cependant, dernièrement une parade a été trouvée (je suis désolé, je ne sais pas faire de lien qui pointe directement sur un post, il faut aller voir le post de Jean Pale n° 2158 ) ; et comme tu peux le voir, ça date du 06/2012 donc, c'est très récent.

Après oui on peut gérer un jeu OpenGl en stéréoscopie de manière logiciel via le code du jeu, en calculant deux fois la scène à chaque fois pour avoir les deux images des yeux de chaque frame.

Ca fonctionne, je ne dis pas le contraire. Mais je dis que c'est bien plus gourmand en ressources machines et du coup, j'affirme qu'avec le procédé "carte graphique" by 3D Vision, HD3D et Tridef, on aura de bien meilleurs résultats, et qu'on peut voir cela comme une "accélération matérielle" de la 3D.

Après ma courte visite sur leur site, a moins que je n'est touvé le topic en question, je trouve dommage qu'il ne travail pas dans ce sens. J'ai l'impression que c'est un peu du gâchis.

J'ai peur que la gestion stéréoscopique de l'oculus se dirige par du tout logiciel et du coup oui la gestion, l'optimisation des codes et moteurs des jeux auras effectivement une grande part dans l'appréciation de cette réalité virtuelle.

Alors qu'a coté, y une solution qui à fait ses preuves de stabilité et ce dans des jeux où il n'y a aucune ligne de code en rapport à la gestion de la stéréoscopie.

[doshu]

je suis désolé, je ne sais pas faire de lien qui pointe directement sur un post, il faut aller voir le post de Jean Pale n° 2158

Fait pointer le lien sur le n° de post justement. Le n° de post en lui-même est un lien.

Et, pfiou, je lis plus tout ce que vous racontez moi hein. Un tartine ça, dix...

[MrPapillon]

J'ai peur que la gestion stéréoscopique de l'oculus se dirige par du tout logiciel et du coup oui la gestion, l'optimisation des codes et moteurs des jeux auras effectivement une grande part dans l'appréciation de cette réalité virtuelle.
Alors qu'a coté, y une solution qui à fait ses preuves de stabilité et ce dans des jeux où il n'y a aucune ligne de code en rapport à la gestion de la stéréoscopie.

Le Rift gère la stéréo comme n'importe quel autre périph d'affichage 3D. Il faut juste présenter les deux images sur le même buffer, l'une à côté de l'autre ce qui doit déjà être compatible avec le 3D Vision parce que je crois que ce n'est pas le premier à utiliser ce mode de fonctionnement.
Tant mieux alors si NVidia a réussi à faire réduire la latence dessus du coup, je dois avouer que ça me plombe pas mal les perfs sur certains jeux quand même. Et puis NVidia tweak en fonction de chaque jeu et c'est un système fermé. Si un jeu manque, il faut attendre bêtement ou alors on a plein d'effets désagréables. Il serait sympa d'avoir une solution open source pour régler ce problème quitte à s'ajouter par dessus le 3D vision pour modifier le rendu de certains jeux avec un injector avant de balancer au 3DVision.
Maintenant tout ça ça reste quand même une latence supplémentaire, qu'on puisse l'optimiser plus ou non, qui s'ajoute à tout le reste sur le pipe.

Sinon pourquoi c'est impossible de le faire avec OpenGL : en général la réponse c'est tout simplement que NVidia et ATI en ont rien à foutre. Sinon si c'était impossible à faire avec l'API de base, ils auraient présenté une extension supplémentaire pour gérer ça directement par le code puisque c'est comme ça qu'on fait sous OpenGL. Je n'ai jamais joué avec la stéréo native d'OpenGL, mais ça fait depuis des siècles qu'elle est là et je pense que si NVidia voulait vraiment que ça fonctionne avec, ils l'auraient fait. C'est le même problème avec OpenCL et CUDA, Cg et GLSL, NVidia fait tout pour mettre en avant son poulain au détriment de la standardisation et ainsi mettre des bâtons dans les roues d'Intel et AMD/ATI.

[Erokh]

Je voudrais redire ma vision de la chaine de traitement et là je pense que tu vas comprendre ou je veux en venir.
[...]

Mais... mais non pas du tout!! POurquoi ton moteur de jeu serait-il obligé de tout reprendre dès le début de sa scène pour faire de la 3D?!
Si un moteur de jeu faisait comme tu dit, l'image de droite serait décalée par rapport à celle de gauche puisque le point de vue aurait changé (étant donné qu'on aura capté un mouvement du head-tracking). J'ose pas imaginer l'effet que ça ferait, en pratique...

Si j'ai mis "rendu" en version globale, c'est bien justement pour englober rendu 2D ou 3D.

Alors reprenons mon schéma. Pour toi, le moteur du jeu ferait
mouvement de tête -> captage et prétraitement par les capteurs->envoi au PC->gestion par les drivers->envoi au jeu->interprétation des données par le jeu->calcul de la scène->rendu->affichage I1a
mouvement de tête -> captage et prétraitement par les capteurs->envoi au PC->gestion par les drivers->envoi au jeu->interprétation des données par le jeu->calcul de la scène->rendu->affichage I1b
On a donc 18tops
Mais c'est juste débile et inefficace pour de la 3D (décalage entre les deux images, calculs inutiles tout du long,...)

Et avec les drivers ça ferait ça d'après toi:
mouvement de tête -> captage et prétraitement par les capteurs->envoi au PC->gestion par les drivers->envoi au jeu->interprétation des données par le jeu->calcul pour obtenir les scènes 1a et 1b->rendu->affichage I1a->affichage 1b
9tops

Moi ce que je vois niveau moteur c'est:
mouvement de tête -> captage et prétraitement par les capteurs->envoi au PC->gestion par les drivers->envoi au jeu->interprétation des données par le jeu->calcul de la scène S1a+calcul de la scène S1b->renduS1a+renduS1b->affichage
9tops

Et je pense qu'en réalité le fait de passer par les drivers donne plutôt ça:
mouvement de tête -> captage et prétraitement par les capteurs->envoi au PC->gestion par les drivers->envoi au jeu->interprétation des données par le jeu->calcul de la scène 2D par le moteur -> recalcul par les drivers pour obtenir les scènes 1a et 1b->rendu->affichage I1a->affichage 1b
10tops

Donc exactement le même principe que ton histoire de drivers, mais directement dans le jeu plutôt que les drivers CG. Et encore mieux: selon ce qu'on veut faire, on peut choisir de faire calculer les 2 scènes par le proco ou le GPU, on peut aussi leurrer la CG en calculant une scène double et lui envoyant ensuite une seule image à calculer.

De toute façon y'a pas à tortiller: une feature est toujours mieux quand elle est supportée en natif. Les performances sont très souvent meilleures car on supprime des intermédiaires, et on évite beaucoup d'incompatibilités ou de bugs éventuels (les postprossecing 2D qui foutent la merde, par exemple).

Quant au système d'affichage de l'occulus, c'est un système qui n'est finalement ni actif ni passif.
Je m'explique:
un système passif, on envoie 2 images entrelassées et les lunettes filtrent
Un système actif, on envoie 1 image, mais les lunettes masquent chaque oeil alternativement

Sur le Rift, on a juste deux écrans qui envoient une image à chaque oeil. On est donc en fait plus proche du système passif car les deux images sont envoyées en même temps aux deux yeux. Le Rift n'est pas du tout un système actif tel que tu le vois, donc, et n'a rien à voir avec le 3Dvision.


Au final t'inquiète pas: si plein de mecs du milieu se sont penchés dessus et qu'ils disent que c'est chaud, c'est pas un péquin qui n'a aucune (ou peu) d'expérience en programmation de moteurs de jeu qui va leur trouver une solution toute faite
Carmack a beau préférer l'OpenGL, je pense qu'il saurait prendre du D3D s'il pensait qu'il y aurait un réel avantage à le faire (et les gars du Rift choisiraient aussi un moteur D3D plutôt qu'OpenGL si sa supériorité était si évidente).

[Daedaal]

.../...
Et puis NVidia tweak en fonction de chaque jeu et c'est un système fermé. Si un jeu manque, il faut attendre bêtement ou alors on a plein d'effets désagréables. Il serait sympa d'avoir une solution open source pour régler ce problème quitte à s'ajouter par dessus le 3D vision pour modifier le rendu de certains jeux avec un injector avant de balancer au 3DVision.
.../...

Je veux bien que l'open source soit le Bien... Mais baser ça sur le temps d'attente me parait un peu spécieux : Attendre que Nvidia tweake son driver pour incorporer un jeu moteur spécifique est peu ou prou équivalent à attendre que "la communauté" modifie son injecteur pour gérer un moteur spécifique.

D'ailleurs, tu n'auras pas manqué de remarquer que la communauté est d'ores et déjà investie dans l'amélioration de l'expérience 3Dvision...

[Nieur]

Je verrais bien un appareil du genre pour les informaticiens : plein d'écrans virtuels en face des yeux (un peu comme les 3 écrans que j'ai face à moi en ce moment), où tu tournes la tête pour en regarder un autre.
Et en plus, finie la fatigue visuelle puisque tu peux changer la distance de mise au point.

[Boitameuh]

Pas con ça Nieur, même si j'ai pensé à ça direct :




Sinon la perspective de piloter un warbird avec le Rift sur le nez me colle une demi-molle je dois avouer.


Tiens d'ailleurs au sujet de ce tu proposes : http://www.rockpapershotgun.com/2012...ble-computing/

What you really want is VR and to not have the screen. With high enough resolution, you can just put your screens around you. And then your desk is wherever you choose to be.