SIMULATION D'UN BILLARD
cs_Urgo
Messages postés
780
Date d'inscription
lundi 16 décembre 2002
Statut
Membre
Dernière intervention
16 avril 2009
-
30 août 2005 à 23:00
cs_JCDjcd Messages postés 1138 Date d'inscription mardi 10 juin 2003 Statut Membre Dernière intervention 25 janvier 2009 - 4 sept. 2005 à 13:13
cs_JCDjcd Messages postés 1138 Date d'inscription mardi 10 juin 2003 Statut Membre Dernière intervention 25 janvier 2009 - 4 sept. 2005 à 13:13
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/33545-simulation-d-un-billard
https://codes-sources.commentcamarche.net/source/33545-simulation-d-un-billard
4 sept. 2005 à 13:13
4 sept. 2005 à 12:59
4 sept. 2005 à 12:01
prgm.ex => prgm.exe
4 sept. 2005 à 11:28
3 sept. 2005 à 14:57
3 sept. 2005 à 14:45
Donc pour le moment je calculs les eventuelles collisions avec TOUTES les autres boules, mais en revanche j'utilise des arbres pour rechecher le minimum.
Donc c'est un logique telle que :
recalculer : O(n)
memoire : O(n²)
minimum : O(log(n))
tout cela dans le pire des cas
3 sept. 2005 à 14:16
Donc, si je comprends bien, ta méthode n'est pas une simulation "libre" où tu regardes pas à pas ce qui se passe, tu prévois les rebonds et tu les exécutes à la suite? C'est assez original comme procédé. Juste une chose: tu testes toutes les billes contre toutes les autres billes, où tu divise le plan en sous parties pour réduire le nombre de tests? (les quadtrees sont généralement utilisés pour ce genre de choses: ça permet de ne tester les collisions qu'entre billes relativement proches, ça va plus vite que de calculer la distance entre chaque couple)
3 sept. 2005 à 13:54
Mais la difficulte provient du test des collisions : la definition d'une collision est lorsque la distance entre deux boules vaut la somme des deux rayons et que la collision se produise a t>=0, car la resolution de l'equation en t peut avoir comme solution des temps negatifs, donc je ne prends que les cas t>=0, de plus il y a un autre probleme : c'est le cas t=0, car prenons le cas ou deux boules sont initialement collees sans vitesse initiale, alors la resolution donne t=0 car a t=0 la distance vaut bien la somme des deux rayons ! Mais pourtant physiquement il n'y a pas de collision. Il faut etre plus rigoureux sur la definition d'un chocs, il y a chocs que si la distance vaut la somme des deux rayons et que cela se produise a t>=0 ET que la distance diminue, i.e. sa derivee strictement negative. Donc le point crucial est ici. Il faut que ces DEUX conditions soient verifiees pour qu'il est chocs, le cas echeant la collision est enregistree dans l'arbre.
Un cas pathologique est par exemple : plusieurs boules collees et alignees sans vitesse initiale, et on envoie une boule dans l'alignement (comme le celebre jeu des 5 boules dont on lache que celle de l'extremite et seule la boule a l'autre extremite bouge). Alors la on est en plein dans le cas du dessus, et la distinction entre "se rapprochent" et "s'eloigne" est importante.
le fonction pour resoudre une collision est :
//----------------------------------------------------------
// calcul l'eventuelle collision entre deux boules
static BOOL foreseeBetweenTypeCrash(double *pTime,P_BALL B1,P_BALL B2)
{
// somme des deux rayons
double R;
// difference des deux vitesse
VECT2D dv;
// difference des deux position
VECT2D dp0;
// pour la resolution de l'equation
double a, // coefficient
b, // coefficient
c; // coefficient
AssertPointer(pTime);
AssertPointer(B1);
AssertPointer(B2);
// on calcule l'equation
SubVect2D(&dp0,&B2->p0,&B1->p0);
SubVect2D(&dv,&B2->v,&B1->v);
R = B1->r + B2->r;
a = Norm2Vect2D(&dv);
b = 2.*DotProductVect2D(&dp0,&dv);
c = Norm2Vect2D(&dp0) - R*R;
c = max(0.,c); // pour les erreurs de calculs
// on resout l'equation
// * ceci distingue le contact entre deux boules, et le rebond
// car il peut y avoir contact sans rebond, il n'y a rebond
// que si les deux boules se rapproche, i.e. la distance diminue
// i.e. sa derivee est strictement negatif, a le signe
// de cette derivee
if(b >= 0.)
return FALSE;
else
// * il y a rebond (pas forcement dans le futur)
{
double T1,T2;
if(resolve(&T1,&T2,a,b,c))
{
// si les deux racines sont negatives
if((T1 < 0.) && (T2 < 0.))
return FALSE;
// si les deux racines sont positives
else if((T1 >= 0.) && (T2 >= 0.))
return (*pTime = min(T1,T2),TRUE);
// si les deux racines sont de signes opposes
else
return (*pTime = max(T1,T2),TRUE);
}
else
return FALSE;
}
} // foreseeBetweenTypeCrash()
3 sept. 2005 à 13:29
3 sept. 2005 à 13:21
Les erreurs de la resolution interviennent evidemment.
Mais cela n'est pas suffisant, comme tu le faisais remarquer Kirua, il est aussi preferable de calculer le signe du produit scalaire entre les vitesses et les positions (qui est en fait le coefficient lineaire de l'equation) pour voir si les boules se rapprochent ou s'eloignent. Le probleme est que si la solution est dans le passe, il n'y a pas de collision, par contre dans le futur aucun probleme, mais si elle est exactement au present (i.e. t(chocs) = t(courant) alors il y a un chocs que si les deux boules se rapprochent, i.e. si la derivee est negative, i.e. voir le signe de la quantite du dessus.
Donc la resolution des collisions est en soi pas complique, mais il faut bien faire les calculs sur papier, et surtout prendre en compte le cas t(chocs) = t(courant) car sinon l'algo. se plante, les cas pathologiques sont faciles a trouves.
3 sept. 2005 à 12:39
Pour les collisions donc, à mon avis pas besoin de runge-kutta, mais si tu veux un exemple, il y en a plusieurs sur cppfrance et des dizaines sur internet. C'est un peu mathématique mais si tu as eu un cours d'analyse de niveau bac ça devrait passer.
3 sept. 2005 à 09:55
3 sept. 2005 à 09:33
3 sept. 2005 à 01:32
F = ma
A = F/m
v dt = F/m dt
et donc on a qq ch dans le goût de:
nouvelle vitesse = ancienne vitesse + (F/m) * delta temps
avec un delta temps équivalent à l'écart entre deux frames. c'est easy à coder, suffisament précis quand il s'agit de faire du "eye candy" (des jolis effets), mais pour faire une simulation physique, c'est complètement nul :/ tu fais une erreur de l'ordre de delta temps élevé au carré. pour réduire drastiquement l'erreur (due à la discrétisation du temps), tu peux utiliser l'interpolateur de runge-kutta, qui réduit l'erreur à l'ordre de delta temps exposant 5, ce qui est sérieusement plus petit!
Sinon, c'est cool pour la simu de collisions. Perso quand j'ai codé la mienne (ça fait un moment, mais je m'en souviens encore très bien, c'était génial ^^), je n'ai utilisé que des opérations vectorielles, complètement empiriques ("observé" sur des schémas de ma conception), et ça s'est révélé correct (juste pour mentionner le fait que c'est possible, et qu'il ne fait pas forcément faire un changement de repère, ce qui peut être non trivial).
1 sept. 2005 à 16:13
Globalement la simulation est assez realiste.
J'avais fait un test avec 3 boules se deplacant qu'horizontalement, et au bout de t=58 secondes, les vitesses des boules avaient des composantes verticales du justement aux erreurs.
1 sept. 2005 à 15:58
1 sept. 2005 à 15:12
la je gere successivement les chocs, ce qui je l'avoue n'est pas tres physique car rien ne me dit que c'est equivalent (il n'y a pas associativité des chocs).
c'est là un defaut du programme.
1 sept. 2005 à 08:45
31 août 2005 à 15:08
31 août 2005 à 13:29
comment calculer les rebonds (les chocs).
Il y a deux quantités qui se conservent :
* l'énergie
* la quantité de mouvement
On a ainsi deux équations.
On se place dans le repere (u,v) avec u unitaire et dirige selon les deux centres des boules, et v l'orthogonal direct et
unitaire de u.
Dans ce repere on va changer les vitesses des deux boules pour simuler le rebond. Seul les vitesses selon u change, les
composantes selon v restent inchangees.
On a :
delta(mA.vA² + mB.vB²) = 0
delta(mA.vA + mB.vB) = 0
la solution est (il suffit de verifier) :
vA(apres) = 2.vG - vA(avant)
vB(apres) = 2.vG - vB(avant)
avec vG la vitesse du centre de gravité
voila les seules equations utilisees
(pour ce qui est de la resolution, physiquement parlant : dans un repere se deplacant a la vitesse du centre de gravité, les
vitesses changent seulement de signes, d'ou le resultat car :
v(apres) [-(v(avant)-vG)] + vG 2.vG - v(avant)
Un truc amusant a faire est de mettre 500 boules dans un billards, et cela donne l'effet d'un gaz (analogie non-fortuite) ou
a des abeilles, et je trouve ca beau a voir, essayez donc.
31 août 2005 à 12:56
30 août 2005 à 23:00