Collision pixel perfect

UltimAKnighT Messages postés 34 Date d'inscription samedi 21 janvier 2006 Statut Membre Dernière intervention 12 juillet 2008 - 20 nov. 2006 à 20:48
UltimAKnighT Messages postés 34 Date d'inscription samedi 21 janvier 2006 Statut Membre Dernière intervention 12 juillet 2008 - 24 nov. 2006 à 21:04
Bonjour,

Savez-vous où je pourrais trouver de la documentation là-dessus(en
français de préférence) car j'ai eu beau chercher, les tutos sur
lesquels je suis tombés n'expliquaient pas clairement le principe et
surtout le mécanisme de ce type de collision.

Ou alors, est ce que quelqu'un d'entre vous pourrait me l'expliquez, si bien sûr ça ne le gênes pas.


Merci.


                                                     UltimAKnighT.

13 réponses

Galmiza Messages postés 573 Date d'inscription samedi 16 novembre 2002 Statut Membre Dernière intervention 9 avril 2008 1
20 nov. 2006 à 21:40
0
UltimAKnighT Messages postés 34 Date d'inscription samedi 21 janvier 2006 Statut Membre Dernière intervention 12 juillet 2008
22 nov. 2006 à 18:51
Merci de votre réponse.

J'ai déjà été voir ce tuto auparavant, mais celui-ci ne m'avait pas satisfait, je n'ai pas réussi à cerner les explications, c'est pourquoi je cherche à obtenir un cours expliqué disons plus simplement, pour que je puisses comprendre le mieux possible.
0
Galmiza Messages postés 573 Date d'inscription samedi 16 novembre 2002 Statut Membre Dernière intervention 9 avril 2008 1
22 nov. 2006 à 19:48
Qu'est ce qui te tracasse ?
Le principe ?
L'algorithme ?
Le code en C ?
0
UltimAKnighT Messages postés 34 Date d'inscription samedi 21 janvier 2006 Statut Membre Dernière intervention 12 juillet 2008
22 nov. 2006 à 20:39
Ben je pense avoir cerner un peu le principe ( si j'ai bien compris ça joue sur la transparence d'un pixel ou quelque chose dans le genre).
Mais ce qui me tracasse vraiment c'est l'algorithme.
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
UltimAKnighT Messages postés 34 Date d'inscription samedi 21 janvier 2006 Statut Membre Dernière intervention 12 juillet 2008
23 nov. 2006 à 20:51
up!
0
Galmiza Messages postés 573 Date d'inscription samedi 16 novembre 2002 Statut Membre Dernière intervention 9 avril 2008 1
23 nov. 2006 à 22:01
Salut,

Les ups ne fonctionnent pas comme sur les forums "ordinaires".
Par contre ca envoie un mail à ceux qui ont participé au topic ;).

Tu as deux rectangles qui sont en fait tes deux images.
Tu regardes si ces deux grands rectangles sont en contact.
si x_max de l'un est plus petit que x_min de l'autre etc...

Si ils sont en contact, tu procedes à l'analyse pixel par pixel.
La zone de contact est bien entendu un rectangle.

Tu boucles sur la surface de ce rectangle, pixel par pixel.
Pour chaque pixel (x,y), tu détermines les coordonnées des pixels correspondants sur les deux images (x1,y1) et (x2,y2).
Si le pixel en (x1,y1) sur l'image 1 est opaque ET le pixel (x2,y2) de l'image 2 est opaque, tu as collision.
Après tu peux colorier le pixel en rouge pour faire joli mais c'est accessoire.

A quel niveau est ton problème ?
0
UltimAKnighT Messages postés 34 Date d'inscription samedi 21 janvier 2006 Statut Membre Dernière intervention 12 juillet 2008
24 nov. 2006 à 19:16
Désolé pour le derangement, je ne savais pour le up.

Sinon j'ai quelques questions, comment sait-on si un pixel est opaque? et, une boucle de la surface demande beaucoup de ressources processeur (surtout si il y a plusieurs collisions en meme temps) il n'y aurais pas moyen de faire quelque chose de moins gourmand?
Une derniere question, comment assigner à un pixel sur une image 1, un homologue sur l'image 2, car ce choix doit être fait pour chaque surfaces en contact, n'importe oû sur les deux images (rectangles). (je ne sais pas si j'ai été tres clair, si non fat le moi savoir).

Merci.
0
Galmiza Messages postés 573 Date d'inscription samedi 16 novembre 2002 Statut Membre Dernière intervention 9 avril 2008 1
24 nov. 2006 à 19:36
Salut,

Un pixel est opaque si son canal alpha est nul (ou plein je ne sais plus).
Mais bon tu peux dire que 2 pixels sont en collision si la somme de leur canal alpha (0-255) est au dessous 128, ou leur produit est au dessous de 97... c'est arbitraire.

Regarde ce schéma:
http://galmiza.free.fr/FTP/collision_perfect.PNG

Dans ce cas, le rectangle a pour coordonnées haut gauche: (x2,y2), pour largeur L=(l1-(x2-x1)), pour hauteur H=(h1-(y2-y1)).
En faisant plusieurs dessins du même type tu trouveras les différentes configurations possibles.
Ensuite tu fais 2 for imbriqués:
for (i=0;i<L;i++)
 for (j=0;j<H;j++)
  // pixel de l'image 1 correspondant: ((x2-x1)+i, (y2-y1)+j)
  // pixel de l'image 2 correspondant: (x2+i, y2+j)

Evidemment il faut prendre en compte quelques cas mais ce n'est pas trop compliqué.

C'est très gourmand en ressource effectivement (c'est pour ca que je n'ai jamais envisagé de l'utiliser ;)).
Pour aller plus vite (beaucoup plus vite en fait), tu peux assimiler les images sur tes sprites à plusieurs rectanges.
Ainsi tu testes les collisions entre les rectangles sur tes images et pas les pixels.
0
UltimAKnighT Messages postés 34 Date d'inscription samedi 21 janvier 2006 Statut Membre Dernière intervention 12 juillet 2008
24 nov. 2006 à 20:06
Hum je pense que je commence à comprendre.
Quand tu dis "assimiler les images sur tes sprites à plusieurs rectanges", c'est à dire en gros que l'on coupe une image en bande c'est ça?

Je définis mon idée général : Mon objectif est de créé un moteur physique, que je pourrais utilisé (ou d'autres personnes) pour faire des applis 2D necessitant une gestion des collisions.
0
Galmiza Messages postés 573 Date d'inscription samedi 16 novembre 2002 Statut Membre Dernière intervention 9 avril 2008 1
24 nov. 2006 à 20:25
Pas spécialement en bandes, mais en rectangles qui approximent l'image dans l'optique de remplacer les comparaisons entre pixels par des détections de collisions entre rectangles simples.
Pour une image d'humain complet de face, tu aurais un rectangle pour sa tête, un rectangle pour son corps, deux pour ses jambes etc... autant que tu veux en fait. Plus tu en auras plus ta collision sera précise.
Après il y a des techniques si tu veux économiser du temps de calcul: si plusieurs rectangles Ri sont dans un rectangle, et que ce rectangle n'est pas en collision avec les rectangles d'une autre image, alors tu peux zapper le test de collision avec les rectangles Ri.

J'ai recemment déposé une source de collision de rectangle 2D avec rotation pour permettre de faire un moteur physique 2D. Elle donne point de contact et normale au contact.
Peut-être que ça peut servir pour ton moteur physique.
0
UltimAKnighT Messages postés 34 Date d'inscription samedi 21 janvier 2006 Statut Membre Dernière intervention 12 juillet 2008
24 nov. 2006 à 20:34
Ok jvais aller jeter un coup d'oeil sur ta source.
Sinon, quand tu dis un rectangle pour la tete...etc cette methode est pratique pour seulement deux images en collisions, mais si tu en as plusieurs. Comme dans un jeu par exemple, on va pas s'amuser à definir pour chaque tileset, pnj...etc des rectangles, je vais essayez de transcrire ça dans un cas général pour mon code.
0
Galmiza Messages postés 573 Date d'inscription samedi 16 novembre 2002 Statut Membre Dernière intervention 9 avril 2008 1
24 nov. 2006 à 20:39
Pour un jeu en tileset, ma source est inutile ;).
Sinon la méthode des rectangles est laborieuse mais tu peux faire un scan des pixels et trouver de façon automatique les rectangles pour chaque tileset.
Ca demande un peu de reflexion sur papier mais en 2D ça doit être faisable.
0
UltimAKnighT Messages postés 34 Date d'inscription samedi 21 janvier 2006 Statut Membre Dernière intervention 12 juillet 2008
24 nov. 2006 à 21:04
Ok ben merci, je vais tenter de réaliser tout ça, je te tiendrai au courant, si j'ai un quelconque problemes.
C'est sympa de m'aider ^^, merci encore.
0
Rejoignez-nous