Bonjour,
Je calcule dans un script la vitesse en mètre/secondes à laquelle le PJ se déplace. Mètres et secondes étant à l'échelle du jeu.
Le résultat me semble incohérent et je ne comprends pas pourquoi. Voici ce dont je tiens compte et ce que je fais :
Pour la distance :
Je relève les coordonnées x et y du PJ au départ, puis de nouveau 2 frames plus loin. (Z ne change pas et ne rentre donc pas dans mon calcul).
Ensuite je fais sqrt ( ( X2 - X1 )² + ( Y2 - Y1 )² ) ; "sqrt" indique "racine carrée".
Comme le MSfD indique qu'une unité de jeu = 1.42 cm, je multiplie le résultat obtenu par 0.0142 pour avoir la distance en mètres.
Note : J'ai aussi essayé de multiplier directement par 0.0142 chaque coordonnée au lieu de multiplier la racine carrée (le résultat est sensiblement le même).
Pour le temps, j'ai essayé deux méthodes :
Méthode 1) Je démarre un timer au départ et le stoppe au deuxième relevé de position. J'obtiens donc un temps exprimé en secondes réelles que je multiplie par "TimeScale" pour le convertir en secondes du jeu. (Dans le doute, j'ai aussi essayé en divisant par "TimeScale").
Méthode 2) Je fais ( GameHour de l'arrivée - GameHour du départ ) ; en vérifiant au préalable que l'heure d'arrivée est > que celle du départ.
J'obtiens donc un temps exprimé en heure à l'échelle du jeu, que je multiplie par 3600 pour l'avoir en secondes du jeu.
Note : Autant pour la distance que pour le temps, j'ai vérifié mes résultats avec une calculette en relevant toutes les mesures. Mes résultats étant presque identiques, ce n'est donc pas un problème d'écriture de script.
Au final, je fais ( mètres du jeu / secondes du jeu ) pour obtenir ma vitesse en m/s à l'échelle du jeu.
Au passage, j'en profite pour exprimer le résultat sous d'autres formes dans d'autres variables :
( ( mètres du jeu / secondes du jeu ) * 3600 ) ; ... vitesse en m/h
( ( mètres du jeu / secondes du jeu ) * 3.6 ) ; ... vitesse en km/h
( ( mètres du jeu / secondes du jeu ) * 1.943845 ) ; ... vitesse en nœuds
Le problème est le suivant :
Quelque soit la vitesse (stat) du PJ, je n'arrive jamais à atteindre les 1 m/s. Même si la vitesse (stat) du PJ combine différents facteurs, je vois bien dans le jeu que je me déplace très vite.
A 300 par exemple, j'obtiens du 0,280 m/s ; soit, 1,008 km/h. Or, si je place un objet à 100 unités de distance du départ, c'est à dire à 1,42m du PJ, il semble bien visuellement à environ 1,m42 et je le dépasse bien avant l'écoulement d'une seconde. Je comprendrais qu'il y ait des imprécisions de calcul mais avec mes 0,280m/s, je suis très loin du compte !
Je précise que j'ai essayé dans différents lieux, intérieurs et extérieurs, avec des taux de framerate allant de 5 à 96.
Quelqu'un aurait-il une idée d'où peut venir le problème ?
1
Unités Du Jeu - Conversions - Distance - Vitesse
Débuté par
elendell
, 18 nov. 2008 - 06:02
26 réponses à ce sujet
#2
Cogite Stibon
Théoriquement moddeur
Posté 18 novembre 2008 - 06:53
Bonjour Elendell,
Quelques pistes qui pourraient t'aider :
2 frames, ça me semble très court. Les erreurs d'arrondis peuvent avoir un impact important sur des petits nombres. Il vaudrait sans doute mieux faire ces calculs sur des plus grandes distances.
Une première source de distorsion vient peut-être de là : Est-ce que ce le résultat, sur une distance connue, te semble cohérent ?
Il ne faut pas utiliser le timescale ni le gamehour, uniquement le résultat brut du getsecondspassed. En effet, le jeu utilise deux échelles de temps, une pour les actions du PJ, et une pour gérer le calendrier. C'est la première qu'il faut prendre :
Cogite
Quelques pistes qui pourraient t'aider :
Elendell dit :
Je relève les coordonnées x et y du PJ au départ, puis de nouveau 2 frames plus loin.
Elendell dit :
Comme le MSfD indique qu'une unité de jeu = 1.42 cm, je multiplie le résultat obtenu par 0.0142 pour avoir la distance en mètres.
Elendell dit :
Méthode 1) Je démarre un timer au départ et le stoppe au deuxième relevé de position. J'obtiens donc un temps exprimé en secondes réelles que je multiplie par "TimeScale" pour le convertir en secondes du jeu. (Dans le doute, j'ai aussi essayé en divisant par "TimeScale").
Méthode 2) Je fais ( GameHour de l'arrivée - GameHour du départ ) ; en vérifiant au préalable que l'heure d'arrivée est > que celle du départ.
J'obtiens donc un temps exprimé en heure à l'échelle du jeu, que je multiplie par 3600 pour l'avoir en secondes du jeu.
Méthode 2) Je fais ( GameHour de l'arrivée - GameHour du départ ) ; en vérifiant au préalable que l'heure d'arrivée est > que celle du départ.
J'obtiens donc un temps exprimé en heure à l'échelle du jeu, que je multiplie par 3600 pour l'avoir en secondes du jeu.
Cogite Stibon dit :
Les distorsions de la représentation du temps de la fiction
http://img355.imageshack.us/img355/995/temps04bb1.th.jpg
En fait, le temps de la fiction est plus compliqué que cela. Si les journées s’écoulent 12 fois plus vite dans le monde de la fiction que dans le monde réel, cela ne veut pas dire pour autant que les personnages agissent 12 fois plus vite. Par exemple, dégainer son épée prend 2 secondes dans le temps du jeu comme dans celui de la fiction, et un combat qui dure 5 minutes en temps de jeu dure aussi 5 minutes, du point de vue des personnages. Mais en regardant le trajet du soleil, on se rend compte qu’une heure s’est écoulée pendant ces 5 minutes.
Cela ne veut pas dire pour autant que, dans le monde de la fiction, les journées ne durent que 120 minutes. C’est simplement une simplification de la représentation du monde fictif dans le jeu, qui est acceptée naturellement par le joueur. Elle est à rapprocher d’une distorsion équivalente de la représentation de l’espace : les bâtiments sont représentés en vraie grandeur, mais un continent entier ne fait que quelques kilomètres de large, et les grandes villes ne comportent que quelques dizaines de maisons.
Le résultat de tout cela est que le monde fictif peut apparaître incohérent : Le PJ va mettre 2 heures « au soleil » à aller d’une maison à une autre dans le même village, et une journée pour rejoindre la ville voisine, qui paraîtra ridiculement petite. Mais ces contraintes sont imposées à la fois par le média – dans un CRPG, le temps de la fiction doit suivre le point de vue du personnage de façon continue – et la nécessité dramatique – une journée « temps réel » est composée d’énormément de temps morts.
http://img355.imageshack.us/img355/995/temps04bb1.th.jpg
En fait, le temps de la fiction est plus compliqué que cela. Si les journées s’écoulent 12 fois plus vite dans le monde de la fiction que dans le monde réel, cela ne veut pas dire pour autant que les personnages agissent 12 fois plus vite. Par exemple, dégainer son épée prend 2 secondes dans le temps du jeu comme dans celui de la fiction, et un combat qui dure 5 minutes en temps de jeu dure aussi 5 minutes, du point de vue des personnages. Mais en regardant le trajet du soleil, on se rend compte qu’une heure s’est écoulée pendant ces 5 minutes.
Cela ne veut pas dire pour autant que, dans le monde de la fiction, les journées ne durent que 120 minutes. C’est simplement une simplification de la représentation du monde fictif dans le jeu, qui est acceptée naturellement par le joueur. Elle est à rapprocher d’une distorsion équivalente de la représentation de l’espace : les bâtiments sont représentés en vraie grandeur, mais un continent entier ne fait que quelques kilomètres de large, et les grandes villes ne comportent que quelques dizaines de maisons.
Le résultat de tout cela est que le monde fictif peut apparaître incohérent : Le PJ va mettre 2 heures « au soleil » à aller d’une maison à une autre dans le même village, et une journée pour rejoindre la ville voisine, qui paraîtra ridiculement petite. Mais ces contraintes sont imposées à la fois par le média – dans un CRPG, le temps de la fiction doit suivre le point de vue du personnage de façon continue – et la nécessité dramatique – une journée « temps réel » est composée d’énormément de temps morts.
Cogite
Tout droit vers le non-linéaire !
It's not the engine, it's the writing.
HERMA MORA ALTADOON AE
#3
Orann
Nérévarine de Pertevue
Posté 18 novembre 2008 - 08:32
Citation
Citation
Citation (Elendell)
Comme le MSfD indique qu'une unité de jeu = 1.42 cm, je multiplie le résultat obtenu par 0.0142 pour avoir la distance en mètres.
Comme le MSfD indique qu'une unité de jeu = 1.42 cm, je multiplie le résultat obtenu par 0.0142 pour avoir la distance en mètres.
Je ne pense pas pouvoir être d'une grande aide, mais pour vérifier l'ordre de grandeur de l'échelle des unités par rapport à la taille réelle, tu peux prendre la taille des npcs. Je n'ai pas de mesure précise, c'est pour ça que je parle uniquement d'ordre de grandeur.
Je dirais donc, au vu de mon expérience dans 3dsmax, que la hauteur des npcs est d'à peu près 130-135 unités. Si on considère qu'ils font 1,70m, avec un simple produit en croix, on obtient environ 1 unité = 1,3 centimètres. C'est un peu plus petit que ce qu'annonce MSFD mais c'est sûrement dû à l'imprécision de mes valeurs de départ.
Quoi qu'il en soit, ça permet de voir que la valeur donnée dans MSFD se tient. Si on prend cette échelle, les npcs mesure un peu plus d'un mètre 80 en moyenne. C'est sûrement probable vu la grande taille des nordiques, des hauts elfes...
Donc à mon avis, l'erreur ne vient pas de là.
Palme d'honneur 2010 pour le mod Archipel de Pertevue
Entamez votre voyage vers l'Archipel de Pertevue ! Test communautaire en cours.
Entamez votre voyage vers l'Archipel de Pertevue ! Test communautaire en cours.
#4
Kafou
Le canari a bouffé le rominet !
Posté 18 novembre 2008 - 09:11
Je rajouterai qu'il faut faire très attention aux types des variables. Si t'as un type non float quelque part ça peut suffire à faire foirer le reste du calcul.
Il faut aussi développer tes expressions dès lors qu'elles contiennent un appel de fonction (en passant par une variable temporaire où tu stockes le résultat de la fonction).
Il faut aussi développer tes expressions dès lors qu'elles contiennent un appel de fonction (en passant par une variable temporaire où tu stockes le résultat de la fonction).
You look like you need a monkey!
Attention : perfectionniste paresseux.
Attention : perfectionniste paresseux.
#5
elendell
Mécano Dell'Arte
Posté 18 novembre 2008 - 21:16
Bonjour !
J'en ai conscience mais je ne fais pas ce calcul de distance sur 2 frames pour ça. C'est justement parce que j'ai une distance relevée pour une autre raison que j'ai voulu en profiter pour rajouter en bonus l'expression de la vitesse (qui n'est pas nécessaire à mon script).
Une première source de distorsion vient peut-être de là : Est-ce que ce le résultat, sur une distance connue, te semble cohérent ?
Oui, cette indication du MSfD me semble bien cohérente.
Les scripts me poursuivant dans mon sommeil, je me suis justement réveillé avec cette idée mais exprimée autrement (et plus confuse).
C'est d'ailleurs un élément très intéressant à approfondir.
Je me suis dit au réveil qu'en fait, mes résultats sont justes. Dans mon exemple d'hier, le PJ se déplace vraiment à 0,280 m/s à l'échelle du jeu. C'est à dire que dans le jeu, les personnages sont très lents.
Quand on joue, on appréhende l'espace à l'échelle sans difficulté tandis que pour le temps, on continue à le percevoir en temps réel.
Pour qu'il en soit autrement, il faudrait être capable de percevoir le monde 30 fois plus vite (avec TimeScale à 30). Mais aussi de bouger la souris, voir les éléments, appuyer sur les touches, etc. 30 fois plus vite.
Si c'était le cas, on verrait le PJ se déplacer très lentement. C'est sans doute aussi ce qu'on percevrait si on était transportés réellement dans cet espace/temps.
Comme on en est incapable, cela causerait cette distortion dont tu parles. On perçoit l'espace proche du PJ à l'échelle du jeu mais avec une perception du temps qui elle, n'est pas à l'échelle. C'est d'ailleurs fort heureux car sinon, quand on jouerait, le temps nous semblerait bien long (avec les jeux réalisés en tenant compte de ça).
Il me reste donc à vérifier ça (je sais comment) et ensuite à prendre une décision. J'ai en effet trois solutions pour exprimer la vitesse :
1) Indiquer au joueur la vitesse réelle dans le jeu. Dans ce cas, si je dis "vous faites du 1km/h" qui est la vitesse objective, et que le PJ note le temps qu'il met pour traverser l'ile du nord au sud, il s'aperçoit qu'il a bien mis 5h de jeu pour le faire.
Le problème est que cette vitesse est réelle à l'échelle mais qu'elle donnerait au joueur le sentiment d'être fausse. C'est difficile d'admettre qu'on rame alors qu'on a la sensation d'aller très vite. (C'est justement ce qui m'a fait douter de mes résultats).
2) Indiquer au joueur une vitesse subjective. Je n'ai pas fait le calcul mais disons que dans ce cas, j'indiquerais au joueur "vous faites du 30km/h". Cela lui semblerait correspondre à ce qu'il perçoit mais serait en fait faux. S'il sait que l'ile fait 5km du nord au sud, cela causerait cette incohérence qu'il a mis 5h pour traverser l'ile alors qu'il fait du 30km/h.
3) Indiquer au joueur une vitesse exprimée en unités/h. Si je dis au joueur "vous faites du 1000/h", cela lui donnerait l'impression d'aller vite alors qu'en fait cela veut dire "vous faites du 14,2 mètres/h". Le problème de cette solution est qu'il n'y a pas d'expression pour le kilo.
Donc, si le PJ fait du 1,42km/h en temps objectif du jeu, je devrais lui dire "vous faites du 10 000/h". Et du coup, cela semble totalement exagéré et faux.
Quel choix vous semble le meilleur ?
Tu as raison de le rappeler mais j'ai tendance à vérifier de nombreuses fois si toutes mes variables sont bien dans le bon type (surtout quand les résultats me semblent faux). Je vérifie aussi qu'il ne peut pas y avoir de confusion avec d'autres variables et qu'elles ne sont pas utilisées par un autre script.
Je développe les équations dès qu'elles me semblent trop complexes et dans le détail quand ça foire. De même, j'évite d'utiliser des variables globales à l'intérieur, en préférant d'abord mettre la valeur de la globale dans une locale.
Mais je n'avais par contre pas fait le rapprochement avec l'utilisation d'une fonction à l'intérieur de l'équation. C'est une information utile.
Merci à tous pour vos réponses !
Cogite Stibon, le 18.11.2008 à 06:52, dit :
2 frames, ça me semble très court. Les erreurs d'arrondis peuvent avoir un impact important sur des petits nombres. Il vaudrait sans doute mieux faire ces calculs sur des plus grandes distances.
Citation
Citation
Comme le MSfD indique qu'une unité de jeu = 1.42 cm, je multiplie le résultat obtenu par 0.0142 pour avoir la distance en mètres.
Le 18.11.2008 à 08:31 :
Donc à mon avis, l'erreur ne vient pas de là.
Citation
Il ne faut pas utiliser le timescale ni le gamehour, uniquement le résultat brut du getsecondspassed. En effet, le jeu utilise deux échelles de temps, une pour les actions du PJ, et une pour gérer le calendrier. C'est la première qu'il faut prendre :Les distorsions de la représentation du temps de la fiction
C'est d'ailleurs un élément très intéressant à approfondir.
Je me suis dit au réveil qu'en fait, mes résultats sont justes. Dans mon exemple d'hier, le PJ se déplace vraiment à 0,280 m/s à l'échelle du jeu. C'est à dire que dans le jeu, les personnages sont très lents.
Quand on joue, on appréhende l'espace à l'échelle sans difficulté tandis que pour le temps, on continue à le percevoir en temps réel.
Pour qu'il en soit autrement, il faudrait être capable de percevoir le monde 30 fois plus vite (avec TimeScale à 30). Mais aussi de bouger la souris, voir les éléments, appuyer sur les touches, etc. 30 fois plus vite.
Si c'était le cas, on verrait le PJ se déplacer très lentement. C'est sans doute aussi ce qu'on percevrait si on était transportés réellement dans cet espace/temps.
Comme on en est incapable, cela causerait cette distortion dont tu parles. On perçoit l'espace proche du PJ à l'échelle du jeu mais avec une perception du temps qui elle, n'est pas à l'échelle. C'est d'ailleurs fort heureux car sinon, quand on jouerait, le temps nous semblerait bien long (avec les jeux réalisés en tenant compte de ça).
Il me reste donc à vérifier ça (je sais comment) et ensuite à prendre une décision. J'ai en effet trois solutions pour exprimer la vitesse :
1) Indiquer au joueur la vitesse réelle dans le jeu. Dans ce cas, si je dis "vous faites du 1km/h" qui est la vitesse objective, et que le PJ note le temps qu'il met pour traverser l'ile du nord au sud, il s'aperçoit qu'il a bien mis 5h de jeu pour le faire.
Le problème est que cette vitesse est réelle à l'échelle mais qu'elle donnerait au joueur le sentiment d'être fausse. C'est difficile d'admettre qu'on rame alors qu'on a la sensation d'aller très vite. (C'est justement ce qui m'a fait douter de mes résultats).
2) Indiquer au joueur une vitesse subjective. Je n'ai pas fait le calcul mais disons que dans ce cas, j'indiquerais au joueur "vous faites du 30km/h". Cela lui semblerait correspondre à ce qu'il perçoit mais serait en fait faux. S'il sait que l'ile fait 5km du nord au sud, cela causerait cette incohérence qu'il a mis 5h pour traverser l'ile alors qu'il fait du 30km/h.
3) Indiquer au joueur une vitesse exprimée en unités/h. Si je dis au joueur "vous faites du 1000/h", cela lui donnerait l'impression d'aller vite alors qu'en fait cela veut dire "vous faites du 14,2 mètres/h". Le problème de cette solution est qu'il n'y a pas d'expression pour le kilo.
Donc, si le PJ fait du 1,42km/h en temps objectif du jeu, je devrais lui dire "vous faites du 10 000/h". Et du coup, cela semble totalement exagéré et faux.
Quel choix vous semble le meilleur ?
Le 18.11.2008 à 09:10 :
Je rajouterai qu'il faut faire très attention aux types des variables. Si t'as un type non float quelque part ça peut suffire à faire foirer le reste du calcul.
Il faut aussi développer tes expressions dès lors qu'elles contiennent un appel de fonction (en passant par une variable temporaire où tu stockes le résultat de la fonction).
Il faut aussi développer tes expressions dès lors qu'elles contiennent un appel de fonction (en passant par une variable temporaire où tu stockes le résultat de la fonction).
Je développe les équations dès qu'elles me semblent trop complexes et dans le détail quand ça foire. De même, j'évite d'utiliser des variables globales à l'intérieur, en préférant d'abord mettre la valeur de la globale dans une locale.
Mais je n'avais par contre pas fait le rapprochement avec l'utilisation d'une fonction à l'intérieur de l'équation. C'est une information utile.
Merci à tous pour vos réponses !
#6
Kira
Top-modeleuse...
Posté 18 novembre 2008 - 21:59
Bonjour Elendell...
A titre indicatif, il semblerait que le jeu table, pour les animations, sur une base de 15 frames par secondes...
En tous cas, c'est ce qui ressort de l'examen que j'ai fait des meshes, in et outgame...
Je précise cela parce qu'en matière de jeux vidéos, on est plus coutumier de 25 frames/seconde....
A titre indicatif, il semblerait que le jeu table, pour les animations, sur une base de 15 frames par secondes...
En tous cas, c'est ce qui ressort de l'examen que j'ai fait des meshes, in et outgame...
Je précise cela parce qu'en matière de jeux vidéos, on est plus coutumier de 25 frames/seconde....
Tout n'est qu'illusion... Surtout le fait de le penser.....
(Wiwi d'or de la plus serviable et de la plus cool... Merci à vous tous...)
(Wiwi d'or de la plus serviable et de la plus cool... Merci à vous tous...)
#7
Kafou
Le canari a bouffé le rominet !
Posté 18 novembre 2008 - 22:24
Ah oui effectivement, intuitivement je me disais que le PJ devait aller plus vite qu'il ne semble dans le système du jeu, mais c'est l'inverse.
Comme solution je préfère la 2. Ca se justifie en précisant que Vvardenfell est normalement plus grande que dans le jeu (ça va aller les villes de 100m de large et séparées de la voisine par 200m) et que donc les "vraies" distances parcourues ingame sont plus grandes que l'impression qu'on en a.
Il faut donc prendre en compte non seulement l'échelle du temps, mais aussi celle de l'espace. A la louche, ça fait un rapport de 1 sur 10 (avec une Vvardenfell de 50km, ensuite je sais pas combien elle est censée faire en réalité faudrait demander aux spécialistes) et donc ton PJ il va pas à 1km/h mais à 10km/h. Ca fait la vitesse de trot d'un humain, ça reste inférieur au vrai rapport déplacement ingame/temps IRL (avec 300 en speed) mais c'est mieux.
Comme solution je préfère la 2. Ca se justifie en précisant que Vvardenfell est normalement plus grande que dans le jeu (ça va aller les villes de 100m de large et séparées de la voisine par 200m) et que donc les "vraies" distances parcourues ingame sont plus grandes que l'impression qu'on en a.
Il faut donc prendre en compte non seulement l'échelle du temps, mais aussi celle de l'espace. A la louche, ça fait un rapport de 1 sur 10 (avec une Vvardenfell de 50km, ensuite je sais pas combien elle est censée faire en réalité faudrait demander aux spécialistes) et donc ton PJ il va pas à 1km/h mais à 10km/h. Ca fait la vitesse de trot d'un humain, ça reste inférieur au vrai rapport déplacement ingame/temps IRL (avec 300 en speed) mais c'est mieux.
You look like you need a monkey!
Attention : perfectionniste paresseux.
Attention : perfectionniste paresseux.
#8
Von Zeeple
Grille pain Dwemer
Posté 18 novembre 2008 - 23:14
Après t'avoir lu Elendell, j'ai essayé de calculer la vitesse du joueur dans mon coin, et j'ai obtenu des résultats cohérents:
J'ai pris en compte la coordonnée Z, car il suffit d'une légère pente pour modifier significativement la distance parcourue.
Comme toi j'ai pris les coordonnées à chaque frame, j'ai divisé la distance par un getsecondspassed.
Un perso ayant 100 en vitesse coure à 4,2 m/s, ce qui est cohérent.
Mon perso ayant 66, il faisait du 1,6m/s en marchant. C'est des grandes foulées mais avec un 66 en vitesse ça peut l faire.
En fait c'est peut être la vitesse des perso qui est exagérée.
Et c'est compréhensible, aucun joueur n'a envie de passer 1/4 d'heure à traverser une ville.
Mais j'y pense, il est peut être possible, connaissant la masse du joueur, en le faisant chuter d'une hauteur donnée, de chronométrer sa chute pour en déduire "g", la constante de gravitation de Nirn.
Et pas la même occasion de déterminer M, la masse de Nirn, ( en supposant que G, la constante de gravitation universelle, est la même que dans notre monde ).
EDIT: ton, problème venait peut-être du fait que tu divisais la distance par Getsecondspassed alors qu'il y avait plus d'une seule frame de passée.
RE-EDIT:
Pour ma part je préfèrerais avoir une vitesse "réelle", même si cela révèle le fait que l'île soit petite et que le temps est accélèré.
Une autre solution serait de créer une unité, par exemple 1Bidule = 1420 unités/s ( vous allez à 10 bidules )
J'ai modifier mon script pour qu'il calcule l'accélération du PJ, ça semble marcher puisque lorsqu'il marche a vitesse constante en ligne droite, son accélération tourne autour de 0.
Si j'ai le temps demain matin, je ferais un nouveau topic pour parler des différentes grandeurs physiques et voir si on peut calculer quelques constantes...comme g ou G...
begin "GDI_compteur_vitesse_script" float posX float posY float posZ float posX2 float posY2 float posZ2 float distX float distY float distZ float distance float speed if ( menumode == 1 ) return endif set posX2 to posX set posY2 to posY set posZ2 to posZ set posX to "player"->getpos x set posY to "player"->getpos y set posZ to "player"->getpos z set distX to ( posX - posX2 ) set distY to ( posY - posY2 ) set distZ to ( posZ - posZ2 ) set distX to ( distX * 0.0142 ) set distY to ( distY * 0.0142 ) set distZ to ( distZ * 0.0142 ) set distance to ( ( distX * distX ) + ( distY * distY ) + ( distZ * distZ ) ) set distance to getsquareroot distance set speed to ( distance / getsecondspassed ) messagebox "Vous faites du %f m/s " speed end
J'ai pris en compte la coordonnée Z, car il suffit d'une légère pente pour modifier significativement la distance parcourue.
Comme toi j'ai pris les coordonnées à chaque frame, j'ai divisé la distance par un getsecondspassed.
Un perso ayant 100 en vitesse coure à 4,2 m/s, ce qui est cohérent.
Mon perso ayant 66, il faisait du 1,6m/s en marchant. C'est des grandes foulées mais avec un 66 en vitesse ça peut l faire.
En fait c'est peut être la vitesse des perso qui est exagérée.
Et c'est compréhensible, aucun joueur n'a envie de passer 1/4 d'heure à traverser une ville.
Mais j'y pense, il est peut être possible, connaissant la masse du joueur, en le faisant chuter d'une hauteur donnée, de chronométrer sa chute pour en déduire "g", la constante de gravitation de Nirn.
Et pas la même occasion de déterminer M, la masse de Nirn, ( en supposant que G, la constante de gravitation universelle, est la même que dans notre monde ).
EDIT: ton, problème venait peut-être du fait que tu divisais la distance par Getsecondspassed alors qu'il y avait plus d'une seule frame de passée.
RE-EDIT:
Citation
Quel choix vous semble le meilleur ?
Pour ma part je préfèrerais avoir une vitesse "réelle", même si cela révèle le fait que l'île soit petite et que le temps est accélèré.
Une autre solution serait de créer une unité, par exemple 1Bidule = 1420 unités/s ( vous allez à 10 bidules )
J'ai modifier mon script pour qu'il calcule l'accélération du PJ, ça semble marcher puisque lorsqu'il marche a vitesse constante en ligne droite, son accélération tourne autour de 0.
Si j'ai le temps demain matin, je ferais un nouveau topic pour parler des différentes grandeurs physiques et voir si on peut calculer quelques constantes...comme g ou G...
Modifié par Von Zeeple, 18 novembre 2008 - 23:50.
Le Steampunk, c'est bon, mangez en !
#9
elendell
Mécano Dell'Arte
Posté 19 novembre 2008 - 01:02
Hello !
C'est bien de le savoir. En fait, pour d'autres points de mon script, j'avais tout calculé sans tenir compte du framerate.
Puis, en le testant dans une autre cellule, je me suis aperçu qu'il ne fonctionnait plus. La raison était simple. J'avais établi mes valeurs en fonction de relevés effectués à une moyenne de 12 frames/s. Ma deuxième cellule ayant 60 frames/s en moyenne, cela ne collait plus. Puis, j'ai réalisé que je devais faire autrement car dans une troisième cellule, le framerate passait de 5 à 60, simplement en changeant d'angle de vue. Donc, je fais autrement.
Ce que tu obtiens va justement avec mes calculs. La vitesse que tu trouves et le choix que tu fais correspondent à la deuxième solution de mon dernier message. C'est à dire qu'il s'agit de la vitesse que je nomme "subjective".
Ton PJ va à 5,76km/h en marchant. Mais si tu traverses l'ile du nord au sud, tu t'apercevras qu'il t'aura fallu plus d'une heure dans le jeu alors que la distance est de 5kms.
C'est d'ailleurs, je pense, la solution que je vais adopter. Elle colle avec les observations de Cogite, la préférence de Kafou et c'est celle que tu as automatiquement utilisé. C'est aussi celle qui va le mieux avec la sensation du joueur, même si en fait c'est la seule des 3 solutions qui soit fausse. Mon seul regret est qu'on ne puisse pas utiliser directement dans une quête la vitesse exprimée. Par exemple : "A l'allure ou vous marchez, dans une heure vous serez au lieu du trésor.". Si le modeur fait ça, il ne doit pas placer le trésor à 5,76kms (traduits en unités) mais bien plus loin. Mais ce n'est qu'un détail et le modeur peut toujours le résoudre par un calcul ou en donnant au PJ un instrument de mesure adapté.
Oui, il faut le prendre en compte. Je ne l'ai pas fait dans mes exemples car z ne changeait pas mais j'avais aussi essayé avec un z changeant.
Juste pour n'induire personne en erreur : La valeur stat Speed du PJ n'indique pas sa vitesse mais juste un élément entrant dans son calcul. (Celui sur lequel on agit le plus facilement par script).
La vitesse est également déterminée par certaines compétences comme l'athlétisme et aussi l'encombrement. De plus, il y a une fourchette mini/maxi indépendante des stats, compétences ou encombrement ainsi que des coefficients multiplicateurs différents ou cumulés, suivant si le PJ court, marche, nage ou vole. Bref, suivant les circonstances, le PJ peut avoir un speed à 100 et se trainer comme une limace.
Là, je ne suis pas sûr de comprendre. Il faudrait d'abord que j'étudie ce que sont la masse et la gravitation. Mais j'ai demandé à mon PJ s'il voulait bien que je le jette d'une falaise pour prendre des mesures et il n'avait pas l'air d'être d'accord ! 
Non, le framerate n'entrait pas en ligne de compte. Je l'ai d'ailleurs vérifié plusieurs fois. Il s'agissait bien, je crois, d'un problème de perception espace/temps.
EDIT (suite à celui de Von Zeeple) :
Le choix est effectivement difficile et j'ai aussi tendance à préférer la réalité mais on est dans un jeu.
Le choix peut bien sûr être laissé au modeurs. La seule chose qui me tracasse, c'est d'adopter celui que préfèrerait le plus grand nombre, car si un modeur exprime la vitesse d'une manière et un autre modeur d'une autre façon, il y aurait de quoi perturber le joueur ayant les deux "mods". Donc, quitte à établir un précédent, autant qu'il soit le plus judicieux possible. Soit pour ce qu'on peut faire avec l'expression d'une vitesse, soit parce que c'est plus ludique dans le jeu.
C'est ce que fait en quelque sorte l'unité du jeu. On peut effectivement en créer une nouvelle pour qu'elle soit plus proche de nos habitudes de penser en kms mais elle ne servirait que pour un "mod".
EDIT 2 :
Von, ton script ne va pas chez moi. Je me doute qu'il n'est pas affiné mais la mesure que l'on obtient n'est jamais la même.
C'est logique puisque la mesure de la distance est liée au framerate alors que celle du temps ne l'est pas. Même avec une seule frame, le temps qui sépare la frame 0 de la frame 1 n'est jamais le même.
Je n'ai pas eu de problèmes de framerate dans mes autres essais mais les distances et les temps relevés étaient toujours liés au framerate. Avec cette solution, il faut donc faire intervenir la mesure du framerate mais je ne sais pas encore comment. J'ai essayé mais sans succès.
Kira, le 18.11.2008 à 21:58, dit :
A titre indicatif, il semblerait que le jeu table, pour les animations, sur une base de 15 frames par secondes...
Puis, en le testant dans une autre cellule, je me suis aperçu qu'il ne fonctionnait plus. La raison était simple. J'avais établi mes valeurs en fonction de relevés effectués à une moyenne de 12 frames/s. Ma deuxième cellule ayant 60 frames/s en moyenne, cela ne collait plus. Puis, j'ai réalisé que je devais faire autrement car dans une troisième cellule, le framerate passait de 5 à 60, simplement en changeant d'angle de vue. Donc, je fais autrement.
Von Zeeple, le 18.11.2008 à 23:13, dit :
Après t'avoir lu Elendell, j'ai essayé de calculer la vitesse du joueur dans mon coin, et j'ai obtenu des résultats cohérents
Ton PJ va à 5,76km/h en marchant. Mais si tu traverses l'ile du nord au sud, tu t'apercevras qu'il t'aura fallu plus d'une heure dans le jeu alors que la distance est de 5kms.
C'est d'ailleurs, je pense, la solution que je vais adopter. Elle colle avec les observations de Cogite, la préférence de Kafou et c'est celle que tu as automatiquement utilisé. C'est aussi celle qui va le mieux avec la sensation du joueur, même si en fait c'est la seule des 3 solutions qui soit fausse. Mon seul regret est qu'on ne puisse pas utiliser directement dans une quête la vitesse exprimée. Par exemple : "A l'allure ou vous marchez, dans une heure vous serez au lieu du trésor.". Si le modeur fait ça, il ne doit pas placer le trésor à 5,76kms (traduits en unités) mais bien plus loin. Mais ce n'est qu'un détail et le modeur peut toujours le résoudre par un calcul ou en donnant au PJ un instrument de mesure adapté.
Von Zeeple, le 18.11.2008 à 23:13, dit :
J'ai pris en compte la coordonnée Z, car il suffit d'une légère pente pour modifier significativement la distance parcourue.
Von Zeeple, le 18.11.2008 à 23:13, dit :
Un perso ayant 100 en vitesse coure à 4,2 m/s, ce qui est cohérent...
En fait c'est peut être la vitesse des perso qui est exagérée.
En fait c'est peut être la vitesse des perso qui est exagérée.
La vitesse est également déterminée par certaines compétences comme l'athlétisme et aussi l'encombrement. De plus, il y a une fourchette mini/maxi indépendante des stats, compétences ou encombrement ainsi que des coefficients multiplicateurs différents ou cumulés, suivant si le PJ court, marche, nage ou vole. Bref, suivant les circonstances, le PJ peut avoir un speed à 100 et se trainer comme une limace.
Von Zeeple, le 18.11.2008 à 23:13, dit :
Mais j'y pense, il est peut être possible, connaissant la masse du joueur, en le faisant chuter d'une hauteur donnée, de chronométrer sa chute pour en déduire "g", la constante de gravitation de Nirn.
Et pas la même occasion de déterminer M, la masse de Nirn, ( en supposant que G, la constante de gravitation universelle, est la même que dans notre monde ).
Et pas la même occasion de déterminer M, la masse de Nirn, ( en supposant que G, la constante de gravitation universelle, est la même que dans notre monde ).
Von Zeeple, le 18.11.2008 à 23:13, dit :
EDIT: ton, problème venait peut-être du fait que tu divisais la distance par Getsecondspassed alors qu'il y avait plus d'une seule frame de passée.
EDIT (suite à celui de Von Zeeple) :
Citation
Pour ma part je préfèrerais avoir une vitesse "réelle", même si cela révèle le fait que l'île soit petite et que le temps est accélèré.
Le choix peut bien sûr être laissé au modeurs. La seule chose qui me tracasse, c'est d'adopter celui que préfèrerait le plus grand nombre, car si un modeur exprime la vitesse d'une manière et un autre modeur d'une autre façon, il y aurait de quoi perturber le joueur ayant les deux "mods". Donc, quitte à établir un précédent, autant qu'il soit le plus judicieux possible. Soit pour ce qu'on peut faire avec l'expression d'une vitesse, soit parce que c'est plus ludique dans le jeu.
Citation
Une autre solution serait de créer une unité, par exemple 1Bidule = 1420 unités/s ( vous allez à 10 bidules )
EDIT 2 :
Von, ton script ne va pas chez moi. Je me doute qu'il n'est pas affiné mais la mesure que l'on obtient n'est jamais la même.
C'est logique puisque la mesure de la distance est liée au framerate alors que celle du temps ne l'est pas. Même avec une seule frame, le temps qui sépare la frame 0 de la frame 1 n'est jamais le même.
Je n'ai pas eu de problèmes de framerate dans mes autres essais mais les distances et les temps relevés étaient toujours liés au framerate. Avec cette solution, il faut donc faire intervenir la mesure du framerate mais je ne sais pas encore comment. J'ai essayé mais sans succès.
#10
Von Zeeple
Grille pain Dwemer
Posté 19 novembre 2008 - 08:17
Citation
C'est logique puisque la mesure de la distance est liée au framerate alors que celle du temps ne l'est pas. Même avec une seule frame, le temps qui sépare la frame 0 de la frame 1 n'est jamais le même.
Hmmm en effet, j'ai effectué mes test dans une cell intérieure, donc je n'ai pas eu trop de problème de framerate...
En fait il faudrait faire une moyenne sur plusieurs frame...Mais il faut s'assurer que le joueur parcoure bien la même distance à chaque frame.
Edit: la distance parcourue par frame dépend du nombre de frame, c'est surement parce que la position du PJ est calculée par le jeu avec un getsecondspassed, il faudrait donc bien diviser la distance par un getsecondspassed pour avoir la meilleure approximation, mais si la vitesse est très fluctuante...
Re-Edit: Après expérience, en utilisant le script ci-dessus, mon perso avance à environ 3,5m/s en courant, que ce soit avec 15 ou 9 de frame-rate.
Modifié par Von Zeeple, 19 novembre 2008 - 08:39.
Le Steampunk, c'est bon, mangez en !
#11
Kafou
Le canari a bouffé le rominet !
Posté 19 novembre 2008 - 09:21
Normalement y'a pas le problème dont vous parlez... mais en effet faire une moyenne sur les frames est préférable, pour éviter des erreurs de précision (et avoir un chiffre qui évolue de façon plus fluide).
Ben si, c'est GetSecondsPassed (qui ne renvoie jamais le même résultat, mais représente justement le temps qui sépare la frame 0 de la frame 1...).
Edit : Un conseil pour Von Zeeple : multiplie le résultat par 0.0142 et non chaque composante du déplacement, le résultat sera meilleur a priori (on traite de toutes petites valeurs dès qu'on a un haut framerate, aussi bien pour le déplacement que pour le temps, et la précision des flottants - environ 6 à 7 décimales - peut ne pas suffire, donc autant éviter de les rendre encore plus petites inutilement).
Citation
C'est logique puisque la mesure de la distance est liée au framerate alors que celle du temps ne l'est pas. Même avec une seule frame, le temps qui sépare la frame 0 de la frame 1 n'est jamais le même.
Edit : Un conseil pour Von Zeeple : multiplie le résultat par 0.0142 et non chaque composante du déplacement, le résultat sera meilleur a priori (on traite de toutes petites valeurs dès qu'on a un haut framerate, aussi bien pour le déplacement que pour le temps, et la précision des flottants - environ 6 à 7 décimales - peut ne pas suffire, donc autant éviter de les rendre encore plus petites inutilement).
You look like you need a monkey!
Attention : perfectionniste paresseux.
Attention : perfectionniste paresseux.
#12
Cogite Stibon
Théoriquement moddeur
Posté 19 novembre 2008 - 14:45
Kafou, le 19.11.2008 à 09:20, dit :
Normalement y'a pas le problème dont vous parlez... mais en effet faire une moyenne sur les frames est préférable, pour éviter des erreurs de précision (et avoir un chiffre qui évolue de façon plus fluide).
Ben si, c'est GetSecondsPassed (qui ne renvoie jamais le même résultat, mais représente justement le temps qui sépare la frame 0 de la frame 1...).
Edit : Un conseil pour Von Zeeple : multiplie le résultat par 0.0142 et non chaque composante du déplacement, le résultat sera meilleur a priori (on traite de toutes petites valeurs dès qu'on a un haut framerate, aussi bien pour le déplacement que pour le temps, et la précision des flottants - environ 6 à 7 décimales - peut ne pas suffire, donc autant éviter de les rendre encore plus petites inutilement).
Citation
C'est logique puisque la mesure de la distance est liée au framerate alors que celle du temps ne l'est pas. Même avec une seule frame, le temps qui sépare la frame 0 de la frame 1 n'est jamais le même.
Edit : Un conseil pour Von Zeeple : multiplie le résultat par 0.0142 et non chaque composante du déplacement, le résultat sera meilleur a priori (on traite de toutes petites valeurs dès qu'on a un haut framerate, aussi bien pour le déplacement que pour le temps, et la précision des flottants - environ 6 à 7 décimales - peut ne pas suffire, donc autant éviter de les rendre encore plus petites inutilement).
le getsecondspassed indique le nombre de secondes écoulée depuis la dernière frame. Et la distance parcouru entre deux frame dépend varie dans les même proportion. Donc l'influence du framerate s'annule.
Pour les arrondis, si on est à 30fps, et que le PJ marche à 1m/s, il parcoure environ 3 cm en une frame. Mais comme le "pas" minimum de déplacement est de 1,4cm, on a une imprécision de 50% sur la distance parcourue, et donc la vitesse. En faisant une moyenne sur 10 frame, cette imprécision tombe à 5%.
elendell, le 19.11.2008 à 01:01, dit :
Ce que tu obtiens va justement avec mes calculs. La vitesse que tu trouves et le choix que tu fais correspondent à la deuxième solution de mon dernier message. C'est à dire qu'il s'agit de la vitesse que je nomme "subjective".
Ton PJ va à 5,76km/h en marchant. Mais si tu traverses l'ile du nord au sud, tu t'apercevras qu'il t'aura fallu plus d'une heure dans le jeu alors que la distance est de 5kms.
C'est d'ailleurs, je pense, la solution que je vais adopter. Elle colle avec les observations de Cogite, la préférence de Kafou et c'est celle que tu as automatiquement utilisé. C'est aussi celle qui va le mieux avec la sensation du joueur, même si en fait c'est la seule des 3 solutions qui soit fausse. Mon seul regret est qu'on ne puisse pas utiliser directement dans une quête la vitesse exprimée. Par exemple : "A l'allure ou vous marchez, dans une heure vous serez au lieu du trésor.". Si le modeur fait ça, il ne doit pas placer le trésor à 5,76kms (traduits en unités) mais bien plus loin. Mais ce n'est qu'un détail et le modeur peut toujours le résoudre par un calcul ou en donnant au PJ un instrument de mesure adapté.
Ton PJ va à 5,76km/h en marchant. Mais si tu traverses l'ile du nord au sud, tu t'apercevras qu'il t'aura fallu plus d'une heure dans le jeu alors que la distance est de 5kms.
C'est d'ailleurs, je pense, la solution que je vais adopter. Elle colle avec les observations de Cogite, la préférence de Kafou et c'est celle que tu as automatiquement utilisé. C'est aussi celle qui va le mieux avec la sensation du joueur, même si en fait c'est la seule des 3 solutions qui soit fausse. Mon seul regret est qu'on ne puisse pas utiliser directement dans une quête la vitesse exprimée. Par exemple : "A l'allure ou vous marchez, dans une heure vous serez au lieu du trésor.". Si le modeur fait ça, il ne doit pas placer le trésor à 5,76kms (traduits en unités) mais bien plus loin. Mais ce n'est qu'un détail et le modeur peut toujours le résoudre par un calcul ou en donnant au PJ un instrument de mesure adapté.
En fait, c'est la seule mesure qui soit juste. Les distances, comme le temps, subissent des distorsions importantes dès que l'on quitte une échelle "locale", et ces distorsion n'ont absolument pas été prévues pour donner des vitesses cohérentes.
Je m'explique : à petite échelle, on peut prendre comme échelle le référence de taille le "bonhomme", soit la taille moyenne d'un PNJ, qu'on estime être à environ 1m70. On constate alors que les objets à petite échelle (une objet, un animal, un meuble, une maison) ont des rapports d'échelle cohérent : une table fait environ 1/2 "bonhomme" de haut, une maison environ 2 "bonhommes", etc. Les vitesses de déplacement le sont aussi : le PJ parcoure une distance d'environ 1 "bonhomme" dans le temps qu'il faut à un garde pour dire "Que voulez-vous ?", soit environ 2 secondes. Ceci a été soigneusement étudié par Bethesda, pour donner au joueur l'impression d'un monde réaliste.
Dès que l'on s'écarte de ces petites échelles (de l'ordre du "bonhomme" en distance et de la durée du "Que voulez-vous ? " en temps), les distorsions commencent. Une journée s'écoule en 1 heure et demi, une grande ville ne comporte que quelques dizaines de maisons et ne s'étend que sur quelque centaines de mêtres, l'île complète peut être traversée à pied en très peu de temps. Ces distorsions ne sont absolument pas uniforme : si on fait le ratio entre la taille représentée de Balmora, et la taille qu'elle devrait avoir "en vrai", on n'obtiendra surement pas le même nombre que si on fait le même travail pour l'île entière. La preuve en est que, par exemple, Gnisis fait a peu près la même taille que Hla Hoad dans le jeu, alors que l'une est une grande ville et l'autre un petit village, et qu'en vrai, l'une devrait être au moins 10 fois plus grande que l'autre.
Ces distorsions d'échelles ont été conçues dans un but d'améliorer le gameplay (le joueur, dans le cadre d'une sessions de jeu de 2h, doit avoir une perception claire de l'écoulement de la journée. Il ne doit pas passer des heures à parcourir des dizaines de kilomètres de campagne vide), et technique (limitation du nombre d'objets pouvant être créés). Pas du tout dans le but d'avoir une représentation des distances réalistes, car cela a très peu d'impact sur l'expérience du joueur.
Cogite
Tout droit vers le non-linéaire !
It's not the engine, it's the writing.
HERMA MORA ALTADOON AE
#13
Kira
Top-modeleuse...
Posté 19 novembre 2008 - 15:09
Bonjour...
Je viens d'examiner précisément l'animation de marche, et il en résulte qu'un pas du personnage (c'est à dire entre le moment où son pied quitte le sol et celui où il y retourne) prend très exactement 14 frames et représente un déplacement de 70 unités...
Je ne sais pas si ça peut vous être utile, mais je pense que c'est quand même bon à savoir, juste dans un but de précision...
Je viens d'examiner précisément l'animation de marche, et il en résulte qu'un pas du personnage (c'est à dire entre le moment où son pied quitte le sol et celui où il y retourne) prend très exactement 14 frames et représente un déplacement de 70 unités...
Je ne sais pas si ça peut vous être utile, mais je pense que c'est quand même bon à savoir, juste dans un but de précision...
Tout n'est qu'illusion... Surtout le fait de le penser.....
(Wiwi d'or de la plus serviable et de la plus cool... Merci à vous tous...)
(Wiwi d'or de la plus serviable et de la plus cool... Merci à vous tous...)
#14
Kafou
Le canari a bouffé le rominet !
Posté 19 novembre 2008 - 15:15
Cogite Stibon, le 19.11.2008 à 14:44, dit :
Pour les arrondis, si on est à 30fps, et que le PJ marche à 1m/s, il parcoure environ 3 cm en une frame. Mais comme le "pas" minimum de déplacement est de 1,4cm, on a une imprécision de 50% sur la distance parcourue, et donc la vitesse. En faisant une moyenne sur 10 frame, cette imprécision tombe à 5%.
Citation
Je viens d'examiner précisément l'animation de marche, et il en résulte qu'un pas du personnage (c'est à dire entre le moment où son pied quitte le sol et celui où il y retourne) prend très exactement 14 frames et représente un déplacement de 70 unités...
).
You look like you need a monkey!
Attention : perfectionniste paresseux.
Attention : perfectionniste paresseux.
#15
Cogite Stibon
Théoriquement moddeur
Posté 19 novembre 2008 - 17:40
Kafou, le 19.11.2008 à 15:14, dit :
Cogite Stibon, le 19.11.2008 à 14:44, dit :
Pour les arrondis, si on est à 30fps, et que le PJ marche à 1m/s, il parcoure environ 3 cm en une frame. Mais comme le "pas" minimum de déplacement est de 1,4cm, on a une imprécision de 50% sur la distance parcourue, et donc la vitesse. En faisant une moyenne sur 10 frame, cette imprécision tombe à 5%.
Tout droit vers le non-linéaire !
It's not the engine, it's the writing.
HERMA MORA ALTADOON AE
#16
Kafou
Le canari a bouffé le rominet !
Posté 19 novembre 2008 - 20:16
Je viens de tester, c'est bien des valeurs flottantes qui sont retournées.
Au passage je précise, le flottant comprend tous les entiers jusqu'à (-) 8 millions, donc c'est au-delà de 8 millions d'unités que ça va commencer à être dur de positionner des objets correctement (de 8 à 16 millions la précision est de 2, de 16 à 32 elle est de 4, etc.).
Avec au moins 70 unités (1m) par seconde, et au plus 70 FPS (ce qui doit être faisable en extérieur ^^) on obtient donc une estimation du déplacement fiable à la frame et à l'unité près jusqu'à 8 millions d'unités (113km, 1024 cellules) du centre de Vvardenfell !
Au passage je précise, le flottant comprend tous les entiers jusqu'à (-) 8 millions, donc c'est au-delà de 8 millions d'unités que ça va commencer à être dur de positionner des objets correctement (de 8 à 16 millions la précision est de 2, de 16 à 32 elle est de 4, etc.).
Avec au moins 70 unités (1m) par seconde, et au plus 70 FPS (ce qui doit être faisable en extérieur ^^) on obtient donc une estimation du déplacement fiable à la frame et à l'unité près jusqu'à 8 millions d'unités (113km, 1024 cellules) du centre de Vvardenfell !
You look like you need a monkey!
Attention : perfectionniste paresseux.
Attention : perfectionniste paresseux.
#17
elendell
Mécano Dell'Arte
Posté 20 novembre 2008 - 02:27
Hummmm... Je suis très fatigué et j'ai du mal à continuer le raisonnement. Je vais donc laisser passer les quelques jours de travail intense (professionnel) que je dois fournir, pour pouvoir de nouveau réfléchir correctement sur le sujet. Je vous tiendrai au courant.
Pour le moment, j'ai effectivement compris pourquoi le framerate ne jouait pas. Par contre, si je peux suivre le raisonnement de Cogite sur les distortions, je ne peux pas l'appréhender totalement pour l'instant. Il faudra sans doute que je prenne des mesures sur le terrain pour me convaincre de sa véracité. Mais pour ça, il faudrait d'abord que je fasse des scripts spécialement dédiés à ces mesures.
Le script de Von Zeeple par contre ne fonctionne pas chez moi. Je veux dire que les mesures que j'obtiens ne sont jamais les mêmes, en étant dans la même cellule intérieure et sans changer le speed.
Avec un speed à 100 par exemple, j'obtiens en marchant des mesures qui vont de 0,5 m/s à plus de 5 m/s ; et ça change tout le temps. Je ne vois donc pas comment on peut en déduire une vitesse. Je précise que je lis les mesures en ouvrant les menus pour stopper le script car sinon, il n'est pas possible de lire l'affichage des messagebox.
J'ai aussi essayé en laissant passer 10 frames entre les deux relevés de position, puis affichage du résultat pendant quelques secondes (sans avoir besoin d'ouvrir les menus). Mais ça ne change rien. La fourchette mini/maxi entre les différents essais au même endroit reste large.
Je me demande donc, puisque le framerate ne joue pas, qu'est-ce qui peut faire que les mesures ne sont jamais les mêmes.
Je précise aussi que si je vais dans une cellule avec un framerate bien différent, je n'obtiens pas la même fourchette de mesures (avec le même speed). Ce qui tendrait à démentir le fait que le framerate ne joue pas, alors que pourtant, je comprends l'explication de Kafou et de Cogite sur ce propos.
Une question aussi que je me pose quand à l'animation du PJ : Est-ce que la vitesse de déplacement du centre du PJ est linéaire lors de la marche (identique quelque soit le le stade de l'animation) ? Si c'est le cas, pas de problème mais sinon, cela expliquerait que les mesures ne soient jamais les mêmes. Dans ce dernier cas, on ne pourrait alors savoir vraiment la vitesse qu'en laissant passer un cycle complet qui forme l'animation d'un pas (les 14 frames indiquées par Kira).
Bref, je ne suis pas sorti de l'auberge...
Pour le moment, j'ai effectivement compris pourquoi le framerate ne jouait pas. Par contre, si je peux suivre le raisonnement de Cogite sur les distortions, je ne peux pas l'appréhender totalement pour l'instant. Il faudra sans doute que je prenne des mesures sur le terrain pour me convaincre de sa véracité. Mais pour ça, il faudrait d'abord que je fasse des scripts spécialement dédiés à ces mesures.
Le script de Von Zeeple par contre ne fonctionne pas chez moi. Je veux dire que les mesures que j'obtiens ne sont jamais les mêmes, en étant dans la même cellule intérieure et sans changer le speed.
Avec un speed à 100 par exemple, j'obtiens en marchant des mesures qui vont de 0,5 m/s à plus de 5 m/s ; et ça change tout le temps. Je ne vois donc pas comment on peut en déduire une vitesse. Je précise que je lis les mesures en ouvrant les menus pour stopper le script car sinon, il n'est pas possible de lire l'affichage des messagebox.
J'ai aussi essayé en laissant passer 10 frames entre les deux relevés de position, puis affichage du résultat pendant quelques secondes (sans avoir besoin d'ouvrir les menus). Mais ça ne change rien. La fourchette mini/maxi entre les différents essais au même endroit reste large.
Je me demande donc, puisque le framerate ne joue pas, qu'est-ce qui peut faire que les mesures ne sont jamais les mêmes.
Je précise aussi que si je vais dans une cellule avec un framerate bien différent, je n'obtiens pas la même fourchette de mesures (avec le même speed). Ce qui tendrait à démentir le fait que le framerate ne joue pas, alors que pourtant, je comprends l'explication de Kafou et de Cogite sur ce propos.
Une question aussi que je me pose quand à l'animation du PJ : Est-ce que la vitesse de déplacement du centre du PJ est linéaire lors de la marche (identique quelque soit le le stade de l'animation) ? Si c'est le cas, pas de problème mais sinon, cela expliquerait que les mesures ne soient jamais les mêmes. Dans ce dernier cas, on ne pourrait alors savoir vraiment la vitesse qu'en laissant passer un cycle complet qui forme l'animation d'un pas (les 14 frames indiquées par Kira).
Bref, je ne suis pas sorti de l'auberge...
#18
Kafou
Le canari a bouffé le rominet !
Posté 20 novembre 2008 - 09:01
elendell, le 20.11.2008 à 02:26, dit :
Une question aussi que je me pose quand à l'animation du PJ : Est-ce que la vitesse de déplacement du centre du PJ est linéaire lors de la marche (identique quelque soit le le stade de l'animation) ?
You look like you need a monkey!
Attention : perfectionniste paresseux.
Attention : perfectionniste paresseux.
#19
Cogite Stibon
Théoriquement moddeur
Posté 21 novembre 2008 - 00:02
elendell, le 20.11.2008 à 02:26, dit :
Le script de Von Zeeple par contre ne fonctionne pas chez moi. Je veux dire que les mesures que j'obtiens ne sont jamais les mêmes, en étant dans la même cellule intérieure et sans changer le speed.
Avec un speed à 100 par exemple, j'obtiens en marchant des mesures qui vont de 0,5 m/s à plus de 5 m/s ; et ça change tout le temps. Je ne vois donc pas comment on peut en déduire une vitesse. Je précise que je lis les mesures en ouvrant les menus pour stopper le script car sinon, il n'est pas possible de lire l'affichage des messagebox.
J'ai aussi essayé en laissant passer 10 frames entre les deux relevés de position, puis affichage du résultat pendant quelques secondes (sans avoir besoin d'ouvrir les menus). Mais ça ne change rien. La fourchette mini/maxi entre les différents essais au même endroit reste large.
Je me demande donc, puisque le framerate ne joue pas, qu'est-ce qui peut faire que les mesures ne sont jamais les mêmes.
Je précise aussi que si je vais dans une cellule avec un framerate bien différent, je n'obtiens pas la même fourchette de mesures (avec le même speed). Ce qui tendrait à démentir le fait que le framerate ne joue pas, alors que pourtant, je comprends l'explication de Kafou et de Cogite sur ce propos.
Avec un speed à 100 par exemple, j'obtiens en marchant des mesures qui vont de 0,5 m/s à plus de 5 m/s ; et ça change tout le temps. Je ne vois donc pas comment on peut en déduire une vitesse. Je précise que je lis les mesures en ouvrant les menus pour stopper le script car sinon, il n'est pas possible de lire l'affichage des messagebox.
J'ai aussi essayé en laissant passer 10 frames entre les deux relevés de position, puis affichage du résultat pendant quelques secondes (sans avoir besoin d'ouvrir les menus). Mais ça ne change rien. La fourchette mini/maxi entre les différents essais au même endroit reste large.
Je me demande donc, puisque le framerate ne joue pas, qu'est-ce qui peut faire que les mesures ne sont jamais les mêmes.
Je précise aussi que si je vais dans une cellule avec un framerate bien différent, je n'obtiens pas la même fourchette de mesures (avec le même speed). Ce qui tendrait à démentir le fait que le framerate ne joue pas, alors que pourtant, je comprends l'explication de Kafou et de Cogite sur ce propos.
elendell, le 20.11.2008 à 02:26, dit :
Pour le moment, j'ai effectivement compris pourquoi le framerate ne jouait pas. Par contre, si je peux suivre le raisonnement de Cogite sur les distortions, je ne peux pas l'appréhender totalement pour l'instant. Il faudra sans doute que je prenne des mesures sur le terrain pour me convaincre de sa véracité. Mais pour ça, il faudrait d'abord que je fasse des scripts spécialement dédiés à ces mesures.
Je viens de faire des mesures de la "taille" de certaines villes, à titre d'exemple (par taille je veux dire la distance entre les deux points les plus éloignés de la ville). J'ai fait ça très simplement, en rajoutant l'affichage des PosX et PosY dans le script de Von Zeeple, et en faisant le calcul dans un tableau Excell.
J'obtiens :
Hla Oad (petit village) : environ 70m
Seyda Nihyn (village) : environ 100m
Gnisis (ville moyenne) : environ 150m
Balmora (grande ville) : environ 190 m
Vivec (capitale) : environ 490m
Cogite
Edit après avoir dormi :
j'ai fait mes tests avec une nouvelle install sans aucun mod, sur une machine rapide. J'avais donc un fps supérieur à 80 tout le temps. J'ai une hypothèse pour expliquer nos différence de résultats, si tu as un fps nettement plus bas. Ce serait que le fps influe, mais de façon plus subtile que ce que l'on imaginait au départ : Plus le FPS serait bas, plus le temps d'exécution des scripts et autre introduirait de l'imprécision dans le résultat du getsecondspassed. Essaye de faire une moyenne sur 100 frame pour voir si c'est plus stable.
Spoiler
Pour mes distance, si le rapport d'échelle était cohérent avec le timescale, on devrait avoir, comme "vraie taille" pour chacune des villes la même taille multipliée par le timescale, soit 30 :
Hla Oad (petit village) : environ 70m ==> 2,1 km
Seyda Nihyn (village) : environ 100m ==> 3 km
Gnisis (ville moyenne) : environ 150m ==> 4,5 km
Balmora (grande ville) : environ 190 m ==> 5,7 km
Vivec (capitale) : environ 490m ==> 14,7 km
Tout droit vers le non-linéaire !
It's not the engine, it's the writing.
HERMA MORA ALTADOON AE
#20
elendell
Mécano Dell'Arte
Posté 23 novembre 2008 - 05:50
Hello !
Effectivement, sur 100 frames j'obtiens une fourchette beaucoup plus réduite. Suffisamment réduite pour qu'on puisse en retirer une vitesse moyenne ; ce qui n'était pas possible (chez moi) sur 10 frames. Ton hypothèse pour expliquer l'influence du fps est peut être juste. J'obtiens aussi des résultats stables en testant, non pas toutes les 100 frames mais toutes les 40 unités parcourues (bien que cela utilise plus de ressources, puisque que le script calcule à chaque frame la distance parcourue depuis le départ).
Au passage, j'ai remarqué de cette façon une alternance de 2 vitesses dans certains cas, avec la particularité que ce sont les mêmes résultats alternés qui reviennent (à vitesse constante). Mais je n'ai pas poussé plus loin pour en comprendre la raison.
Quoi qu'il en soit, s'il est nécessaire de faire une moyenne sur 100 frames pour obtenir une vitesse significative avec certains ordinateurs, je ne pourrai pas m'en servir dans mon script puisqu'il note distances et temps toutes les 2 frames. Je pourrai bien sûr rajouter des relevés toutes les 100 frames ou toutes les x unités parcourues mais donner la vitesse du PJ n'est pas l'objet de ce script. Ce n'était qu'un plus qui profitait de la présence de relevés.
Par contre, il m'importe de bien le comprendre pour d'autres scripts éventuels et pour savoir comment fonctionne le jeu.
Je ne vois pas pourquoi. Timescale définit le rapport entre le temps du jeu et notre temps mais pas le rapport des espaces.
Dans notre univers, le rapport espace/temps est, je crois, déterminé par la vitesse de la lumière dans le vide. Donc, selon cette constante universelle "c", si on réduit l'échelle de moitié, l'espace et le temps se réduisent en conséquence. Je crois donc comprendre ton raisonnement.
La mesure du temps "t" peut être transformée en mesure de distance "d" en multipliant "t" par la constante universelle "c". Donc, d = ct (avec t, le temps nécessaire à la lumière pour parcourir d.)
Mais, si Timescale définit effectivement le rapport entre "t" du jeu et "t" de notre univers, rien ne dit que la constante "c" soit la même dans les deux univers. Et dans le cas contraire, on ne sait pas non plus si "c" a été modifiée proportionnellement à Timescale. Il faudrait donc d'abord établir le rapport espace/temps de Vvardenfell en trouvant sa constante "c" pour pouvoir appliquer Timescale dans d = ct.
Il n'est pas impossible d'ailleurs que ce que je disais sur la perception dans un précédent message soit lié à cette différence éventuelle de constantes :
Ceci dit, ce sont des notions sur lesquelles je ne m'étais jamais penché et je n'ai qu'un lointain niveau de 5ème en maths (un peu plus depuis 1 mois que j'étudie différentes notions dans cette matière). Je peux donc me tromper totalement.
A propos d'une distortion éventuelle :
J'ai pris des mesures précises qui démontrent, si je les interprète bien, qu'il n'y a absolument aucune distortion d'espace et sans doute pas non plus du temps dans le jeu. Ce que j'ai fait :
Pour l'espace :
J'ai d'abord traversé l'ile du sud au nord en ligne droite, avec un script qui plaçait (avec placeatpc) un drapeau toutes les 100 unités. Puis j'ai comparé la distance obtenue par sqrt(x2-x1)²+(y2-y1)²+(z2-z1)² avec celle de (nbre de drapeaux*100). Le résultat était identique à une unité près. Puis, sans rentrer dans les détails, je me suis dit que cela n'impliquait pas obligatoirement l'absence de distortion.
J'ai donc placé dans le tescs des drapeaux sur 3 axes. Sur l'axe y, j'en ai placé 20 ; 1 toutes les 1000 unités exactement. Sur l'axe z, j'en ai placé 10 toutes les 1000 unités et sur l'axe x, j'en ai placé 10 toutes 100 unités.
Les drapeaux de l'axe "y" étaient répartis sur 4 cellules. Chaque drapeau avait un script qui notait ses coordonnées et qui faisait un GetDistance avec le drapeau précédent, ainsi qu'un autre avec le drapeau 0. De plus, ces GetDistance ne se faisaient que si le PJ était à proximité.
J'ai donc obtenu (dans le jeu) des distances par coordonnées cartésiennes (éloignées de 4 cellules pour les plus grandes) et d'autres par addition des distances de proximité. Dans tous les cas, les résultats sont rigoureusement identiques. S'il y avait distortion entre distances éloignées et distances à proximité du PJ, j'aurais dû obtenir des résultats différents.
Pour le temps :
J'ai "scripté" des objets pour qu'ils se déplacent le long de ces drapeaux, à une vitesse constante de 100 unités par seconde. Les scripts notaient les positions de départs et d'arrivées, le temps passé en secondes réelles, le nombre de frames écoulées ainsi que les GameHour de départ et d'arrivée.
Quelque soit l'axe et les distances (très courtes ou éloignées de 4 cellules), la vitesse résultante a toujours été exactement de 1,42m/s (en tenant compte des arrondis). Ce qui me fait penser que pour le temps non plus, il n'y a pas de distortion.
Je reste quand même prudent en ce qui concerne le temps pour deux raisons :
1) Il m'a semblé que si le PJ se déplaçait, le déplacement de l'objet s'arrêtait et ne reprenait que lorsque le PJ stoppait. Pour ces mesures, j'ai donc recommencé en laissant le PJ immobile ; à coté pour les distances courtes et dans la cellule du milieu pour les distances longues. Je dois vérifier cet arrêt éventuel du déplacement de l'objet pour voir si ça influe et en tirer des conclusions.
2) Je n'ai pas réussi à comprendre le rapport entre les résultats de (GameHourarrivée - GameHourdépart) et GetSecondsPassed. Ce manque de compréhension peut venir d'une éventuelle distortion mais j'en doute car je ne le comprends pas plus pour une distance courte à proximité du PJ. Cela peut venir aussi de la méconnaissance de l'équation à faire (la manière dont chaque élément se combine), de mon faible niveau en maths (J'ai du mal à traduire par exemple GetSecondsPassed en heures décimales.) ou encore de l'inconnue de "c" dont je parle plus haut.
Voici 3 relevés au cas où vous voudriez en tirer vos conclusions :
Note : F = frames écoulées, U = Unités de distances écoulées, GH = (GameHourarrivée - GameHourdépart), T = GetSecondsPassed.
Les relevés de temps n'ont que 4 décimales car je les ai notés en faisant "sv" à la console (qui ne donne que les 4 premières décimales).
Les déplacements se sont faits à 100 unités/seconde et TimeScale est à 30.
- F : 311 U : 1001,5989 GH : 0,0676 T : 10,0160
- F : 4052 U : 20001,1406 GH : 1,6632 T : 200,0136
- F : 1351 U : 10003,0586 GH : 0,7841 T : 100,0315
A propos des tailles entre les villes :
Je ne crois pas que tu puisses déterminer les différences de cette façon, Cogite. Pour comparer, il faudrait mesurer la surface du sol occupée par les habitations mais aussi qu'elles aient la même taille, le même espacement et le même pourcentage d'habitants au m².
Mais imaginons des lieux avec une seule rue et où l'on ne considèrera que la longueur. Si un lieu-dit a 2 maisons qui font chacune 100m de long, séparées par une distance de 500m ; tu relèveras 700m de l'entrée à la sortie du lieu-dit. Si par ailleurs, un village a 10 maisons contigües de 70m de long chacune, tu relèveras également 700m de l'entrée à la sortie du village. Pourtant, le premier n'aurait que 2 maisons et l'autre 10.
Si en plus, les 2 maisons du lieu-dit hébergent des célibataires et le village des couples, dont la moitié ont un enfant, tu auras 2 habitants pour le lieu-dit et 25 pour le village. On ne va pas pour autant dire qu'il y a distortion parce que les 2 font 700m de long. Et tu considèreras bien que le premier est le lieu-dit et l'autre le village. Sans parler bien sûr des services que l'on peut trouver dans chaque lieu.
J'ai copié les cabanes de Hla Oad et les ai collées à Gnisis et à Balmora. Leurs tailles et les distances qui les séparent restent identiques dans le jeu, quelque soit la cellule où elles se trouvent. Il n'y a donc pas distortion.
De plus, comment Bethesda pourrait-il prévoir ce que va faire un "modeur" dans une cellule pour déterminer un ratio différent ?
Le "modeur" peut très bien faire une très grande ville remplie de cabanes de Hla Oad et ils ne peuvent même pas se baser sur la taille des meshes puisque le "modeur" peut faire des meshes personnels pour ses maisons.
Note aussi le nombre de cellules extérieures utilisées dans les agglomérations de tes exemples : Hla Oad : 1, Seyda : 2, Gnisis : 3, Balmora : 4, Vivec : 15. Si l'on raisonne en terme de territoire communal (bien que tout le territoire ne soit pas recouvert de maisons) ; une cellule faisant 116,33m de côté, on obtient :
Hla Oad (petit village) : 13533 m²
Seyda Nihyn (village) : 27065 m²
Gnisis (ville moyenne) : 40598 m²
Balmora (grande ville) : 54131 m²
Vivec (capitale) : environ 202990 m²
Le rapport des proportions est beaucoup moins déséquilibré.
Cogite Stibon, le 21.11.2008 à 00:01, dit :
J'ai une hypothèse pour expliquer nos différence de résultats, si tu as un fps nettement plus bas. Ce serait que le fps influe, mais de façon plus subtile que ce que l'on imaginait au départ : Plus le FPS serait bas, plus le temps d'exécution des scripts et autre introduirait de l'imprécision dans le résultat du getsecondspassed. Essaye de faire une moyenne sur 100 frame pour voir si c'est plus stable.
Au passage, j'ai remarqué de cette façon une alternance de 2 vitesses dans certains cas, avec la particularité que ce sont les mêmes résultats alternés qui reviennent (à vitesse constante). Mais je n'ai pas poussé plus loin pour en comprendre la raison.
Quoi qu'il en soit, s'il est nécessaire de faire une moyenne sur 100 frames pour obtenir une vitesse significative avec certains ordinateurs, je ne pourrai pas m'en servir dans mon script puisqu'il note distances et temps toutes les 2 frames. Je pourrai bien sûr rajouter des relevés toutes les 100 frames ou toutes les x unités parcourues mais donner la vitesse du PJ n'est pas l'objet de ce script. Ce n'était qu'un plus qui profitait de la présence de relevés.
Par contre, il m'importe de bien le comprendre pour d'autres scripts éventuels et pour savoir comment fonctionne le jeu.
Cogite Stibon, le 21.11.2008 à 00:01, dit :
Pour mes distance, si le rapport d'échelle était cohérent avec le timescale, on devrait avoir, comme "vraie taille" pour chacune des villes la même taille multipliée par le timescale
Dans notre univers, le rapport espace/temps est, je crois, déterminé par la vitesse de la lumière dans le vide. Donc, selon cette constante universelle "c", si on réduit l'échelle de moitié, l'espace et le temps se réduisent en conséquence. Je crois donc comprendre ton raisonnement.
La mesure du temps "t" peut être transformée en mesure de distance "d" en multipliant "t" par la constante universelle "c". Donc, d = ct (avec t, le temps nécessaire à la lumière pour parcourir d.)
Mais, si Timescale définit effectivement le rapport entre "t" du jeu et "t" de notre univers, rien ne dit que la constante "c" soit la même dans les deux univers. Et dans le cas contraire, on ne sait pas non plus si "c" a été modifiée proportionnellement à Timescale. Il faudrait donc d'abord établir le rapport espace/temps de Vvardenfell en trouvant sa constante "c" pour pouvoir appliquer Timescale dans d = ct.
Il n'est pas impossible d'ailleurs que ce que je disais sur la perception dans un précédent message soit lié à cette différence éventuelle de constantes :
elendell dit :
Quand on joue, on appréhende l'espace à l'échelle sans difficulté tandis que pour le temps, on continue à le percevoir en temps réel... On perçoit l'espace proche du PJ à l'échelle du jeu mais avec une perception du temps qui elle, n'est pas à l'échelle.
A propos d'une distortion éventuelle :
J'ai pris des mesures précises qui démontrent, si je les interprète bien, qu'il n'y a absolument aucune distortion d'espace et sans doute pas non plus du temps dans le jeu. Ce que j'ai fait :
Pour l'espace :
J'ai d'abord traversé l'ile du sud au nord en ligne droite, avec un script qui plaçait (avec placeatpc) un drapeau toutes les 100 unités. Puis j'ai comparé la distance obtenue par sqrt(x2-x1)²+(y2-y1)²+(z2-z1)² avec celle de (nbre de drapeaux*100). Le résultat était identique à une unité près. Puis, sans rentrer dans les détails, je me suis dit que cela n'impliquait pas obligatoirement l'absence de distortion.
J'ai donc placé dans le tescs des drapeaux sur 3 axes. Sur l'axe y, j'en ai placé 20 ; 1 toutes les 1000 unités exactement. Sur l'axe z, j'en ai placé 10 toutes les 1000 unités et sur l'axe x, j'en ai placé 10 toutes 100 unités.
Les drapeaux de l'axe "y" étaient répartis sur 4 cellules. Chaque drapeau avait un script qui notait ses coordonnées et qui faisait un GetDistance avec le drapeau précédent, ainsi qu'un autre avec le drapeau 0. De plus, ces GetDistance ne se faisaient que si le PJ était à proximité.
J'ai donc obtenu (dans le jeu) des distances par coordonnées cartésiennes (éloignées de 4 cellules pour les plus grandes) et d'autres par addition des distances de proximité. Dans tous les cas, les résultats sont rigoureusement identiques. S'il y avait distortion entre distances éloignées et distances à proximité du PJ, j'aurais dû obtenir des résultats différents.
Pour le temps :
J'ai "scripté" des objets pour qu'ils se déplacent le long de ces drapeaux, à une vitesse constante de 100 unités par seconde. Les scripts notaient les positions de départs et d'arrivées, le temps passé en secondes réelles, le nombre de frames écoulées ainsi que les GameHour de départ et d'arrivée.
Quelque soit l'axe et les distances (très courtes ou éloignées de 4 cellules), la vitesse résultante a toujours été exactement de 1,42m/s (en tenant compte des arrondis). Ce qui me fait penser que pour le temps non plus, il n'y a pas de distortion.
Je reste quand même prudent en ce qui concerne le temps pour deux raisons :
1) Il m'a semblé que si le PJ se déplaçait, le déplacement de l'objet s'arrêtait et ne reprenait que lorsque le PJ stoppait. Pour ces mesures, j'ai donc recommencé en laissant le PJ immobile ; à coté pour les distances courtes et dans la cellule du milieu pour les distances longues. Je dois vérifier cet arrêt éventuel du déplacement de l'objet pour voir si ça influe et en tirer des conclusions.
2) Je n'ai pas réussi à comprendre le rapport entre les résultats de (GameHourarrivée - GameHourdépart) et GetSecondsPassed. Ce manque de compréhension peut venir d'une éventuelle distortion mais j'en doute car je ne le comprends pas plus pour une distance courte à proximité du PJ. Cela peut venir aussi de la méconnaissance de l'équation à faire (la manière dont chaque élément se combine), de mon faible niveau en maths (J'ai du mal à traduire par exemple GetSecondsPassed en heures décimales.) ou encore de l'inconnue de "c" dont je parle plus haut.
Voici 3 relevés au cas où vous voudriez en tirer vos conclusions :
Note : F = frames écoulées, U = Unités de distances écoulées, GH = (GameHourarrivée - GameHourdépart), T = GetSecondsPassed.
Les relevés de temps n'ont que 4 décimales car je les ai notés en faisant "sv" à la console (qui ne donne que les 4 premières décimales).
Les déplacements se sont faits à 100 unités/seconde et TimeScale est à 30.
- F : 311 U : 1001,5989 GH : 0,0676 T : 10,0160
- F : 4052 U : 20001,1406 GH : 1,6632 T : 200,0136
- F : 1351 U : 10003,0586 GH : 0,7841 T : 100,0315
A propos des tailles entre les villes :
Je ne crois pas que tu puisses déterminer les différences de cette façon, Cogite. Pour comparer, il faudrait mesurer la surface du sol occupée par les habitations mais aussi qu'elles aient la même taille, le même espacement et le même pourcentage d'habitants au m².
Mais imaginons des lieux avec une seule rue et où l'on ne considèrera que la longueur. Si un lieu-dit a 2 maisons qui font chacune 100m de long, séparées par une distance de 500m ; tu relèveras 700m de l'entrée à la sortie du lieu-dit. Si par ailleurs, un village a 10 maisons contigües de 70m de long chacune, tu relèveras également 700m de l'entrée à la sortie du village. Pourtant, le premier n'aurait que 2 maisons et l'autre 10.
Si en plus, les 2 maisons du lieu-dit hébergent des célibataires et le village des couples, dont la moitié ont un enfant, tu auras 2 habitants pour le lieu-dit et 25 pour le village. On ne va pas pour autant dire qu'il y a distortion parce que les 2 font 700m de long. Et tu considèreras bien que le premier est le lieu-dit et l'autre le village. Sans parler bien sûr des services que l'on peut trouver dans chaque lieu.
J'ai copié les cabanes de Hla Oad et les ai collées à Gnisis et à Balmora. Leurs tailles et les distances qui les séparent restent identiques dans le jeu, quelque soit la cellule où elles se trouvent. Il n'y a donc pas distortion.
De plus, comment Bethesda pourrait-il prévoir ce que va faire un "modeur" dans une cellule pour déterminer un ratio différent ?
Le "modeur" peut très bien faire une très grande ville remplie de cabanes de Hla Oad et ils ne peuvent même pas se baser sur la taille des meshes puisque le "modeur" peut faire des meshes personnels pour ses maisons.
Note aussi le nombre de cellules extérieures utilisées dans les agglomérations de tes exemples : Hla Oad : 1, Seyda : 2, Gnisis : 3, Balmora : 4, Vivec : 15. Si l'on raisonne en terme de territoire communal (bien que tout le territoire ne soit pas recouvert de maisons) ; une cellule faisant 116,33m de côté, on obtient :
Hla Oad (petit village) : 13533 m²
Seyda Nihyn (village) : 27065 m²
Gnisis (ville moyenne) : 40598 m²
Balmora (grande ville) : 54131 m²
Vivec (capitale) : environ 202990 m²
Le rapport des proportions est beaucoup moins déséquilibré.
#21
Noctis Lux
Posté 23 novembre 2008 - 10:49
Je ne sais pas si ça a un quelconque intérêt pour la précision des calculs, mais on ne sait jamais...
Dans la description des sorts d'invocation de créature (dans Créer un Sort, par exemple), il est indiqué que la créature apparait deux mètres devant le lanceur. Si on considère la distance en unités on peut avoir une base de conversion plus précise, non?
Voilà, c'était juste au cas où...
Dans la description des sorts d'invocation de créature (dans Créer un Sort, par exemple), il est indiqué que la créature apparait deux mètres devant le lanceur. Si on considère la distance en unités on peut avoir une base de conversion plus précise, non?
Voilà, c'était juste au cas où...
Langue de dragon : expression nordique désignant une personne qui n'ouvre sa gueule que pour hurler sur ceux qui la contrarient.
#22
Von Zeeple
Grille pain Dwemer
Posté 23 novembre 2008 - 11:52
Pour répondre au sujet de la vitesse de la lumière dans morrow:
En fait le temps dans notre univers est le même que dans celui des TES, sauf que, pour des raisons pratiques, une journée ne dure que 30min environ. En fait c'est plutôt la vitesse de rotation de Nirn et le rythme de vie des habitants qui est accéléré. La définition de l'heure n'est donc pas la même que chez nous puisque par définition c'est 1/24 de journée.
Ce qui explique le résultat de gamehour.
La distorsion temporelle évoquée par cogite est en fait une illusion.
Car getsecondspassed renvoi bien le temps réel.
Dans cette logique, une horloge atomique (dwemer?), renverrait le même battement que chez nous. Et la vitesse de la lumière serait la même.
En fait, tout dépend de l'unité que l'on veux obtenir, si on la veux en heure Nirnienne (gamehour) ou en heure terrestre (getsecondspassed).
En fait le temps dans notre univers est le même que dans celui des TES, sauf que, pour des raisons pratiques, une journée ne dure que 30min environ. En fait c'est plutôt la vitesse de rotation de Nirn et le rythme de vie des habitants qui est accéléré. La définition de l'heure n'est donc pas la même que chez nous puisque par définition c'est 1/24 de journée.
Ce qui explique le résultat de gamehour.
La distorsion temporelle évoquée par cogite est en fait une illusion.
Car getsecondspassed renvoi bien le temps réel.
Dans cette logique, une horloge atomique (dwemer?), renverrait le même battement que chez nous. Et la vitesse de la lumière serait la même.
En fait, tout dépend de l'unité que l'on veux obtenir, si on la veux en heure Nirnienne (gamehour) ou en heure terrestre (getsecondspassed).
Le Steampunk, c'est bon, mangez en !
#23
Kafou
Le canari a bouffé le rominet !
Posté 23 novembre 2008 - 12:36
Citation
J'ai donc obtenu (dans le jeu) des distances par coordonnées cartésiennes (éloignées de 4 cellules pour les plus grandes) et d'autres par addition des distances de proximité. Dans tous les cas, les résultats sont rigoureusement identiques. S'il y avait distortion entre distances éloignées et distances à proximité du PJ, j'aurais dû obtenir des résultats différents.
Von Zeeple, le 23.11.2008 à 11:51, dit :
La distorsion temporelle évoquée par cogite est en fait une illusion.
Car getsecondspassed renvoi bien le temps réel.
Car getsecondspassed renvoi bien le temps réel.
Cette distorsion est tout à fait subjective et ne concerne que le rapport entre :
- comment est le monde en théorie, la façon dont le perçoit le joueur (s'il se prend au jeu)
- comment il est représenté en pratique, la façon informatique dont le monde fonctionne et est rendu ingame
You look like you need a monkey!
Attention : perfectionniste paresseux.
Attention : perfectionniste paresseux.
#24
elendell
Mécano Dell'Arte
Posté 23 novembre 2008 - 19:26
Noctis Lux, le 23.11.2008 à 10:48, dit :
Je ne sais pas si ça a un quelconque intérêt pour la précision des calculs, mais on ne sait jamais...
Von Zeeple, le 23.11.2008 à 11:51, dit :
En fait le temps dans notre univers est le même que dans celui des TES, sauf que, pour des raisons pratiques, une journée ne dure que 30min environ.
).Von Zeeple, le 23.11.2008 à 11:51, dit :
La définition de l'heure n'est donc pas la même que chez nous puisque par définition c'est 1/24 de journée.
Ce qui explique le résultat de gamehour.
Ce qui explique le résultat de gamehour.
Kafou, le 23.11.2008 à 12:35, dit :
Elendell désolé mais tu te prends la tête pour rien
Pour les distortions éventuelles, je pensais que Cogite se trompait. Mais ayant constaté bien des fois à quel point je pouvais me tromper en étant persuadé du contraire, je me fais un devoir de vérifier mes suppositions. Surtout quand elles ne collent pas avec ce que dit une personne intelligente et qui ne parle pas pour ne rien dire (comme c'est le cas de Cogite
).Quoi qu'il en soit, merci à tous d'avoir pris le temps de réfléchir avec moi sur ce sujet !
#25
Cogite Stibon
Théoriquement moddeur
Posté 24 novembre 2008 - 12:17
Bonjour,
Le rapport entre GameHour et Getsecondspassed est assez simple :
Getsecondspassed indique le nombre de secondes écoulée en temps "réel"
GameHour indique le nombre d'heures en temps "du jeu", qui s'écoule 30 fois plus vite (entre deux "levers de soleil" dans le temps du jeu, il se passe 48 minutes en temps réel, soit un trentième de 24 heures).
Pour ramener GameHour en secondes, il faut le multiplier par 3600 (1 heure fait 60 minutes qui font 60 secondes).
Pour ramener GetsecondsPassed en "temps du jeu", il faut le multiplier par 30 (car 1 seconde de temps réel correspond à 30s de temps du jeu)
On a donc théoriquement :
GameHour * 3600 = GetsecondsPassed * 30
Soit
GetSecondsPassed = GameHour * 120
Ou encore :
GameHour = Getseconds Passed / 120
Dans la pratique, sur en appliquant ces formules à tes relevés, on a :
Les écarts importants s'expliquent par les imprécisions et les arrondis du moteur de jeu. On voit quand même que plus on fait une moyenne sur un grand nombre de frame, plus l'écart diminue.
Concernant les distorsions, je me suis mal fait comprendre. Je parle de distorsions entre la "réalité" de l'univers des Elders Scrolls et la représentation qui en est faite dans le jeu, pas de distorsions au sein même de cette représentation. Dans la "réalité" de Nirn, Vvardenfell fait plusieurs centaines de kilomètres de large, Gnisis occupe une surface bien supérieure à celle de 4 terrains de foot, et les journées durent 24 heures, pas 48 minutes. Mais on ne peux pas calculer un simple ratio permettant de dire : pour passer de la taille "dans le jeu" à la taille "réelle de Nirn", il suffit de multiplier par x.
Une question qui me tracasse : à quel usage destines-tu cette vitesse ?
Cogite
Le rapport entre GameHour et Getsecondspassed est assez simple :
Getsecondspassed indique le nombre de secondes écoulée en temps "réel"
GameHour indique le nombre d'heures en temps "du jeu", qui s'écoule 30 fois plus vite (entre deux "levers de soleil" dans le temps du jeu, il se passe 48 minutes en temps réel, soit un trentième de 24 heures).
Pour ramener GameHour en secondes, il faut le multiplier par 3600 (1 heure fait 60 minutes qui font 60 secondes).
Pour ramener GetsecondsPassed en "temps du jeu", il faut le multiplier par 30 (car 1 seconde de temps réel correspond à 30s de temps du jeu)
On a donc théoriquement :
GameHour * 3600 = GetsecondsPassed * 30
Soit
GetSecondsPassed = GameHour * 120
Ou encore :
GameHour = Getseconds Passed / 120
Dans la pratique, sur en appliquant ces formules à tes relevés, on a :
F U GH T GH * 3600 T *30 Ecart 311 1001,5989 0,0676 10,016 300,48 243,36 19% 4052 20001,1406 1,6632 200,0136 6000,408 5987,52 0% 1351 10003,0586 0,7841 100,0315 3000,945 2822,76 6%
Les écarts importants s'expliquent par les imprécisions et les arrondis du moteur de jeu. On voit quand même que plus on fait une moyenne sur un grand nombre de frame, plus l'écart diminue.
Concernant les distorsions, je me suis mal fait comprendre. Je parle de distorsions entre la "réalité" de l'univers des Elders Scrolls et la représentation qui en est faite dans le jeu, pas de distorsions au sein même de cette représentation. Dans la "réalité" de Nirn, Vvardenfell fait plusieurs centaines de kilomètres de large, Gnisis occupe une surface bien supérieure à celle de 4 terrains de foot, et les journées durent 24 heures, pas 48 minutes. Mais on ne peux pas calculer un simple ratio permettant de dire : pour passer de la taille "dans le jeu" à la taille "réelle de Nirn", il suffit de multiplier par x.
Une question qui me tracasse : à quel usage destines-tu cette vitesse ?
Cogite
Tout droit vers le non-linéaire !
It's not the engine, it's the writing.
HERMA MORA ALTADOON AE
0 utilisateur(s) li(sen)t ce sujet
0 membre(s), 0 invité(s), 0 utilisateur(s) anonyme(s)
