Discussion :

[I_Pnose]

Bonsoir à tous,

Je rencontre un p'tit souci avec le système de navmesh d’Unity et je ne sais pas trop comment passer outre.

En gros j’ai des unités qui se baladent sur un navmesh et je peux dynamiquement rajouter des obstacles sur leur chemin (je passe par un nav mesh obstacle avec la propriété carve à true).

La construction d’un obstacle se passe donc en deux étapes ; une première étape où l’obstacle en cours de construction suit le curseur de la souris et ne gène pas la progression des unités, et une deuxième étape (après un clic souris) où l’obstacle est effectivement placé sur la map (et son nav mesh obstacle component activé).

J’aimerais donc faire en sorte qu’avant de valider la construction de l’obstacle vérifier que ce dernier ne bloquera pas le chemin des unités en mouvement (le but est de faire faire des détours aux unités pas de les bloquer).

J’avais fait des essais avec NavMesh.CalculatePath(_spawn.position, _target.position, -1, _path); qui prend bien en compte mes obstacles dynamiques. Là où sa se corse c’est de faire un test en continu (ou quasiment en continu, pendant le placement à la souris de l’obstacle), j’ai donc naïvement écrit le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// J'active le nav mesh obstacle component de mon gameobject pour que mon obstacle 
// en cours de construction soit pris en compte dans le calcul du chemin.
_baseTowerObstacle.enabled = true;  
// Je lance le calcul du chemin pour déterminer si mon obstacle bloque
// le passage.
NavMesh.CalculatePath(_spawn.position, _target.position, -1, _path);
// Je désactive immédiatement le nav mesh obstacle component pour que mon obstacle 
// en cours de construction ne bloque pas les unités en mouvement.
_baseTowerObstacle.enabled = false; 
 
if (_path.status == NavMeshPathStatus.PathComplete)
{
    // Je ne bloque personne, je peux effectivement construire ma tour.
}
else
{
    // Je bloque le chemin, je ne peux donc pas construire ma tour.
 
    // Problème : Je ne passe jamais ici, même lorsque j'ai une tour au milieu du chemin =/
}

Si vous avez une astuce à me communiquer pour que j'arrive à mes fins, vous aurez droit à ma reconnaissance éternel... au moins =P

D'avance merci ^^

[Greg Latiner]

Je dois dire que je ne suis vraiment pas un spécialiste des Navmesh. En fait j'ai un peu de mal de cerner ton problème de fond (sorry).
Est-ce un soucis de fiabilité des pathstatus (à une époque, c'était pas tip top), ou le soucis se situe dans le fait de devoir faire des 'CalculatePath' permanent en fonction de la position de ton pointeur (et donc le la charge que cela représente potentiellement) ?

[I_Pnose]

La charge est maitrisée en appelant la coroutine deux à trois fois par seconde (je n’ai pas vraiment besoin d’un rafraîchissement temps réel).

Mon souci c’est que visiblement le fait d’activer l’obstacle temporairement, de calculer le chemin, et de re-désactiver l’obstacle derrière ça n’a pas l’air d’avoir le moindre impact sur le fameux calcul du chemin (si je lance le calcul avant et après l’activation de l’obstacle et que je regarde l’objet _path en détail je me rends compte que la topologie n’a pas bougé d’un poil, alors qu’elle devrait vu que j’ai activé un obstacle qui crée un trou temporaire dans le navmesh).

En fait, c’est comme si il fallait un petit temps d’adaptation pour que l’activation du NavMeshObstacle soit pris en compte et que le fameux trou soit fait (auquel cas mon "algo" n’a aucune chance de fonctionner en l’état).

[Greg Latiner]

Je dirais qu'a vue de nez, qu'il ne faudrait pas faire dans la même frame le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
_baseTowerObstacle.enabled = true;  
// Je lance le calcul du chemin pour déterminer si mon obstacle bloque
// le passage.
NavMesh.CalculatePath(_spawn.position, _target.position, -1, _path);
// Je désactive immédiatement le nav mesh obstacle component pour que mon obstacle 
// en cours de construction ne bloque pas les unités en mouvement.
_baseTowerObstacle.enabled = false;

A mon avis, pour qu'un nouveau calcul valide de CalculatePath soit fiable, il ne peut se faire que lors de la frame suivante. (je sais pas si je me fais bien comprendre)

[I_Pnose]

Si je fais ça (j’active l’obstacle, la frame d’après je fais le calcul et je désactive l’obstacle) pour une raison que j’ignore mes unités se retrouvent bloquées (comme si un obstacle existait alors que mon NavMeshObstacle est bien désactivé) et le status du chemin est à PathComplete 100% du temps (ce qui est paradoxale vu que mes unités sont bloquées >.<) ...

Si j’attends suffisamment longtemps (donc pas une frame sur l’autre, mais avec un léger délai entre activation et calcul/désactivation) le comportement est le même, mes unités s’arrêtent, mais par contre j’ai bien le statu qui se met à jour correctement.

Bref, c’est à s’arracher les cheveux (le peu qu’il me reste), et il va falloir que je trouve une alternative à ce que j’ai cherché à faire avec cette histoire d’activation/désactivation de l’obstacle car ça n’a vraiment pas l’air de lui plaire. Reste à savoir quoi =/

[Greg Latiner]

A quoi cette latence est-elle du, je ne serais le dire (encore moins fournir une solution pour passer outre).
Tu passes par path.status, mais si tu fais une interrogation plutôt à partir d'un agent (agent.pathStatus), que se passe-t-il ? ( quitte à activer un agent fictif juste pour la partie test).

[I_Pnose]

Je n'y avais pas pensé. Mais même punition malheureusement =/

[Greg Latiner]

Hmm, bizarre. Je confirme le soucis de status sur le path. Par contre, sur l'agent cela me semblait plus fiable.
Je viens de faire un rapide test (trrrèèèss sommaire hein), et le status de l'agent semble plutôt valide par rapport à celui du path
(sur le screen, états au moment où je fais apparaitre l'obstacle barrant le passage, l'agent passe bien en Partial )
Si ce n'est soluble en l'état (le pathfinding natif s’accommode très mal des environnement dynamique, c'est pas nouveau), il te faudra alors peut-être songer à une solution externe (il en existe pas mal sur le store)

[I_Pnose]

Oui j’ai posté un peu vite, j’ai fait une coquille en paramétrant mon agent. Donc en effet ça semble plus fiable !

Bon par contre j’ai toujours le souci du navmesh altéré malgré le fait que je désactive mon NavMeshObstacle aussitôt après (et du coup mes agents sont bloqués).

Il va peut-être sérieusement falloir que je zieute du côté des libs tierces, et/ou que je mette les mains dans le cambouis.

Merci beaucoup pour ton implication en tout cas ^^

[Greg Latiner]

Bon par contre j’ai toujours le souci du navmesh altéré malgré le fait que je désactive mon NavMeshObstacle aussitôt après (et du coup mes agents sont bloqués).

de ce que j'ai pu voir, c'est qu'il fallait attendre au moins une frame pour qu'ils réagissent à la nouvelle solution à partir d'un nouveau CalculatePath (un peu comme évoque plus haut). Maintenant, je n'ai pas approfondi je dois bien l'avouer, ma petite scène de test étant bien dépouillée .

Il va peut-être sérieusement falloir que je zieute du côté des libs tierces, et/ou que je mette les mains dans le cambouis.

la solution native est toujours à privilégier, maintenant quand ça veut pas... (A* Pathfinding Project d'Aron Granberg est l'une de plus connu et des plus plébiscitée, et existe en version free)

Si tu arrives à trouver la solution à partir des composants natifs, alors cela sera toujours interessant à connaitre

[I_Pnose]

Bon j’ai eu beau retourner le problème dans tous les sens, je n’ai pas réussi à m’en sortir avec le système de navmesh natif. Et comme il faut que j’avance j’ai bricolé (c’est le terme) un truc qui a le mérite de fonctionner.

En gros je garde le système de navigation d’Unity pour tout ce que je faisais jusqu’à maintenant, et j’ai rajouté un autre système de pathfinding plus simpliste et complètement dédiée au placement/validation temps réel d’un obstacle. En gros quand je ne suis pas en train de placer un obstacle ce système d’appoint est tout simplement désactivé.

C’est un peu overkill mais ça fonctionne, et je ne me sens pas de migrer complètement sur une autre solution de pathfinding avec toute la logique que j’ai écrite sur la base des navmeshs d’Unity.

[Greg Latiner]

l'essentiel est d'avancer, même si c'est par des chemins de travers. Si c'est maitrisé et parfaitement fonctionnel, alors pourquoi pas.
Qui sait, l'amélioration prévu du système natif te permettra peut-être de revenir dessus d'ici quelques temps