Voila, je suis en train de coder mon 1er jeu en 3D (une sorte de casse brique modifié il faut bien commencer bas ) et je me demandais si quelqu'un peut m'indiquer une ou plusieurs méthodes pour gérer les collisions entre les divers objets en mouvement???

As-tu déjà géré les collisions entre des objets 2D ? Car, finalement, ce n'est qu'une dimension à ajouter, le principe reste identique.

Heu.. oui et non, en fait j'ai deja fait un casse brique (ben oui, ca me fait tripper en plus) sur une TI82 bon, c'est sur que c'était pas pour le plaisir d'y jouer vu la vitesse d'execution
mais le plaisir de proguer... pourquoi pas sur PC? Parce qu'en cours, on n'a pas droit de ramener son PC (surtout en 2nd )!!!
Enfin, pour en revenir aa sujet, la solution que j'avait employée était simple:
J'avait déclaré un tableau a 2 dimensions ou chaque case pouvait contenir ou non une brique. La position de la balle dans l'écran était ensuite ramenée a une position du tableau pour savoir dans quelle case celle-ci se trouvait puis chercher quelle(s) étai(en)t la(les) briques qui étaient touchées. Pour la barre, comme il n'y en avait qu'une (comme la balle) je n'avait qu'a faire un test directement avec les positions respectives des deux éléments.

Cette méthode me parait difficilement réutilisable dans mon projet actuel (sur PC celui-la ) car j'ai l'intention de mettre la posibilité (et presque l'obligation) qu'il y ai plusieurs balles et plusieurs joueurs (4 au maxinum pour l'instant, un pour chaque coté de l'écran de jeu) le problème étant que les briques et les barres des joueurs peuvent être verticales ou horizontales (et dans le futur peut-être obliques, si je met la posibilité de mettre plus de 4 joueurs).
En plus ma méthode gérait la balle comme si elle était carrée, ce que je préfèrerait éviter sur un PC ou les ressouces sont (légèrement ) plus interressantes.

pour les collisions, il faut prendre des modèles simples:
des boîtes, des sphères (ou plus généralement des ellipsoïdes), des quads ou des triangles.

Pour les barres je conseille des boîtes mais c'est à toi de voir...

Le reste est assez simple, tu regarde la trajectoire de 2 objets pour savoir s'ils se cognent. Il faut considérer la nouvelle et l'ancienne position de chaque objet et regarder s'ils ne se sont pas pénétrés ou traversé (pour éviter qu'un coup de rame ne perturbe le jeu). Ensuite pour les rebonds, tu récupère la normale à chaque objet au point de contact et tu utilise le modèle physique qui te plaît pour simuler le rebond (rebond élastique par exemple).

j'espère que j'ai répondu à ta question

Euh... je suis assez mauvais en maths et je n'ai pas compris grand chose a ce que tu as dit
Dans ta méthode, il faut tester tous les points de chaque objet pour chaque objet?
Ce n'est pas un peu lourd? Si il y a 3 objet, il faut tester 2 fois tous les points de chaque objet?
Arrivé a 100, ca rique d'être assez long, non?

Mais ton casse brique est il vraiment en 3D ?
La balle se déplace elle dans les trois dimensions ?

Ou alors la 3D ne sert qu'a faire joli et dans ce cas les routines de
collisions 2D conviennent à merveilles

(Comme dit zuzuf le modèle des sphères et des boites, quand il s'agit de collisions
simples peuvent être très éfficaces.

Dans ce cas bête calcul de distance avec des racines
(ou alors tu laisses tout au carré (ca ne change rien !) et tu soustrais les rayons pour des sphères,

Ou collisions carrées et rectangulaire, comme en 2D avec un Z en plus.

Polygone à polygone ... Ca en vaut vraiment le coup pour un cassebrique ?

"Mais ton casse brique est il vraiment en 3D ?
La balle se déplace elle dans les trois dimensions ?" => oui

"Dans ce cas bête calcul de distance avec des racines
(ou alors tu laisses tout au carré (ca ne change rien !) et tu soustrais les rayons pour des sphères," => pas d'accord! la racine consomme plus de cycles horloge que le carré. Si on veut optimiser au maximum, il est plutot conseillé de laisser les carrés, je penses, non?

"Polygone à polygone ... Ca en vaut vraiment le coup pour un cassebrique ?" => non, je ne penses pas, mais si je parvient a trouver une solution acceptable (voire la plus précise possible ) j'essayerai surement de faire des choses plus complexes qu'un casse-brique.
En fait, j'aime la programmation des casse-brique parce que c'est simple et permet d'introduire plusieurs notions qui sont les bases des jeux en temps réels (en tout cas, c'est ce que je pense )

moi pour un casse briques j'utiliserait des sphères pour les balles, des ellipsoïdes pour les barres des joueurs et des boïtes pour les briques (à moins qu'elles ne soient sphériques elles aussi...).

Pour ce qui est de la détection polygone à polygone, c'est à proscrire absolument s'il ne s'agit pas d'un simulateur physique super précis qui n'est pas censé tourner en temps réel: imaginez 2 monstres en 3D de 1000 polygones chacun voire plus se tapant dessus...s'il faut tester une collision pour chaque paire de triangles, puis prendre le point d'impact le plus proche...ça rappelle un peu les algorithmes de lancer de rayons (c'est tout sauf du temps réel!!). La seule chose que l'on peut envisager pour faire un test pour chaque polygone est l'intersection d'un rayon avec un modèle (mais pas sans faire de tests plus simples avant!!) pour savoir par exemple si on a touché quelqu'un dans un jeu de tir

Quand je te disais de laisser tout au carré c'était pour éviter le sqrt(...)
évidemment c'est plus rapide.

Maintenant que j'y repense, ta batte ne représente qu'une portion de plan
de collision (tes balles ou autres ne vont pas rebondir sur ses cotés ? De toute façon ça ne compliquerait en rien l'algo), dans ton cas on peut largement simplifier le truc car tes plans sont verticaux ou horizontaux si je ne m'abuse.

Tu calcules donc pour chaque sphère la distance au plan correspondant au plan de collision
(ex : le plan du dessus de la batte)
(avec les équations paramétriques ou la formule bidon niveau terminale), tu calcules en même temps le projeté du centre de la
sphère sur le plan, et tu vérifies bien que ce projeté est contenu
dans la portion de plan qu'est la surface de ta batte (avec l'aide de deux vecteurs directeurs orthogonaux unitaires de ton plan) (en gros tu vérifies que dans cette base, le projeté s'exprime avec des
coordonnées comprises entre 0 et 1).

Après deux solutions, soit tu considère que c'est suffisament précis
pour ton application sachant que y'aura des ratés (une sphère ne
se résume pas en son projeté) ou tu considères dans la vérification
une tolérance de +- le rayon de la sphère (à exprimer dans la base précédente) ce qui te donnera un coéfficient (en sin ou cos) sur la distance réelle au plan de ta sphère

En espérant être compris ... Je dois partir.
Salut.

Erf... Ca remonte, ce topic ^^
Merci, je pense avoir compris ce que tu veux dire.

En gros, utiliser les distances des objets (balles ou barre) pour effectuer un 1er tri, puis vérifier si l'objet testé est rentré dans l'objet de référence.
C'est bien ça? (Je passe les détails mathématiques que tu m'as filé, faudra que je trouve un site pour apprendre les maths, j'ai jamais pu accrocher à cette matière "inutile" lol)

Entre nous le plus logique serait sans doute de ne pas réinventer la roue et d'utiliser un "moteur physique" du style Bullet Physics ou OpenDE (Open Dynamics Engine).