[Géométrie]Collision

edition: (Résolu) cet état peut changer en fonction du temps, merci de votre compréhension

Je suis en train de modéliser un petit monde pour un programme de bateau si l'on peut dire.


Ma classe Monde a comme attributs:

* Un rectangle, qui représente le monde entier.
* Une ArrayList de bateau
* Une zone naviguable, représentée par un ensemble de Polygone, contenus dans une ArrayList


Une classe bateau a comme attributs:

* un rectangle, représentant le bateau SANS se soucier de son orientation
* un angle dit "d'orientation" représentant la direction du bateau. 0= vers la droite, le sens est horloger.

Une méthode public Shape getActuallRectangle() renvoit le rectangle auquel a été appliqué la rotation adéquate.

Les bateaux se déplacent bien sûr, en fonction de divers choses.


Mon souci est le suivant:

Je veux tester qu'un bateau ne peut sortir de la zone naviguable.
Quelle méthode me permettrait de tester qu'un Shape est bien contenu dans un des polygones de "naviguable" ?

L'arrayList des polygones "naviguable" ne peut-elle pas être remplacée par un objet? qui représenterait une sorte de polygone non-convexe.
(non-convexe car il peut exister des iles).


En espérant que vous pourrez (et voudrez bien) m'aider.
Zeil

PS: Les épinards, c'était pour faire un titre stylé.

Citation:

---

Je veux tester qu'un bateau ne peut sortir de la zone naviguable.
Quelle méthode me permettrait de tester qu'un Shape est bien contenu dans un des polygones de "naviguable" ?

---

Tu peux faire ca assez facilement avec les méthodes contains() et intersects() de l'interface Shape. De plus n'oublie pas que ta forme même "rotationnée" avec un angle dispose quand même d'un boite englobante rectangulaire (getBounds() et getBounds2D()) ce qui permet de te simplifier grandement une partie des calculs.

- si boite englobante (de la forme transformée) n'intersecte pas les bordures de l'ocean alors peut naviguer
- sinon faire plus de test sur la vrai forme transformée.

Pour plus de détail sur des algorithmes de collision je t'invite à regarder (et poser des questions sur) les forum 2D de JavaGaming.org.

Citation:

---

L'arrayList des polygones "naviguable" ne peut-elle pas être remplacée par un objet? qui représenterait une sorte de polygone non-convexe.
(non-convexe car il peut exister des iles).

---

Ensuite la classe Area permet EDIT - d'ajouter et de soustraire une forme à une autre. Egalement GeneralPath dispose de regles pour déterminer ce qui est ou pas à l'intérieur d'une forme. Je pense cependant que pour le calcul des collisions il est préférable de gartder quand même les formes des îles à part (en plus de la forme de l'ocean - celles des îles).

Citation:

---

Envoyé par Zeil

(non-convexe car il peut exister des iles).

---

En fait même si il n'y avait pas d'île, il pourrait ne pas être convexe. Convexe, ça veut dire que la région est "arrondie". Plus formellement, si deux points appartiennent au polygone, le segment les joignant aussi.
C'était la petite parenthèse culturelle :P


Pour répondre à ta question :
http://java.sun.com/j2se/1.5.0/docs/...m.Rectangle2D)

Citation:

---

Envoyé par Zeil

PS: Les épinards, c'était pour faire un titre stylé.

---

lol :D

Merci pour vos réponses.

Je vais donc utiliser les méthodes dont vous avez parlé mais je me dis que ce sera quand même bien long en temps de calcul pour juste cela :(

Je ferais un test de charge avec une 10aine de clients et je viendrais râler si ca n'est pas concluant. (parce que râler, c'est stylé)

Encore merci

Citation:

---

quand même bien long en temps de calcul pour juste cela

---

Alala il ne faut pas desesperer, d'autant plus que tous les jeux 2D ou 3D, vectoriels ou bitmaps ou ils y a des trucs qui bougent utilisent des algorithmes de collision de ce genre.
Et oui l'usage de la boite englobante permet d'eviter des calculs inutiles et souvent bien plus longs sur les formes reelles.

D'ailleurs dans un premier temps tu peux tout simplement te restreintre aux boite englobantes sans chercher a calculer plus loin. Ca marche deja relativement bien (c'est juste beaucoup moins precis...).