[3D] Delta Time encore une fois

[SPH]

Je n'ai pas modifié le premier code figurant au premier message afin de préserver le cheminement de ce post.

Je souhaiterais que quelques utilisateurs testent ce nouveau code en me signalant si la vitesse de rotation est conforme au gif ci-dessous.

Même vitesse que ton gif chez moi.

[G-Rom]

Falsam , je t'ai fait un code EXTRA minimaliste :

Code : Tout sélectionner

Define.f Temps_reel   = 0
Define delta_clock.i  = 0
Define delta_time.d   = 0.0


Define Mouvement.f = 0

Repeat
  Temps_reel  = ElapsedMilliseconds() ; ne sert que pour sortir de la boucle
  delta_clock = ElapsedMilliseconds()
  
   
  Mouvement + 100 * delta_time
  
  Delay( 15 + Random(15) ) ; simule une charge sur le PC ou un processeur différent
  
  delta_time = (ElapsedMilliseconds() - delta_clock) / 1000
Until Temps_reel > 1000


; Produit en croix 
MessageRequester("" , Str((1000 * Mouvement) / Temps_reel)  )
; doit affiché 100
; le produit en croix est nécessaire ici uniquement 
; car Temps_reel est plus grand que 1000

Le but de ce code, "simulé" un mouvement de 100 unités par secondes
on simule dans le code la charge CPU ou la génération de CPU par un simpe delay randomizé, même si tu change la valeur du delay par un nombre beaucoup plus grand , le resultat sera 100
qui correspond à une vitesse de 100 par secondes.
le produit en croix a la fin est juste là pour prendre en compte la possibilité que la boucle dure plus que une seconde, il ne sert uniquement pour démontré que le résultat sera toujours égal a 100.

[Ollivier]

C'est presque ca
ton calcul est bon.
mais tu peu faire plus simple, ogre te donne déjà le delta time, pas besoin de le calculé :

Code : Tout sélectionner

dt = RenderWorld() / 1000

et cela :

Code : Tout sélectionner

 RotateEntity(0, 0, 360 * dt, 0, #PB_Relative) 

l'entité fera une rotation de 360° par secondes, quelque soit la config

Très bon cette astuce de synchro retourné par RenderWorld().

La seule difficulté c'est qu'on a une frame de retard. Et parce que l'attente est intégrée dans FlipBuffers(), et que ce FlipBuffers() s'exécute après RenderWorld(), théoriquement le retard d'une frame reste.

Après, ce n'est pas très grave : les dT sont sensés être plutôt stables donc si on calcule la moyenne des dT retournés, et qu'on ajoute cette moyenne, on "avance" les calculs d'une image (ou frame).

[G-Rom]

On perd effectivement la première frame, mais quelque part c'est logique, tant que l'on ne sait pas combien prend une frame à être exécutée.
a 60fps, la première frame est imperceptible

[Ollivier]

a 60fps, la première frame est imperceptible

Je pense qu'on perçoit, mais c'est juste un retard constant et minime entre la main et l'oeil donc, il ne faut pas 10 secondes pour s'habituer.

Pire, sous Windows, si on calcule la moyenne des dT pour la rajouter et anticiper le retard, autant rajouter le message d'alerte << Ne convient pas aux épileptiques >>.

[G-Rom]

a 60fps, la première frame est imperceptible

Je pense qu'on perçoit, mais c'est juste un retard constant et minime entre la main et l'oeil donc, il ne faut pas 10 secondes pour s'habituer.

Pire, sous Windows, si on calcule la moyenne des dT pour la rajouter et anticiper le retard, autant rajouter le message d'alerte << Ne convient pas aux épileptiques >>.

Si t'est sous acide, peut être , je demanderais à Palmade quand je le verrais
sans rire, une frame peut prendre sur une belle config 0.1 ms et 15/20ms sur une vieille config , je ne pense pas que le temps de réaction humaine puisse le percevoir.

[Ollivier]

Si t'est sous acide, peut être , je demanderais à Palmade quand je le verrais

T'as toujours été attiré par les "révolutionnaires" de l'IVG. Ça, c'est pour camoufler ta propre addiction à l'acide (ascorbique).

sans rire, une frame peut prendre sur une belle config 0.1 ms et 15/20ms sur une vieille config , je ne pense pas que le temps de réaction humaine puisse le percevoir.

En temps normal, non. Et consciemment, non plus, effectivement. C'est la persistance rétinienne qui va dans de telle furtivités (0.1 ms ou plus bref : les cellules de la rétine sont nombreuses et asynchrones donc elles détectent, même si tu vas t'imaginer les cheveux de la voisine à la place d'un carré blanc affiché furtivement. La preuve serait un jeu risqué où tu chronomètres le temps de réponse d'un utilisateur après un affichage furtif. Tu commences par 100 millisecondes d'affichage furtif. Si l'utilisateur met moins d'une seconde pour réagir, tu descends à 99 millisecondes et ainsi de suite).

Edit : j'ai testé un petit code qui décide d'attendre entre une et dix secondes (1000 + Random(9000) ) pour flasher pendant 10 ms (équivalent 100 Hertz).

Au bout d'une seconde après le flash :
- soit l'utilisation a appuyé sur [Entrée], dans ce cas on baisse de 1 ms le prochain flash
- soit l'utilisateur n'a rien capté, dans ce cas, on augmente de 3 ms le prochain flash

Et on augmente de 3 ms le flash si l'utilisateur a appuyé sur [Entrée] avant le flash.

On va aisément de 10 millisecondes à 1 millisecondes.

Maintenant, est-ce que mon ordi est à 100 fps quand il n'a quasiment rien à afficher excepté le ClearScreen() ?

Dans le bénéfice du doute, je te dirai que non et qu'il stationne à 15/16 millisecondes par frame. Je n'ai pas vérifié si pureBasic peut descendre en dessous (option dans OpenScreen() ), si Windows (10) peut aller plus vite que 60 hertz et si le matériel vidéo (de 2019) peut aller plus vite aussi.

Si ta "vieille daube de la comptabilité" dépasse tout ça, je pense que tu percevras un flash en dessous de 0.1 millisecondes.

Je te dis ça parce que j'ai perçu des flash LED d'une durée égale à une période de fréquence de 78 KHz.

Par contre, à une telle fréquence, est-ce qu'on peut différencier un double-flash d'une durée simple d'une durée double ?

comparer ça :
[flash 0.1ms][néant de 1 ms][flash 0.1ms]
et
[flash 0.1ms][néant de 2 ms][flash 0.1ms]

Dans ce cas, à mon avis, là on ne dicerne plus rien. Je pense même qu'un double flash de 0.1 ms séparés par un néant de 1 ms n'est pas dicernable par l'oeil humain d'un simple flash.

Tu remarqueras aussi que la périphérie de la vue est très sensible aux variations (c'est pour ça que pour arrêter l'effet de vertige, il faut regarder le vide, ne pas le fuir des yeux dont la périphérie des rétines envoient direct à l'oreille interne. Des gros seins en pleine face, ça circule beaucoup plus lentement dans les nerfs optiques que la perception du vide)

[Ollivier]

Je confirme : après vérif pratique, j'ai 15ms autour du FlipBuffers() en mode OpenScreen() par défaut (W10).

Pour descendre en dessous de 15ms, je mets l'option #PB_Screen_NoSynchronization

Dans ce cas, avec un simple ClearScreen() à afficher, ça descend jusqu'à 0 millisecondes. Donc possiblement, théoriquement, hypothétiquement, etc... supérieur à 1000 Hertz.

Comme la vidéo est à 60 Hertz, les flashs sont des bandes horizontales blanches à l'écran. Il y en a parfois même deux simultanément (et mystérieusement).

Conclusion : la carte vidéo ne me permet pas de vérifier mes capacités visuelles, car les bandes blanches, en 60 fps, s'affichent durant 15 ms.

Une autre technique consiste à user de l'électronique, et mettre en cascade trois composants NAND (TTL pour éviter d'avoir à adapter la LED et l'alimentation puisqu'une batterie USB est suffisante). C'est avec ce procédé qu'on se rend compte qu'on perçoit des fréquences plus élevées de flash. Et que la persistance rétinienne est supérieure autour de la fovéa.

[Ollivier]

Test "entre l'oeil et la main" : jusqu'à 15 ms de retard, on voit rien.

À part une fois toutes les deux heures, quand une phrase typique de type << Ah mais p...utain de système ! Je l'ai vu : l'ordinateur a triché. Il m'a n...iqué ! Je le touchais pas le machin, j'en suis certain ! >> peut retentir, une période de 15 ms par image (et donc entre un clic et une réaction), ça ne fait pas mal au yeux du tout.

Il y a quelque fois quand la vitesse affichée, d'un objet graphique, est grande, on entrevoit les "pas" de l'animation :
alors je sais qu'en 2D, ça se résoud assez facilement.

Mais en 3D, je n'ai aucune idée de la technique sous Ogre. Je sais dessiner un polygone en 3D perspective avec des sprites, et faire un semblant de flou de mouvement.

Mais avec Ogre, je ne vois pas trop de technique rapide...