La Confrérie des Traducteurs

D'accord merci shadow.
Mais pour moi, tant que ça n'a pas quatre pattes et deux ailes ce n'est pas un dragon, mais une wyvern ou un wyrm. Ah et bien sur cela porte écailles et craches le feu!

Eldrak a écrit :Mais pour moi, tant que ça n'a pas quatre pattes et deux ailes ce n'est pas un dragon, mais une wyvern ou un wyrm. Ah et bien sur cela porte écailles et craches le feu!

Dans la plupart des textes, Dragon et Wyrm sont des mots interchangeables…

Autant ici que là par exemple…

On entend aussi parler de "Wamasu" pour une "espèce de dragon ayant de la foudre pour sang" qui vivraient (auraient vécu) en Argonie…


Dragon peut être un "genre d'espèce", un petit peu comme les "hommes" ou "elfes"…
Ou quelque chose dans le genre…

Pour Hauteroche, si j'ai dit "plat et franchouillard", c'est parce qu'avant Daggerfall c'était la seule vision que l'on pouvait en avoir... Et encore, il n'y a que le guide de poche de l'empire pour proposer un visuel du pays, car Daggerfall laisse vraiment l'image d'un pays plat habité par des campagnards.
En parlant de ça, Hauteroche et Lenclume seraient des pays très intéressants à revisiter avec les moteurs de jeu actuels.

Plumétoile a écrit :Pour Hauteroche, si j'ai dit "plat et franchouillard", c'est parce qu'avant Daggerfall c'était la seule vision que l'on pouvait en avoir... Et encore, il n'y a que le guide de poche de l'empire pour proposer un visuel du pays, car Daggerfall laisse vraiment l'image d'un pays plat habité par des campagnards.

Oui Daggerfall est plat, car le moteur ne sait pas gérer les reliefs…
Si on part de ce principe, toutes les provinces sont "plates" parce qu'Arena ne sait pas non-plus gérer le relief…?


Non, d'après le Lore, et pas que dans les PGE, toute la partie est de la province est constituée de montagnes…
Il suffit de regarder la carte…
Plus de la moitié du territoire est recouvert de montagnes, les Montagnes de Wrothgar, on ne nomme pas le pays "Hauteroche" pour rien…
Divers textes dans les différents jeux parlent des "hommes de la crevasse", les "reachmen", parlant de ces habitants de la montagne…

Et la partie "plate", ça reste des "collines verdoyantes", notamment ici…

Bref, ça fait beaucoup de possibilités pour un Elder Scrolls VI, que ce soit pour revoir Hauteroche et Lenclume telles qu'elles auraient du être, ou pour découvrir le reste de Tamriel. L'idéal à mon sens c'est qu'ils puissent nous surprendre, plus que juste nous divertir avec leurs nordiques culturistes et leurs dragons.
Je dis pas qu'il n'en faut pas, je pense que Skyrim a l'avantage de relancer la série sur un très bon pied par rapport à ce qui se fait en ce moment. Et ce confort que donne leur position de Studio de l'année, de Jeu de l'année leur permettrait sans doute de faire quelque chose d'osé et d'original, tout en retrouvant la complexité des premiers jeux.

Plumétoile a écrit :Si ils pouvaient par exemple délaisser à l'occasion des prochaines générations de consoles le principe technique qui ne les lâche pas depuis Arena : c'est la map qui se déplace et pas le joueur. Abandonner cette facilité pour les processeurs permettrait de développer l'intéraction entre le PJ et son environnement physique, par exemple l'escalade qui est très en vogue en ce moment dans les jeux.

En partant du principe que tu as raison…
Qu'est-ce que ça change…? En quoi l'un est meilleur que l'autre…? (je me suis plus ou moins documentée et la différence entre les deux méthodes tiendrait d'une inversion de calcul matriciel, après il y a peut-être autre chose, je ne maîtrise pas le sujet…)

Au passage, l'escalade existe dans Daggerfall…
Le fait que le référentiel soit le joueur ou pas, ça n'empêche pas le déplacement sur l'axe des Z, et encore heureux…

Evidemment que ça ne l'empêche pas. Mais ce système est tel qu'un mode d'escalade serait ni fluide ni réaliste. D'ailleurs c'est le cas pour l'escalade dans Daggerfall, c'est simplement atroce.
Un système d'escalade décent demande une interaction entre le PJ et la paroi, seulement c'est la paroi qui est mue par les contrôles et pas le PJ. Je ne dis pas que c'est impossible de le faire de cette façon, ça peut être fait très facilement, mais le résultat sera affreusement surréaliste.
On aurait une animation bizarre de PJ qui bouge les bras et les jambes le long de la paroi sans qu'on comprenne à quoi il s'accroche, d'autant plus que la caméra est "lockée" sur lui en location et en direction, ce qui donnerait une sensation d'inertie, même quand il se déplace.

Une autre preuve de la réalité de ce système dans les jeux : vous avez remarqué que les animations ou le PJ s'asseoit sont précédées d'un changement de caméra ? Pareil pour les killmove, ils sont tous en mode cinématique. La transformation en loup-garou également, il y a un premier changement au début, la caméra bouge bizarrement pour souligner le malaise du personnage, puis un deuxième changement discret juste avant qu'il se mette à rugir en écartant les bras !

C'est très subtil comme modification, surtout quand c'est bien dissimulé. Mais au final l'expérience de jeu est changée, les interactions entre le PJ et son environnement sont hachées, pas fluides. Si la rumeur comme quoi ils attendent les prochaines générations de console pour sortir un nouvel opus, alors cela leur permettrait de changer radicalement l'expérience de jeu et d'ouvrir un tas de possibilités au niveau de l'interactivité.

J'ai toujours un petit peu de mal à comprendre pourquoi il y aurait un problème, puisque normalement pour l'escalade c'est surtout le moteur physique qui définit les placements sur la paroi, pas le moteur 3D…

Et j'ai toujours du mal à voir ce que tu démontres avec tes histoires de caméra…

Plumétoile a écrit :Une autre preuve de la réalité de ce système dans les jeux

Car moi aussi je peux fournir des exemples pour l'inverse…

Un moteur 3D, ça a besoin d'un référentiel pointé arbitrairement (mais c'est bien pratique) en (0,0,0)…
Selon ta théorie, ça signifie que le joueur est en (0,0,0)…

Pourtant, quand on fait un "player.GetPos", on a une coordonnée 3D, on déplace le PJ, on refait la commande, et on obtient une coordonnée différente…
Maintenant on fait ça sur un arbre, un GetPos dessus, il a une coordonnée, on bouge le PJ, on refait un GetPos et on obtient le même nombre…

Là on peut en déduire assez "logiquement" que c'est le PJ qui bouge, pas l'arbre…
Mais, mettons que c'est du "camouflage"…

Notre carte du monde, elle, est centrée à cette fameuse coordonnée (0,0,0), elle n'est pas centrée sur le PJ, puisque le PJ peut sortir de la carte, c'est très facile à voir sur Morrowind, un petit peu moins sur les autres jeux…
Mais là encore, s'il y avait camouflage sur le premier point, le détail de la carte s'explique assez facilement…

Maintenant, dans Morrowind, certains modules font leurs îles de façon très éloignée du centre de la carte (qui se situe quelque part dans le Mont Écarlate), de façon a éviter les conflits et éviter que les îles n'apparaissent sur la carte…
Quand on s'éloigne suffisamment, vers ±132 cells si je me souviens bien, on assiste au phénomène des "acteurs qui tremblent" (dont le PJ si je me souviens bien, mais je ne sais plus pour le décors)…

Le moteur 3D utilise des virgules flottantes pour faire ses calculs…
C'est à dire que sur les 32bits pour coder un nombre, un bit sert à définir le signe, puis les 31 autres bits définissent le nombre…
Je passe le détail du codage de ce nombre, ce n'est pas très important, mais il va sans dire que plus la partie entière du nombre est grande, moins il y a de place pour les nombres après la virgule…
Or le jeu utilise quatre nombres après la virgule pour définir sa précision (visible depuis le TESCS)…

Donc il arrive un moment où la partie entière devient tellement grande qu'il n'y a plus de place pour les virgules, et donc on arrive à faire des arrondis, qui dit arrondis, dit erreurs de calculs…
Si on code mal un moteur 3D, et que l'on fait tourner un objet 3D sur lui-même durant un certain temps, il finit par se ratatiner sur lui-même à cause de ces erreurs de calculs sur les virgules…

C'est justement ce qui se passe pour nos "acteurs qui tremblent", le jeu calcule à chaque frame la position de chaque partie du corps, c'est à dire qu'il calcule la position des cheveux, celle de la tête, celle du cou, et cetera…
Comme il y a des erreurs de calculs, on obtient un décalage entre la position des cheveux sur la tête, qui elle-même a un décalage par rapport au cou, qui elle-même a un décalage par rapport au tronc, et cetera…
Il suffit que l'acteur se déplace d'un chouïa (ce qui se passe tout le temps), ces erreurs de calculs font que les cheveux ne sont jamais à une position fixe, avec les erreurs dû aux arrondis, les cheveux sautent (visuellement) de position en position, et c'est comme ça pour chaque partie du corps…
Donc l'acteur "tremble", c'est particulièrement laid, il faut le dire…



Bref, tout cela pour dire que si le PJ est le référentiel du moteur 3D, c'est à dire la position (0,0,0), le positionnement des autres acteurs se ferait rapport au PJ, et ils resteraient donc toujours dans une distance raisonnable, on ne verrait pas ce tremblement…
Or non, ce tremblement est dû au fait que le jeu calcule la position des acteurs par rapport au centre du monde, donc à partir du point (0,0,0) sur le mont écarlate…



En fait, je me demande surtout d'où tu tires cela (une source…), et où trouves-tu une explication pour les problèmes que ça peut poser… (je l'ai dit, je ne maîtrise pas le sujet, je n'ai que quelques bases, donc je peux me tromper, et je ne refuse pas de m'instruire sur le sujet…)
Parce que tes histoires de caméra, j'ai du mal à voir ce que ça prouve mis à part que Beth est pas doué avec les animations…

Je ne suis pas programmeur de jeu, et mes études ne vont pas non plus dans ce sens, donc je ne vais pas rentrer dans un débat technique.
Je me base sur des constats. J'ai lu quelque part (je ne sais plus ou) que les Elder Scrolls utilisaient ce système ou la map se déplaçait autour du joueur. Ce n'est pas moi qui l'ai inventé, je te rassure. Et, fort de cette information, j'ai constaté en effet les détails visuels et physiques du jeu qui trahissent l'usage de ce système.

Comment dire, les personnages non joueurs, les objets physiques soumis à havok ainsi que le PJ ont des coordonnées par rapport au centre de la carte qu'ils utilisent pour leurs interactions physiques, mais ces calculs sont exclusifs à l'univers virtuel du jeu. Pour ce qui est d'arpenter cet univers, on se retrouve avec un autre référentiel basé sur la position du joueur avec des coordonnées 0,0,0 invisibles qui vont régir la profondeur de champ, le champ de vision du joueur pour l'affichage, et le déplacement de l'univers en son entier.

Et c'est d'autant plus flagrant quand on passe en première personne ! Fais un test simple, brandis ton épée en 3è personne et mets toi le nez face au mur. Fais en sorte que l'épée traverse la paroi du mur. Sans bouger, passe en 1ère personne et tu remarqueras que ton épée est entière, et qu'il est impossible de lui faire traverser les parois. C'est une preuve du détachement du personnage par rapport à son environnement.

Je fais pas de code, je sais pas comment ils programment leur bazar autour de ce système-ci, mais je sais observer les résultats.

Bonjour,

Du coup je m'incruste dans ce HS, en m'excusant d’ailleurs auprès de l'équipe de modération Shadow m'a récemment parlé de ce sujet qui m'intéresse beaucoup.

Il est vrai Plumétoile que traditionnellement, le rendu graphique (c'est à dire la projection du monde virtuel en 3D sur un écran 2D) se fait avec une caméra fixe, orientée vers -Z. Dans ce cas de figure on peut considérer, et l'on dit souvent dans les livres, que le "monde se déplace autour de la caméra". C'est quelque chose qui est géré par les drivers de cartes graphique, le développeur se contentant en général (mais c'est de moins en moins vrai) de faire appel à des fonction d'API.

Mais tout ça n'est qu'une histoire de calcul matriciel, la matrice de transformation coordonnée monde-> coord caméra étant inversée (pour les translations) entre un référentiel égocentrique et un référentiel monde centré. Mais tout ça, le développeur s'en bas littéralement, on le voit en cours de Rendu 3D, on le sait mais on s'en fout. Sauf s'il faut faire un moteur 3D pour de l'embarqué ou en passant par des shaders...

Tu imagines bien que je n'ai pas accès aux sources des moteurs Bethesda, mais on peut faire ces constatations simples :
- Les getPos sur le joueur, qui donnent cette conclusion :

Comment dire, les personnages non joueurs, les objets physiques soumis à havok ainsi que le PJ ont des coordonnées par rapport au centre de la carte qu'ils utilisent pour leurs interactions physiques, mais ces calculs sont exclusifs à l'univers virtuel du jeu.

Effectivement, ces coordonnées que l'on appelle coordonnées monde, sont sur un référentiel propre au monde, avec les inconvénients soulevés par shadow plus haut (tremblement lors de calculs flottant).

Par contre ça:

Pour ce qui est d'arpenter cet univers, on se retrouve avec un autre référentiel basé sur la position du joueur avec des coordonnées 0,0,0 invisibles qui vont régir la profondeur de champ, le champ de vision du joueur pour l'affichage, et le déplacement de l'univers en son entier.

Ça me semble faux. Il existe, à partir du moment où l'on utilise DiretX (ou OpenGL), un objet caméra, généralement défini par un matrice ( position, orientations de ses axes par rapport au ref monde, et direction) et par un ensemble de paramètres, fov, zmin, zmax, etc... Et là, je peux le dire d’expérience, il n'y a STRICTEMENT AUCUNE différence entre avoir une caméra fixe et une caméra flottante. A priori, dans Skyrim, il est plus simple d'avoir une caméra flottante.

A titre d'exemple pour un projet de RV où la caméra devra suivre en temps réel les yeux d'un utilisateur, on utilise une caméra flottante et sans lag aucun je te l'assure Pour un jeu qui restera globalement sur un même plan, pourquoi pas une caméra fixe. En fait c'est au goût du développeur.

Mais au final pour le rendu, la caméra sera fixe et le monde bougera autour. Mais le rendu n'influe pas et ne peut avoir aucune influence sur l’interaction monde-joueur.

Et c'est d'autant plus flagrant quand on passe en première personne ! Fais un test simple, brandis ton épée en 3è personne et mets toi le nez face au mur. Fais en sorte que l'épée traverse la paroi du mur. Sans bouger, passe en 1ère personne et tu remarqueras que ton épée est entière, et qu'il est impossible de lui faire traverser les parois. C'est une preuve du détachement du personnage par rapport à son environnement.

Effectivement, mais encore une fois cela n'a rien à voir avec le système utilisé pour la caméra. Pour des raisons d'optimisation on utilisera souvent un model très simple pour le joueur dans un jeu à la première personne (Faith dans mirrors edge n'a ps de corps par exemple). A la 3ème personne, le mesh est complet et l'on peut bien voir les collision dues à la mauvaise configuration de Havock (intersection avec les murs, pieds qui rentre dans le sol,...), à la première personne on a ça :
http://cloud.steampowered.com/ugc/63073 ... 5C43AB369/

Lorsqu'on étend le bras pour frapper. Lorsque le joueur est en garde la distance d'affichage de la porte ne bougera pas (exactement même arrière plan). On constate donc que les bras sont affichés "par dessus" le monde, à priori le moteur désactive le Z-buffering sur les bras, comme un cache misère. Le joueur n'est pas conscient que ses bras passent à travers le mur, ça rend plutôt bien et surtout rien ne passe jamais (ou ne devrait jamais passer) entre la tête du joueur et ses bras.

A la troisième personne, on ne peut bien sur pas faire ça, pour des questions de réalisme dans le rendu (l'impression d'avoir un PJ flottant dessiné par dessus l’écran, les arbres qui passerait derrière le joueur sans qu'on sache pourquoi...)

Pour l'escalade, encore une fois cela n'a rien à voir avec la manière dont la caméra est gérée. Juste que Bethesda a la flemme. De toute façon les interactions se feront en coordonnées monde et pas caméra. Un vecteur à inverser c'est franchement pas la mort

Et finalement, pour le joueur parfaitement centré par rapport à l’écran. On obtient ça en définissant la caméra (flottante) par rapport à la position du PJ. Si la caméra regarde toujours vers le joueur, son référentiel aligné avec celui du monde (pour pas avoir de rotation) et toujours positionnées à posPJ - ( 0, 3, 3) on devrait avoir un truc plutôt similaire.

Tout ça pour conclure, qu'il est ben plus simple d'avoir une caméra flottante en référentiel monde pour un jeu 3D comme le ES et qu'en fait on s'en fout puisque le rendu sera lui sur un repère ego-centré. Les relations entre le joueur et le monde se faisant en référentiel monde.