Hello,
is possible to have one unit that shares for example two or three different graphs on scene (Same type of graph or even other types ?) ?
Can it make decision which one choose based on the graph priority ?
Thanks
M.
Hi
Could you elaborate a bit?
I strongly recommend using only a single graph for a unit since connecting graphs usually leads to tricky problems on the border between the graphs.
I need to navigate with two types of graph … Point and Recast graph … The idea is to navigate unit to the nearest point of point graph by Recast, navigate by Point graph to the nearest point to the destination point and switch back to the recast and navigate from this point to the destination point. What do you think about it ?
The Point graph has greater priority for us (roads) than Recast (land).
Hi
That is theoretically possible.
Basically you would have to add a large penalty on the recast graphs so that units avoid walking on it (note, this might affect performance), then you would need to using code, connect each point node to the closest recast node (using AstarPath.active.GetNearest using a graphMask in the NNConstraint parameter and using the node.AddConnection method)… However I am not how good results it would give you.
Hierarchical pathfinding (which this is an example of) is not very well supported in the system at the moment.
Hi.
This is exactly my situation as well. I have a large-ish terrain and I would like the units sometimes to go through it and sometimes to navigate the roads.
Is it possible to have two graphs completely independent from each other and specify which one to use when requesting a path?
If not, which solution would you recommend atm?
Would have only 1 graph and programmatically assign a lower penalty to the road’s nodes make sense?
You can. There is a graphMask field which can be set when calling StartPath on the seeker (it is an optional parameter). The graphMask is a bitmask so the first bit indicates that the first graph can be searched, the second bit indicates that the second bit can be searched, etc.
Very much appreciate your answer Aron.