COLLISION DE RECTANGLES 2D
Galmiza
Messages postés
573
Date d'inscription
samedi 16 novembre 2002
Statut
Membre
Dernière intervention
9 avril 2008
-
15 nov. 2006 à 20:08
Arnaud16022 Messages postés 1329 Date d'inscription vendredi 15 août 2003 Statut Membre Dernière intervention 16 juin 2010 - 16 nov. 2006 à 20:30
Arnaud16022 Messages postés 1329 Date d'inscription vendredi 15 août 2003 Statut Membre Dernière intervention 16 juin 2010 - 16 nov. 2006 à 20:30
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/40332-collision-de-rectangles-2d
https://codes-sources.commentcamarche.net/source/40332-collision-de-rectangles-2d
16 nov. 2006 à 20:30
Pour Runge-Kutta : ouff ^^
16 nov. 2006 à 16:59
Il se peut qu'aucun des points des rectangles ne soient à l'intérieur d'un autre rectangle alors qu'il y a collision, met les en croix par exemple ;).
Je vais modifier l'algo pour éviter ce problème.
Une petite question: GLUT monopolise 100% du proc, comment paramétrer GLUT pour éviter ce problème sans mettre de pause dans le code ?
En fait, je me suis planté à propos Lagrange :$, la technique des multiplicateurs de Lagrange permet d'obtenir équations matricielles à coups d'étude énergétique des systèmes d'objets, je ne me souviens plus trop mais elle permet d'éviter d'avoir à intégrer angles et positions.... à vérifier.
Bref, ce n'est pas une technique d'intégration comme je l'ai peut-etre laissé entendre.
Pas de soucis sur les performances et la suprématie :D de Runge-Kutta. Je ne sais pas s'il y a mieux actuellement (mieux = plus rapide ET moins gourmand ET plus précis).
16 nov. 2006 à 12:58
sympa
par contre, tu vois, ca merdouille un peu dès que les rectangles sont un peu trop imbriqués les uns dans les autres.
Runge-Kutta est obsolète ?????!!!!!!?????
Vais aller me renseigner un peu sur ton Lagrange. BAC+2 j'y suis, mais j'ai quand même un doute sur la prise de tête hihi
Pour ta cinématique :
tu vas galérer.
Commence déjà par faire une classe pour que le client puisse avoir le plus d'infos possibles sur la collision.
et gère le cas ou l'un est dans l'autre, ici tu as subtilement évité le cas en mettant des dimension incompatibles ^^
Je ne mets pas de note avant que ça ne soit plus avancé, elle peut monter assez haut cette source ( et être utile à pas mal de monde ). Finalise la :)
16 nov. 2006 à 11:58
Ok je passerais tout en C++ et ajouterais des classes pour le rapport de collision (regrouper contacts + normales aux contacts), ça sera plus facile de faire évoluer la source.
Il n'y a pas que les touches: maintenant on peut tout manipuler avec la souris: clique gauche ou clique droit sur rectangle + glisser.
16 nov. 2006 à 11:53
On peut faire de la simulation cinématique:
dès qu'on a contact, on inverse la vitesse de rotation du rectangle et on fait "rebondir" le vecteur vitesse du rectangle sur l'orthogonal à la normale au contact.
Il n'y a pas de notions d'efforts.
On peut faire de la simulation dynamique:
dès qu'on a contact, on applique l'effort résultant au rectangle.
On déduit l'accélération linéaire et angulaire que doit subit le rectangle (avec à son inertie et à sa masse) puis en intégrant deux fois on obtient sa position et son angle.
Pour intégrer il existe de nombreuses méthodes. Celles que je connais bien sont obsolètes (euler, euler modifié, runge kutta, ...). Pour ceux qui sont intéressés, la méthode actuellement employée par les moteurs physiques est celle des multiplicateurs de Lagrange, extrêmement puissante et accessible sans prise de tête pour des bac+2.
16 nov. 2006 à 11:48
16 nov. 2006 à 11:47
Quoi qu'il en soit :
stuct, c'est mal.
Utilise class.
Pour vérifier collision, fais un proto comme ça :
bool Crectangle::collide ( Crectangle & _rect );
D'ailleurs
Plutôt que de retourner un bool, tu devrais retourner une struct qui donne des infos sur la collision. Problème: on ne peut pas retourner 2 trucs en même temps, et le bool, c'est quand même bien pratique.
Perso je ferais ça :
bool Crectangle::collide ( Crectangle & _rect , CCollisionResults & _results = NULL);
comme ça, ça retourne un bool bien sympathique à l'usage.
Si l'utlisateur a besoin de plus de précision, il fera :
Rect1.Collision(Rect2, Resultats);
et aura des précisions dans Resultats.membres
Attention, faut pas écrire dans Resultats si c'est NULL,hein ^^
pis sinon manque quand même le cas ou l'un est dans l'autre.
Galmiza : ya des touches pour les faire bouger ;)
15 nov. 2006 à 22:04
Comment ça au fur et à mesure ?
Tu parles de plusieurs couches de test genre (sphère + aabb = axis aligned bounding boxes) avant de tester précisement ?
Sinon tu peux actuellement tourner les rectangles avec les touches 'a' et 'z' ainsi que 'q' et 's'.
Je vais rajouter les sphères englobantes et les aabb en visuel et un controle intuitif avec la souris des rectangles sans trop alourdir la source.
15 nov. 2006 à 21:47
J'ai attendu que les deux rectangles sont en mouvement et que le processus de détection de collision sera mis en évidence au fur à mesure.
Je pense que ça sera une bonne amélioration à faire.
Bonne continuation ...
15 nov. 2006 à 20:08