14-08-2019, 11:41 AM
C'est une méthode adaptée à tout pavage hexagonal régulier du plan, qu'importe l'orientation des tuiles (pas sûr que t'arrives à te représenter un pavage tourné de 30°, 45° ou 90° dans ta modélisation 3D)
Hexagones aplatis => Oui, tu fais une transfo initiale pour retomber sur un hexagone régulier et c'est terminé (ou tu transforme le POLYGON dans la query ci-dessus en appliquant un facteur sur X et sur Y, niveau changement, ça va, j'attends de voir les changements dans le modèle X/Y/Z). Ca vaut pour toutes les représentations d'ailleurs, et toutes les transformations linéaires (suffit d'en inverser la matrice pour retomber sur du régulier, ou de l'appliquer au POLYGON). D'ailleurs, l'hexagone aplatit peut l'être dans un plan toujours euclidien, et je ne suis pas certain que tu arrives à te représenter correctement la transformation 3D associées, sachant qu'on partait de ce sujet et qu'elle est (de mémoire) uniquement adaptée aux hexagones réguliers
Représentation en graphe => Oui, tu fais juste un parcours du graph, quelque soit le pavage, y'a pas à discuter là, et y'a pas de représentation 3D/pas 3D qui tienne. C'est, IMO, le meilleur système d'ailleurs puisque très souple et adaptable à un paquet de types de tuiles/pavages plus originaux (c'est l'approche d'ECLERD d'ailleurs). Avec les WINDOW FUNCTIONS de mysql 8, je pense même que c'est performant
Pas besoin de faire de la trigo => Y'a pas de trigo dans mon dernier exemple, et mis à part ça, je trouve l'argument très mal venu. Quand la trigo est un outil adapté, on s'en sert, je maintiens que si un "dev" informatique ne sait pas faire de la trigo, c'est clairement pas un ingénieur. Puis bon, à ce compte-là, tu fais aussi de la trigo avec une représentation 3D (c'est de la trigo dans l'espace d'ailleurs)
Là, j'ai l'impression de partir dans le débat stérile où le postulat "la représentation 3D proposée dans l'article est top pour connaitre les tuiles à une distance de manhattan donnée d'une autre tuile, puisque c'est dans un article" sera de toute façon inébranlable (par définition du postulat, ou parce que "ah, ouais, je me suis peut-être gourré" est trop difficile à dire), donc bon, même si ce ne sera pas hyper-diplomatique comme formule, je dis: quand tu trouveras un argument plus percutant (meilleures perfs SQL? une "applicabilité" à plus de cas/plus de types de tuiles/d'agencements de tuiles?) en faveur de cette représentation 3D, je reviendrai répondre avec plaisir. Si c'est pour se cantonner à "ouais mais non, ton truc est moins bien", je passe mon tour. Chacun modélisera comme il veut son jeu, j'espérai juste éviter qu'il ne faille 3s/page à cause d'un mauvais algo implémenté en SQL.
Hexagones aplatis => Oui, tu fais une transfo initiale pour retomber sur un hexagone régulier et c'est terminé (ou tu transforme le POLYGON dans la query ci-dessus en appliquant un facteur sur X et sur Y, niveau changement, ça va, j'attends de voir les changements dans le modèle X/Y/Z). Ca vaut pour toutes les représentations d'ailleurs, et toutes les transformations linéaires (suffit d'en inverser la matrice pour retomber sur du régulier, ou de l'appliquer au POLYGON). D'ailleurs, l'hexagone aplatit peut l'être dans un plan toujours euclidien, et je ne suis pas certain que tu arrives à te représenter correctement la transformation 3D associées, sachant qu'on partait de ce sujet et qu'elle est (de mémoire) uniquement adaptée aux hexagones réguliers
Représentation en graphe => Oui, tu fais juste un parcours du graph, quelque soit le pavage, y'a pas à discuter là, et y'a pas de représentation 3D/pas 3D qui tienne. C'est, IMO, le meilleur système d'ailleurs puisque très souple et adaptable à un paquet de types de tuiles/pavages plus originaux (c'est l'approche d'ECLERD d'ailleurs). Avec les WINDOW FUNCTIONS de mysql 8, je pense même que c'est performant
Pas besoin de faire de la trigo => Y'a pas de trigo dans mon dernier exemple, et mis à part ça, je trouve l'argument très mal venu. Quand la trigo est un outil adapté, on s'en sert, je maintiens que si un "dev" informatique ne sait pas faire de la trigo, c'est clairement pas un ingénieur. Puis bon, à ce compte-là, tu fais aussi de la trigo avec une représentation 3D (c'est de la trigo dans l'espace d'ailleurs)
Là, j'ai l'impression de partir dans le débat stérile où le postulat "la représentation 3D proposée dans l'article est top pour connaitre les tuiles à une distance de manhattan donnée d'une autre tuile, puisque c'est dans un article" sera de toute façon inébranlable (par définition du postulat, ou parce que "ah, ouais, je me suis peut-être gourré" est trop difficile à dire), donc bon, même si ce ne sera pas hyper-diplomatique comme formule, je dis: quand tu trouveras un argument plus percutant (meilleures perfs SQL? une "applicabilité" à plus de cas/plus de types de tuiles/d'agencements de tuiles?) en faveur de cette représentation 3D, je reviendrai répondre avec plaisir. Si c'est pour se cantonner à "ouais mais non, ton truc est moins bien", je passe mon tour. Chacun modélisera comme il veut son jeu, j'espérai juste éviter qu'il ne faille 3s/page à cause d'un mauvais algo implémenté en SQL.