#0 

16-07-2007 17:47:23

izguit
Administrateur
Lieu: 127.0.0.1
Date d'inscription: 14-09-2006
Messages: 306
Site web

Salut tout le monde,
La lib de pathfinding que je code commence à ressembler à quelque chose (enfin à devenir utilisable)
Pour l'instant il fait :
- Résolution de chemin par l'algo A* dans un graphe 2D (une matrice)
- Coûts de déplacement modifiables (si vous voulez que telle ou telle case soit de l'herbe, sable, bitume ou autre, l'algo en tiendra compte)

A venir (peut etre) :
- Résolution dans un univers 3D ? (je vois l'intéret que pour les simulateurs de vol/spatiaux)
- threads? Ca serait sympa même si pour l'instant je le trouve pas lent.

En gros à utiliser ca donne ça :

Code:

#include <yasp.h>
#include <iostream>

int main()
{
    // First, we create the graph
    yasp::CGraph *world;
    world = new yasp::CGraph(20);

    // Then, we make some squares unwalkable...
    for (int y = 1 ; y < 6 ; y++)
        world->getSquare(4,y)->setState(yasp::CSquare::ST_UNWALKABLE);

    for (int x = 1 ; x < 4 ; x++)
        world->getSquare(x,4)->setState(yasp::CSquare::ST_UNWALKABLE);

    // ... and we make some others slow
    for (int y = 3 ; y < 8 ; y++)
        world->getSquare(2,y)->setMoveCost(40);

    // We call the finder and give him the graph...
    yasp::CPathFinder aStarFinder(world);
    // And we solve it.
    yasp::CPath shortestPath = aStarFinder.find(world->getSquare(2,2),world->getSquare(8,8));

    std::cout << "Chemin choisi :" << std::endl;

    for(int i = 0 ; i < shortestPath.getSize() ; i++ )
        std::cout << "X = " << shortestPath.getSquareCoords(i).x << " et Y = " << shortestPath.getSquareCoords(i).y << std::endl;

    return 0;
}

Mais bon je sais pas si c'est utilisable partout. Comment vous voudriez que ça se présente pour l'utiliser dans votre projet? L'utilisation de matrice limite peut-être les possibilités?

plouf


Athlon 64 3000+ // 1Go RAM // Geforce 6600GT 128Mo
Turion 64 X2 // 1Go RAM // ATI X1250

Hors ligne


#1 

16-07-2007 19:10:32

Jerry Kan
Habitué
Date d'inscription: 21-11-2006
Messages: 265

izguit :

A venir (peut etre) :
- Résolution dans un univers 3D ? (je vois l'intéret que pour les simulateurs de vol/spatiaux)


hmm, t'est sur ? imagine un univers pas plat, avec des étages, ou des surplomb, ca pourrai etre sympa d'avoir enfin un pathfindig qui ne pense qu'a son étage smile mais bon pas forcé de passer par une matrice 3d, en tout cas je trouve quand meme l'idée sympa

izguit :

- threads? Ca serait sympa même si pour l'instant je le trouve pas lent.


de la logique floue ca pourrai etre super class, genre si on demande un résolution, le path find donne la derniere meilleure solution connue,

izguit :

Mais bon je sais pas si c'est utilisable partout. Comment vous voudriez que ça se présente pour l'utiliser dans votre projet? L'utilisation de matrice limite peut-être les possibilités?


je suis d'accord, un graphe matriciel ca pourrait etre pas mal aussi

bon courrage, ca a l'air cool smile

Dernière modification par Jerry Kan (16-07-2007 19:11:01)

Hors ligne


#2 

16-07-2007 19:21:33

Perceval
Abonné
Date d'inscription: 20-10-2006
Messages: 105

Ca a l'air intéressant ca smile

Résolution dans un univers 3D ? (je vois l'intéret que pour les simulateurs de vol/spatiaux)


Je penses que ce serait très utile, et pas seulement pour les simulateurs de vol (imaginons un batiment à plusieurs étages dans un FPS, une matrice seule ne suffit sans doute pas).

L'utilisation de matrice limite peut-être les possibilités?


Certainement. A mon avis, le mieux serait d'avoir une classe abstraite, CGraphe, et plusieurs classes qui en dérivent : une représentation en matrice et une représentation en graphe (ou chaque noeud contient la liste des noeuds qui sont en relation avec lui). Après, l'utilisateur voit quelle est la représentation la plus adaptée (si il a juste un terrain, sans étages, comme dans la plupart des RTS par exemple, la représentation sous formes de matrices me parait plus adapté).
Enfin, c'est juste des suggestions, mais je penses que tu devrait implémenter de "vrais graphes".
Je te souhaites bon courage pour la suite, et je vais suivre ce thread avec attention smile

Hors ligne


#3 

16-07-2007 19:30:40

izguit
Administrateur
Lieu: 127.0.0.1
Date d'inscription: 14-09-2006
Messages: 306
Site web

merci de vos réponses ça fait plaisir smile

Jerry :

hmm, t'est sur ? imagine un univers pas plat, avec des étages, ou des surplomb, ca pourrai etre sympa d'avoir enfin un pathfindig qui ne pense qu'a son étage  mais bon pas forcé de passer par une matrice 3d, en tout cas je trouve quand meme l'idée sympa


Bin le problème quand je parlais de pathfinding 3d c'est que les successeurs du node seraient tout ceux autour de celui-çi, donc il chercherait même en "volant", pas seulement au raz du sol (j'ai un peu de mal à l'expliquer smile )

Jerry :

de la logique floue ca pourrai etre super class, genre si on demande un résolution, le path find donne la derniere meilleure solution connue,


Pas encore regardé de ce côté là, je vois pas trop ce que tu veux dire par "la dernière meilleure solution connue"

Perceval :

Certainement. A mon avis, le mieux serait d'avoir une classe abstraite, CGraphe, et plusieurs classes qui en dérivent : une représentation en matrice et une représentation en graphe (ou chaque noeud contient la liste des noeuds qui sont en relation avec lui).


Ouais ça va peut se faire facilement. En revanche ça peut être le bordel à utiliser, faut déclarer tous les noeuds, avec tous leurs successeurs et les couts de déplacement de chacun. C'est un peu pour ça que je suis pas parti de ce côté-là (aussi parce que je dois l'utiliser avec un systeme de terrain tile-based)

Pour l'utilisation de thread je laisse tomber, autant faire tourner la fonction globale du pathfinder dans un thread si besoin.


Athlon 64 3000+ // 1Go RAM // Geforce 6600GT 128Mo
Turion 64 X2 // 1Go RAM // ATI X1250

Hors ligne


#4 

16-07-2007 19:47:40

Perceval
Abonné
Date d'inscription: 20-10-2006
Messages: 105

faut déclarer tous les noeuds, avec tous leurs successeurs et les couts de déplacement de chacun


Dans ce cas là, je penses qu'il faudrait un outil pour éditer les noeuds du graphe, puis les sauver dans un fichier (si je me souviens bien, worldcraft, l'éditeur de Half life, faisait un truc comme ca : on plaçait des nodes un peu partout sur la carte, autour des poteaux, aux angles des couloirs, partout où les NPC étaient sensés pouvoir aller).

Pour l'utilisation de thread je laisse tomber, autant faire tourner la fonction globale du pathfinder dans un thread si besoin.


T'as raison wink Ca me paraît pas très utile, et çà risque de compliquer sérieusement le tout smile

Hors ligne


#5 

16-07-2007 20:50:15

izguit
Administrateur
Lieu: 127.0.0.1
Date d'inscription: 14-09-2006
Messages: 306
Site web

je vais voir pour un plugin pour irrEdit, ça pourrait être intéressant, en plus de la matrice.


Athlon 64 3000+ // 1Go RAM // Geforce 6600GT 128Mo
Turion 64 X2 // 1Go RAM // ATI X1250

Hors ligne


#6 

16-07-2007 23:35:16

firnafin
Abonné
Date d'inscription: 31-03-2007
Messages: 150

salut;

il est vrai que a avoir fait le systeme du graphe autant l'utiliser pour les algos comme une liste d'adjacence ainsi c'est a l'utilisateur de le transformer en structure 2d ou 3d de plus ca ne complique en rien la programmation des algo si mes souvenirs sont bons ( voir meme ca les facilites ... ).
Enfin puisque le systeme de graphe est fait ,coder les algos c'est plus tres dur alors pourquoi ne pas proposer autre chose que la A* car certain sont plus rapide sur certain type de graphe (complexite algorithmique fonction du nombre de sommets ou  nombre d'arretes ) ... c'est tres optionnel a vrai dire .

Hors ligne


#7 

16-07-2007 23:59:19

Copland
Modérateur
Lieu: ZarbiLand
Date d'inscription: 22-09-2006
Messages: 657
Site web

Bon moi je sais pas quoi dire, j'attends avec impatience de voir si ça sera intégrable dans mon jeux, ça me ferai gagner beaucoup de temps ^^.
Sinon tu prévois une démo quand même qu'on puisse tester rapido pour les fégnasses comme moi ? big_smile


Config : I5 2400, ATI HD6870 1Go DDR5, 4Go DDR3.
Single Boot : Windows Seven.

Hors ligne


#8 

17-07-2007 10:19:43

khayyam
Membre
Date d'inscription: 04-03-2007
Messages: 25
Site web

Une lib de pathfinding, ça m'intéresse aussi pas mal.

Après un rapide parcours du thread, on dirait que ta résolution s'effectue uniquement dans un espace discret. Et on peut implémenter A* dans un milieu continu au moyen d'une petite bidouille élégante .... à réfléchir
Ta résolution se fait en un appel (qui est forcément long). Ne faudrait-il pas faire une résolution étape par étape, comme quand une unité est arrivée à un noeud et cherche quel sera le noeud suivant, quitte à implémenter les 2 ? Ca permet une résolution non omnisciente et donc plus réaliste (encore que, c'est discutable).
Une biblio de pathfinding fait appel à des contraintes de temps réel pour lesquelles il ne faut rien calculer qui pourrait se retrouver changé. Si une unité vient se placer sur le chemin, la solution ne sera plus bonne. Une utilisation de threads serait discutable, surtout si on ne calcule qu'un infime morceau du chemin à chaque appel.

Mais c'est une très bonne initiative, qui pourra être très intéressante si elle est suffisamment souple.

Hors ligne


#9 

17-07-2007 12:25:27

izguit
Administrateur
Lieu: 127.0.0.1
Date d'inscription: 14-09-2006
Messages: 306
Site web

je m'attendais pas à autant de feedback smile

@ firnafin : Plus rapide que A* en pathfinding? t'as des liens? Perso jamais rencontré plus facile (quoique j'ai jamais regardé les réseaux neuronaux mais ca me parait un poil merdique à implémenter pour du pathfinding smile ) Mais ça m'intéresse.

@ Coco : Ouais une démo est prévue mais je trouve toujours des trucs à ajouter/modifier dans la lib et la démo de test est toujours aussi ..... pourrie smile

@ khayyam : Une résolution "noeud par noeud" comme tu le cite n'est pas vraiment possible avec A* (enfin si, mais on perd l'intéret de l'algo). Mais je vois ce que tu veux dire. Il faudrait plutot rechercher le chemin et mettre à jour le graphe à chaque "découverte" d'un obstacle, et réeffectuer la recherche. (Enfin c'est comme ça que je le verrais perso ; si vous avez d'autres idées...)


Athlon 64 3000+ // 1Go RAM // Geforce 6600GT 128Mo
Turion 64 X2 // 1Go RAM // ATI X1250

Hors ligne


#10 

17-07-2007 12:30:02

Jerry Kan
Habitué
Date d'inscription: 21-11-2006
Messages: 265

izguit :

[quote=Jerry]hmm, t'est sur ? imagine un univers pas plat, avec des étages, ou des surplomb, ca pourrai etre sympa d'avoir enfin un pathfindig qui ne pense qu'a son étage  mais bon pas forcé de passer par une matrice 3d, en tout cas je trouve quand meme l'idée sympa


Bin le problème quand je parlais de pathfinding 3d c'est que les successeurs du node seraient tout ceux autour de celui-çi, donc il chercherait même en "volant", pas seulement au raz du sol (j'ai un peu de mal à l'expliquer smile )[/quote]
t as raison, je vois ce que tu veux dire,

ca pourrai etre pas mal avec un graphe matriciel, yaurai alors juste a relier des endroits, et c'est encore plus souple que la 3d (imaginons des téléporteurs sur la map)

izguit :

[quote=Jerry]de la logique floue ca pourrai etre super class, genre si on demande un résolution, le path find donne la derniere meilleure solution connue,


Pas encore regardé de ce côté là, je vois pas trop ce que tu veux dire par "la dernière meilleure solution connue"[/quote]
en gros l'idée c'est de lancer un pathfind dans un thread, et quand le temps critique est attein (le perso DOIT se déplacer) on demande au thread,
ca fait longtemps que j'ai plus touché le a*, mais il va trouver plusieurs solutions et les évaluer non ? imginons que quand on l'interroge, il en ai trouvé, mais qu'il n'ai pas TOUT trouvé,  ca pourrai etre sympa d'avoir une solution approximative, ( par exemple la premiere solution qui se rapproche de la moitié de la distance)  ou une premiere solution sans etre sure que cette solution est optimale
( a noter que ces deux algos sont bien sur tres basique, il y a moyen de faire des choses tres complexe avec le flou)

Pour l'utilisation de thread je laisse tomber, autant faire tourner la fonction globale du pathfinder dans un thread si besoin.


ah ca ? je pense aussi que ce n'est pas la bonne approche pour le pathfind , un pool de thread n'est interressant que si les thread sont succeptible d'attendre des évènements bloquants (remarque avec un dual core peut etre)

Hors ligne


#11 

17-07-2007 13:30:47

izguit
Administrateur
Lieu: 127.0.0.1
Date d'inscription: 14-09-2006
Messages: 306
Site web

Jerry Kan :

[quote=izguit][quote=Jerry]de la logique floue ca pourrai etre super class, genre si on demande un résolution, le path find donne la derniere meilleure solution connue,


Pas encore regardé de ce côté là, je vois pas trop ce que tu veux dire par "la dernière meilleure solution connue"[/quote]
en gros l'idée c'est de lancer un pathfind dans un thread, et quand le temps critique est attein (le perso DOIT se déplacer) on demande au thread,
ca fait longtemps que j'ai plus touché le a*, mais il va trouver plusieurs solutions et les évaluer non ? imginons que quand on l'interroge, il en ai trouvé, mais qu'il n'ai pas TOUT trouvé,  ca pourrai etre sympa d'avoir une solution approximative, ( par exemple la premiere solution qui se rapproche de la moitié de la distance)  ou une premiere solution sans etre sure que cette solution est optimale
( a noter que ces deux algos sont bien sur tres basique, il y a moyen de faire des choses tres complexe avec le flou)[/quote]
A* fait pas ça, il trouve une des solutions possibles, ca privilégie le temps de calcul. Il faudrait un autre algo type dijkstra pour trouver la meilleure, mais on perd tout l'intérêt de la rapidité. Et puis j'en ai lancé des graphes avec A* et j'ai jamais remarqué une solution vraiment meilleure que celle qu'il me proposait. (c'est surement arrivé mais c'était pas évident) Donc au bout du temps critique tu fait avancer ton perso dans la direction du noeud d'arrivée en attendant que le pathfinder renvoie la chemin, je crois que c'est comme ça dans les AoE, C&C & Co

Pour les threads...  vu la structure de l'algo ça sert vraiment pas à grand chose smile


Athlon 64 3000+ // 1Go RAM // Geforce 6600GT 128Mo
Turion 64 X2 // 1Go RAM // ATI X1250

Hors ligne


Options Liens officiels Caractéristiques Statistiques Communauté
Corrections
irrlicht
irrklang
irredit
irrxml
xhtml 1.0
css 2.1
Propulsé par FluxBB
Traduit par FluxBB.fr
882 membres
1429 sujets
11119 messages
Dernier membre inscrit: LiseBuisson96
56 invités en ligne
Aucun membre connecté
RSS Feed