Fast path finding algorithm
-
Hello, I have a big maze (800x800) and I need to search for a shortest path on it, from one point to another. I tried wave algorithm but it is very-very slow. I have to wait for several minutes. Are there path finding algorithms that can accompish such a task relatively quickly?
Depending on the type of maze, you can just stick to the right wall the entire way and you will eventually get out of the maze, though it won't be the shortest path. Wouldn't work if the destination is in an island (e.g., where the ghosts go to in Pac-Man). Though, a properly implemented flood fill (maybe this is the same as your "wave algorithm") should find the exit fairly fast. It certainly shouldn't take minutes (should work in a few milliseconds on a modern computer). Can you post your implementation of the algorithm that is too slow?
-
Hello, I have a big maze (800x800) and I need to search for a shortest path on it, from one point to another. I tried wave algorithm but it is very-very slow. I have to wait for several minutes. Are there path finding algorithms that can accompish such a task relatively quickly?
finding a path is easy and can be handled quickly, finding the or a shortest path is quite difficult, as you have to consider a lot of possibilities, assuming a non-trivial maze. You have to choose your algorithm carefully, and then implement it even more carefully. And what is the information you have: the full map? or are you supposed to discover the maze while travelling? :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Please use <PRE> tags for code snippets, they improve readability.
CP Vanity has been updated to V2.3 -
finding a path is easy and can be handled quickly, finding the or a shortest path is quite difficult, as you have to consider a lot of possibilities, assuming a non-trivial maze. You have to choose your algorithm carefully, and then implement it even more carefully. And what is the information you have: the full map? or are you supposed to discover the maze while travelling? :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Please use <PRE> tags for code snippets, they improve readability.
CP Vanity has been updated to V2.3 -
Hello, I have a big maze (800x800) and I need to search for a shortest path on it, from one point to another. I tried wave algorithm but it is very-very slow. I have to wait for several minutes. Are there path finding algorithms that can accompish such a task relatively quickly?
Is this how your "wave algorithm" works?
-
I have lines on the image control that are like "walls" and I need to bypass them. Also I have two points, that I need to connect.
If the map is known beforehand, I think there are basically three ways: 1. start travelling in one direction, and implement backtracking (e.g. the righthand-on-wall approach). This is simple but may be slow. 2. perform what looks like a flood fill, i.e. start in all directions and visit everything for sure (look at A* algorithm). 3. turn the map into a graph and analyze the graph (sorry, no reference handy). I'm not sure what is best when the goal is "find a shortest path with minimal effort". I'm not sure any of the above is always the best pick anyway. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Please use <PRE> tags for code snippets, they improve readability.
CP Vanity has been updated to V2.3modified on Friday, June 10, 2011 8:50 PM
-
Is this how your "wave algorithm" works?
Probably the best way is to convert the maze to a connectivity graph this will get the datasize down. Intersections are nodes and corridor lengths give the weighting. For this you need some kind of linked list structure. Each node having a pointer to all connected nodes with a weighting for each link. With that you can use either brute force with a recursive algorithm to take every path (but beware of loops) if it is small or apply something like Dijkstra's algorithm (see wikipedia) to it.
DC Always remember that you are unique- just like everybody else.
-
Hello, I have a big maze (800x800) and I need to search for a shortest path on it, from one point to another. I tried wave algorithm but it is very-very slow. I have to wait for several minutes. Are there path finding algorithms that can accompish such a task relatively quickly?
The default answer to a question like this is A*. However, David is right in that you probably don't genuinely have an 800x800 problem space and you should condense your image to a connectivity graph first and use Dijkstra, or at least reduce the resolution of the computational grid (for example if the maze is of 8x8px squares you can reduce the path space to 100x100).
-
Hello, I have a big maze (800x800) and I need to search for a shortest path on it, from one point to another. I tried wave algorithm but it is very-very slow. I have to wait for several minutes. Are there path finding algorithms that can accompish such a task relatively quickly?
I tried wave algorithm but it is very-very slow. I have to wait for several minutes. Given the speed of today's computers and a relatively small problem space, that could mean only one thing: your implementation is not memoizing[^]. With only 640K points to visit, a program that remembers intermediate solutions as it discovers them should finish in under a few milliseconds. This is because a properly coded (i.e. with memoization) wave algorithm visits each point exactly once. P.S. It would be a lot easier to pinpoint the problem if you post your code.
-
Hello, I have a big maze (800x800) and I need to search for a shortest path on it, from one point to another. I tried wave algorithm but it is very-very slow. I have to wait for several minutes. Are there path finding algorithms that can accompish such a task relatively quickly?
Store your maze as a 2D image (I bet it already is). Paint the walls in black, the starting pixel in red, the ending pixel in green and all others in white. Keep an "active list" with the (coordinates of) pixels that can be reached from the starting point in at most N steps. ---- Initialize the active list with the ending pixel (N=0). ---- For increasing N, scan the active list: -------- For every pixel in the list: ------------ Consider its white neighbors, if any ------------ Paint them in navy, ecru, wheat or salmon, depending on the neighbor-to-pixel direction ------------ Replace the pixel by its neighbors in the list ---- Stop as soon as you meet the red pixel. The pixel colors will allow you to trace the path. Properly implemented with arrays using a compiled language, this will run in about 100 ms or less for a 800x800 image.
-
Is this how your "wave algorithm" works?
Sorry for the late response, I was going back over some of old entries in the forum that I had not reviewed yet. I have a question (or observation as the case may be) about the "wave algorithm" as it applies to a maze. If you start at either point and flood fill, you may go down many unproductive paths (in paralel - the wave front expands equally from all points). It takes time to fill all the dead ends. Eventually the other point will be found. What about starting the flood fill at both points? You may fill some dead ends from both points, but when you finally collide with the other wave front, it is "Game over!", stop filling the dead ends. OBTW, the flooding must be with different colors from each point to be able to correctly identify looping paths from either end - you need to find the opposite wave color to claim a complete path. To identify the actual path from the first point to the second point, save (in a solution array that has the same size as the array) the x-y coordinates (or point ID of some kind) of the originating point that was being processed when this new point was flooded, into the array position for the new point. Do this for points starting from the first point (the first color). For the points starting from the second point (the second color), save the new point ID in the current point array position so the path is consistent. To walk the path, start at the second point in the solution array and backtrack to the first point. If you are processing blocks of points in a maze (i.e., 8x8), then you only need a solution array big enough for the number of blocks, not big enough for the number of pixels. Dave.
-
Sorry for the late response, I was going back over some of old entries in the forum that I had not reviewed yet. I have a question (or observation as the case may be) about the "wave algorithm" as it applies to a maze. If you start at either point and flood fill, you may go down many unproductive paths (in paralel - the wave front expands equally from all points). It takes time to fill all the dead ends. Eventually the other point will be found. What about starting the flood fill at both points? You may fill some dead ends from both points, but when you finally collide with the other wave front, it is "Game over!", stop filling the dead ends. OBTW, the flooding must be with different colors from each point to be able to correctly identify looping paths from either end - you need to find the opposite wave color to claim a complete path. To identify the actual path from the first point to the second point, save (in a solution array that has the same size as the array) the x-y coordinates (or point ID of some kind) of the originating point that was being processed when this new point was flooded, into the array position for the new point. Do this for points starting from the first point (the first color). For the points starting from the second point (the second color), save the new point ID in the current point array position so the path is consistent. To walk the path, start at the second point in the solution array and backtrack to the first point. If you are processing blocks of points in a maze (i.e., 8x8), then you only need a solution array big enough for the number of blocks, not big enough for the number of pixels. Dave.
Sorry for the double post. What was I thinking! This will not work:
To identify the actual path from the first point to the second point, save (in a solution array that has the same size as the array) the x-y coordinates (or point ID of some kind) of the originating point that was being processed when this new point was flooded, into the array position for the new point. Do this for points starting from the first point (the first color). For the points starting from the second point (the second color), save the new point ID in the current point array position so the path is consistent. To walk the path, start at the second point in the solution array and backtrack to the first point. If you are processing blocks of points in a maze (i.e., 8x8), then you only need a solution array big enough for the number of blocks, not big enough for the number of pixels.
What it should read is: To identify the actual path from the first point to the second point, save (in a solution array that has the same size as the array) the x-y coordinates (or point ID of some kind) of the current point that was being processed when this new point was flooded, into the array position for the new point. Do this for all flooded points starting from either direction. When the collision occurs between the two wave fronts, you have two adjacent positions marked with different flood fill colors. For each of these positions, backtrack to the originating point and mark the positions with a shortest path color, then scan the entire array and mark all positions that are in either flood fill color with the normal color of the hallway. You will be left with the walls, the halls, the start and end points, and the shortest path between the points. If you are processing blocks of points in a maze (i.e., 8x8 blocks in a 800x800 maze), then you only need a solution array big enough for the number of blocks, not big enough for the number of pixels. Dave.
