Discussion :

[oxyde356]

Bonjour tout le monde,
J'ai fais un petit bout de moteur physique ou une balle rebondi sans vitesse initial mais a une certaine hauteur tombe sous l'effet de la gravité sur un plan horizontale et rebondi selon son coefficient de rebond (coeff de restitution) variant de 0 à 1 (si 1 alors l'energie est entierement conservé). Et donc j'aimerai que quand ce coeff est à 1 la balle apres un rebond remonte à la meme hauteur qu'elle est tombé (étant donné que aucune énergie n'a été perdu) malheuresement avec le système de frame c'est très dur à faire pour une raison simple. La balle ne touche pas le plan en un seul point pile sur une frame donné en général la balle va traverser le plan et il fodra la replacé ce que je fais, je me sers de la norme de son vecteur vitesse pour la faire descendre sur le plan puis remonté pour simuler le rebond selon la longueur de son vecteur vitesse. Donc après le rebond je me retrouve dans la plus part des cas avec une balle plus haute ou plus basse qu'elle ne l'était avant et je ne peux pas utiliser V1=-V0 qui inverserait la vitesse de la balle pour simuler le rebond car la balle étant un peu plus haute ou plus basses je si j'utilise la même vélocité la balle montera plus bas ou plus haut que comme elle l'était quand on l'a laché ! Donc je dois trouvé une équation de sa vitesse après rebond ! Si qu'elqu'un pouvait m'aider sa serait super simpa parcque la je bloque énormement. Merci d'avance.

[plegat]

Rooooh...

Salut,

Il serait judicieux que tu apprennes à appuyer sur la grosse touche avec marqué "Entrée" sur ton clavier... il a fallu que je relise ton post quatre fois avant de comprendre un tant soit peu...

Je ne sais pas ce qu'est ton système de "frame", mais je te donne une piste.

Sachant qu'à l'instant t1, la balle n'a pas encore touché le plan, et qu'à l'instant t2, elle a rebondi, tu devrais pouvoir trouver l'instant t3, compris entre t1 et t2, auquel la balle touche le plan.
Connaissant cet instant t3, tu peux en déduire la vitesse de la balle, et donc l'inverser.
Tu recalcules ensuite sa position et vitesse à l'instant t2, et tu continues.

[Rafy]

Pour un rebond comme celui la il te faut opposer la composante de la vitesse qui normale au plan de la collision.
Donc si ton plan à une normale n, ta vitesse s'exprime ainsi :
V -= 2*(V*n)*n
Avec n qui pointe vers ta boule.

[TicTacToe]

Je comprends ton soucis.

Mais la méthode de 'remettre' la balle sur sa base n'est pas la bonne solution si tu ne fais que ce traitement.

Les colisions se passent en 2 étapes.

1. Repérer le point de colision, ce que tu as fait.
Ta balle se déplacant du point A au point B, le point de colision se passe entre les 2 au point I. il faut repositionner ta balle au point I.

2. le problème, c'est que la vitesse que tu redonnes, est la vitesse au point B, et non au point I -> décalage. Donc, pour les colisions, il ne faut pas que tu reprenne ta derniere vitesse inversée, mais que tu la recalcules sur ta distance AI (et non AB), et ensuite tu inverses.

conclusion, au point I, la vitesse est inversée et correspondant vraiment à la vitesse au moment de l'impact.

D'une manière générale, c'est de toute facon mieux de recalculer la derniere vitesse en prenant la dernière distance réelle / temps (et non la dernière distance théorique).


donne aussi un coefficient de frottement à tes surfaces pour un rendu plus réaliste. (le coef de balle x coeff de rebond de la surface pour la composante dir. de balle, coef de frottement de balle x coef de frottement de la surface sur la normale à la dir. de la balle).

Bon code !

[Rafy]

Si on veut être purriste : Si notre balle est avant la collision en A, en B elle est en collision.... Le repositionnement de la balle n'est pas sur le segment [AB]. Certe la balle à rebondie sur le plan qui coupe le segment [AB], mais elle a rebondie.
Si on apelle I le point de concours du segment et du plan de collision, alors la balle se positionne non pas en I mais en I + le symétrique de IA par rapport au plan...
(souligné = vecteur)
Pour comprendre il faut faire un petit dessin, et on peut même se rendre compte que ce que je viens de dire n'est encore qu'une modélisation (qui s'approche quand même pluis de la réalité que le simple repositionnement sur le plan de collision). Je m'explique :
Durant son trajet sur IA, la balle était soumise à des efforts (gravité par exemple) ces efforts accéléraient la balle (la vitesse instantanée augmentait), mais du fait de sa collision elle doit rebondire, et pendant le temps (infiniment petit) qui sépare le moment de la collision et le moment de la frame suivante, la ou elle doit se retrouver, la balle a changée de direction, à cause de son rebond, les efforts qui s'applique sur elle ne vont plus l'accélérer (pas au sens de la mechanique, mais au sens augmenter sa vitesse). Ce que je veux dire c'est que la balle ne va pas parcourir la même distance en remontant qu'en descendant... Donc elle devra être repositionnée encore ailleurs, un peu plus bas que prévu...
Et la il faut encore compter pour calculer cette nouvelle position.

[Rafy]

J'ai codé un moteur physique, ce moteur prends biensur en compte les collisions.
Je repositionne les objets sur le plan de collision, comme décrit au dessus.
Ce que j'essaye de vous dire c'est que ce n'est pas nécessaire de faire un repositionnement rigoureux (je veux dire très rigoureux), car la différece de position est si infime qu'il est impossible de faire la différence entre les deux... Donc le repositionnement c'est important mais il faut faire ça simplement...
Par contre il faut se concentrer d'avantage sur l'impulsion créée par la collision (symétrisation de la vitesse)...

[TicTacToe]

Tu as parfaitement raison Rafy.

En gros, la boule à un instant T peut être n'importe ou, pourquoi forcément sur le plan de colision ?

Il n'y a pas de Point I ou il faut repositionner la boule, mais en B', symétrie / au plan (mais en tenant compte au passage, des coef de dureté et de frottement).

C'est vrai qu'il est plus simple dans un 1er temps de repositionner sur le plan, plus le refresh de la boule est rapide, plus on s'approche de la vérité...

[Rafy]

Par contre il faut faire attention aux objets relativement petit et/ou fin :
Il est possible qu'il y ai collision sans qu'elle soit détectée.
Je m'explique : on veut modéliser la chute d'une feuille de papier sur une table.
Le plan décrit par la feuille de papier étant parallèle au plan de la table.
Frame n : la feuille est au dessus de la table, n'est pas en collision avec la table.
Frame n+1 : la feuille est sous de la table, n'est pas en collision avec la table.
=> pas de détection de collision (et ouais la feuille n'est pas en contact avec la table pendant une frame, maise entre 2 frame).... Donc pas de traitement de collision, et donc ça traverse.
Ce n'est pas rare....

[TicTacToe]

C'est ce que j'appelais 'l'effet papillon' dans quelques flippers d'il y a qq année,s ou la balle traverse les bumps...
Et l'autre problème c'est vrai, c'est l'epaisseur de l'objet
- soit on le considère comme un point (ex. centre de la boule)
- soit il faut calculer le point le plus proche appartenant à l'objet avec le plan de colision (typiquement, l'intersection entre la droite [centre de gravité de l'objet, normale au plan de colision) et travailler avec ce point.

Mais tout dépend de la méthode de détection de la colision
personellement, entre 2 positions Pt1 et Pt2, je faisais une simple intersection de droites entre (Pt1,Pt2) et la droite du plan de colision.
Cela marchait donc, même si le refresh était très lent et que l'objet ne soit pas "dans" le plan de colision.

[Rafy]

Moi j'utilise des sphere tree pour la détection des collisions.
Chaque objet est modélisé par un arbre de sphere.
Pour détecter des collisions je regarde si les arbre se touchent....
Ce procèdé est utilisé dans GTA.