Connaitre la position d'un point

[kurstley]

Bonjour à tous (ça fait un sacré bail que j'ai pas posté ici, personne m'en veut ? :heuuu lol

En fait j'ai parcouru pas mal de forum et j'ai pas trouvé une solution à mon problème qui se révèle être un problème de maths plus qu'autre chose ..

Pour résumer j'ai une ville en vue isométrique avec pas mal de bâtiments, et le problème que j'ai c'est pour connaitre le rayon d'action d'un poste de police sur une résidence par exemple.
(je récupère les coordoonées X et Y de la position de mon poste de police et celui de mon bâtiment en question pour savoir si il est ou non dans le champs de mon poste de police)

J'ai donc réussi à l'aide d'une formule, mais cela concerne un cercle autour de mon poste de police.

Donc ma condition :
SI ( ((Xa-Xb)²) + ((Ya-Yb)²) <= R² ) alors ma résidence est bien dans le champs de rayon de mon poste de police.
(Xa et Ya sont les coordonnées du poste de police et Xb etYb sont les coordonnées de la résidence, R étant bien entendu le rayon)

Voila donc cette formule marche très bien, le problème c'est que en vue isomètrique, la largeur est deux fois plus grande que la hauteur, si vous voyez ce que je veux dire, donc en gros je cherche l'équivalent de la formule du cercle pour une ellipse, ce qui ferait un rayon d'action autour de mon poste de police en "cercle applati".

Voila si un matheux passe dans le coin ou si vous avez la solution ou un lien ça m'aiderai énormément.

[keke]

Je dois avoir un problème de compréhension ... la formule est toujours bonne ... c'est pas parce l'IHM change que la formule bouge.

C'est laquelle la coordonnée qui est divisé par 2 ? X ou Y ?

Sinon, c'est peut-être un problème de transformation de coordonnée d'affichage ?
Dans ce cas, il faut jongler avec des cos et des sinus /2.

Kéké qui attends une réunion au téléphone ... grr... ils sont en retard !

[X-ZoD]

looooooool
c'est une blague ?
bon allons reprenons notre serieux ?
quand tu dis un rayon de 2 ... tu pense a 2 cases ?
si c'est le cas il te suffit juste de recuperer les case donc les x et y sont a maximum 2 unité plus loin
non?
moi c'est comme ca que je fais

[kurstley]

Ce sont les Y qui sont divisés par 2 du fait de l'isométrie, j'ai essayé de "bidouillé" la formule du cercle en divisant par 2 les Y, mais ca marche pas ... à priori oui il faudrait certainement intégrer des notions de cos ou sin, mais la ... je suis complètement à la ramasse. La formule est bonne mais applicable qu'à un cercle qui à un rayon en X et Y identique, pour une ellipse c'est plus compliqué étant donné que le rayon d'une ellipse en Y c'est le rayon en X divisé par 2.

C'est pas évident à expliquer, mais en gros quand on veut dessiner un cercle en isométrie, il faut dessiner une ellipse, un "cercle applati" quoi.

---

Non X-Zod quand je dis un rayon de 2 c'est plutôt 2 pixels, puisque j'ai pas de systèmes de "case" ...

[keke]

kurstley >

Tu raisonnes en case par case pour ton "cercle applati", non ?
Tu ne demande pas par exemple, à faire un cercle réel affiché à l'écran, n'est-ce pas ? Ton raisonnement reste uniquement focalisé sur du case par case plutôt que du pixel.

Si c'est le cas, ta formule reste bonne pour déterminer les cases qui sont à moins de R cases de ton poste de police.
Tu as déjà une carte en isométrique donc tu as déjà un algorithme qui transforme l'affichage d'un tableau de donnée en un système un peu penché appelé isométrique. Avec la même formule, il te reste à afficher les cases à l'intérieur de ton cercle et ignorer les autres.

Ton problème n'est pas un problème d'algorithmique, mais un problème de rendu (synonyme d'affichage).

Kéké
PS : Si j'ai rien compris, essaye de nous afficher des screens shots de ton problème

[kurstley]

Kéké t'a bien compris mon problème, mais le souci c'est que je n'est pas comme tu dit d'algorithme qui "transforme l'affichage d'un tableau de donnée en un système un peu penché appelé isométrique".

Je récupère la position X et Y (en pixel) avec une requête SQL de chaque terrain avec un petit while, et ensuite je liste tous les terrains et je replace la position X et Y dans les "left" et "top" de div ...

[jo_link_noir]

Euuh tu me fait peur, t'as mi la requête dans un while ?
Sinon peut-être comme ça : "(Xa-Xb)² + (Ya*2-Yb*2)² <= R²" mais j'suis pas sûr

EDIT : me suis mélangé avec une autre formule...

[kurstley]

J'ai trouvé une solution.
Comment ? je viens de faire un système de "case" !
Du coup tout marche impeccable maintenant !

[Zamentur]

Bon tant mieux mais juste une réaction:
En bdd tu ne dois pas stocker les positions en rendu isométrique tu aurais du stocker ces position de façon normal.
Ensuite faire les calculs, à la limite faire une vue qui te convertisse directement tes positions en positions isométrique.

Que se passerais t'il si tu décidais de changer l'angle de ta vue et d'être en perspective mais pas en vue isométrique parfaite...

Et d'un point de vue mathématique et algorithmique çà aurait été plus simple. La tu as mélangé de la vue (affichage) avec du modèle (la base de donnée)

[wild-D]

pour faire mon chieur:

Et d'un point de vue mathématique et algorithmique çà aurait été plus simple.

il s'économise une transformation à chaque affichage; ça me semble plutot économique de ce point de vue là.

je vois pas en quoi il est interdit d'utiliser un système de coordonnée autre que de l'orthonormé.
par contre derrière faut naturellement utiliser des formules de calcul en conséquence.

après tout si ça évite de devoir justement à chaque fois faire la transformation : plan ortho -> iso pixel
ça paraît pas incohérent comme choix de poser carrément dans son modèle qu'on est dans un système de coord iso pixel.

si un jour il veut s'amuser à passer "en perspective" il va effectivement bcp s'amuser pour récup le contenu de sa bdd et transformer tout dans le nouveau système de coord "perspective pixel" ; sans compter la mise à jour des formule de calculs custom/optimisée pour sont système de coord iso pixel. Mais bon normalement on change pas tous les mois de système de coord.
la possible contrainte pour moi est plutot le fait que ce sera "plus dificile" d'offrir un affichage multiple -en perspective, iso, plan- vu que l'un sera facile les autre donneront a priori plus mal au crâne -mais c'est un a priori-; car techniquement c'est ce qu'on fait quand on est en orthonormé -donc le plan est facile; et qu'on fait les calculs systématique pour la représentation en iso ou perspective-

vu l'économie de calculs que ça peut engendrer sur chaque affichage c'est p-e pas inintéressant comme choix. (enfin a priori je pense pas que ce soit énorme vis à vis des requêtes SQL et autre mais je peux me tromper )