I am trying to create game on continuous board ( no grid cells) with some obstacles ( like boxes and ruined walls at random points, map is big). What algorithm can I use to solve this ( is something similar A* in grid boards) ? I kinda done a little research, can I use Voronoi diagram for this ?
In Skiena's The Algorithm Design Manual is an entry under computational geometry called "motion planning". It lists a few implementations for that, the Motion Planning Toolkit, SWIFT++ and CGAL. If you can, take a look at that book, I found it very pragmatic to read, and while it doesn't really offer many solutions, it always has a few pointers where to find them. Basically, an approach is to generate a suitable graph from the map and then to use Dijkstra's Algorithm (or maybe A*?) to find the shortest way. Generating the graph requires analyzing which points you can move between without crossing an obstagle.
Related
I'm currently trying to find a way to take irregularly shaped polygons and divide them into as few quadrilaterals as possible.
I can't find an obvious out of the box algorithm anywhere that does this, so I'm thinking of going down two possible routes.
1.Getting the optimal triangulation first, and then converting these to quadrilaterals
2.Trying to alter the CGAL optimal_convex_partitions function from their 2d polygon partitioning package to create quadrilateral partitions https://doc.cgal.org/latest/Partition_2/group__PkgPolygonPartitioning2.html#ga3ca9fb1f363f9f792bfbbeca65ad5cc5
I'm a total beginner to computational geometry, so I'd just like to know if either of these approaches seems like a fools errand before I try to learn C++? If anyone knows anything about the best possible approach to this that'd be even better. Thanks!
(Edit) Including a sample polygon - None of them should have holes, though they may have complex exteriors and concavity.
I assume that if you start with triangles and then try to merge two adjacent triangles into one quadrilateral in a greedy fashion you may end up with many isolated triangles.
Not sure how the convex partition may come handy.
You may find useful information in the articles below. As far as know, finite element analysis requires that the input object comprise of triangles or quads, so there has been some research done in this direction. Here are two papers that might be relevant:
Ted D. Blacker amd Michael B. Stephenson, “Paving: a new approach to automated quadrilateral mesh generation” Int. J. Num.Meth.Engg, Vol 32, 811-847 (1991)
Jinwoo Choi and Yohngjo Kim , Development of a New Algorithm for Automatic Generation of a Quadrilateral Mesh, International Journal of CAD/CAM Vol. 10, No. 2, pp. 00~00 (2011
I'm far from being an expert on this subjest, but I'm certain that these alg. can be implemented using CGAL...
I am calculating pathfinding inside a mesh which I have build a uniform grid around. The nodes (cells in the 3D grid) close to what I deem a "standable" surface I mark as accessible and they are used in my pathfinding. To get alot of detail (like being able to pathfind up small stair cases) the ammount of accessible cells in my grid have grown quite large, several thousand in larger buildings. (every grid cell is 0.5x0.5x0.5 m and the meshes are rooms with real world dimensions). Even though I only use a fraction of the actual cells in my grid for pathfinding the huge ammount slows the algorithm down. Other than that it works fine and finds the correct path through the mesh, using a weighted manhattan distance heuristic.
Imagine my grid looks like that and the mesh is inside it (can be more or less cubes but its always cubical), however the pathfinding will not be calculated on all the small cubes just a few marked as accessible (usually at the bottom of the grid but that can depend on how many floors the mesh has).
I am looking to reduce the search space for the pathfinding... I have looked at clustering like how HPA* does it and other clustering algorithms like Markov but they all seem to be best used with node graphs and not grids. One obvious solution would be to just increase the size of the small cubes building the grid but then I would lose alot of detail in the pathfinding and it would not be as robust. How could I cluster these small cubes? This is how a typical search space looks when I do my pathfinding (blue are accessible, green is path):
and as you see there is a lot of cubes to search through because the distance between them is quite small!
Never mind that the grid is an unoptimal solution for pathfinding for now.
Does anyone have an idea on how to reduce the ammount of cubes in the grid I have to search through and how would I access the neighbors after I reduce the space? :) Right now it only looks at the closest neighbors while expanding the search space.
A couple possibilities come to mind.
Higher-level Pathfinding
The first is that your A* search may be searching the entire problem space. For example, you live in Austin, Texas, and want to get into a particular building somewhere in Alberta, Canada. A simple A* algorithm would search a lot of Mexico and the USA before finally searching Canada for the building.
Consider creating a second layer of A* to solve this problem. You'd first find out which states to travel between to get to Canada, then which provinces to reach Alberta, then Calgary, and then the Calgary Zoo, for example. In a sense, you start with an overview, then fill it in with more detailed paths.
If you have enormous levels, such as skyrim's, you may need to add pathfinding layers between towns (multiple buildings), regions (multiple towns), and even countries (multiple regions). If you were making a GPS system, you might even need continents. If we'd become interstellar, our spaceships might contain pathfinding layers for planets, sectors, and even galaxies.
By using layers, you help to narrow down your search area significantly, especially if different areas don't use the same co-ordinate system! (It's fairly hard to estimate distance for one A* pathfinder if one of the regions needs latitude-longitude, another 3d-cartesian, and the next requires pathfinding through a time dimension.)
More efficient algorithms
Finding efficient algorithms becomes more important in 3 dimensions because there are more nodes to expand while searching. A Dijkstra search which expands x^2 nodes would search x^3, with x being the distance between the start and goal. A 4D game would require yet more efficiency in pathfinding.
One of the benefits of grid-based pathfinding is that you can exploit topographical properties like path symmetry. If two paths consist of the same movements in a different order, you don't need to find both of them. This is where a very efficient algorithm called Jump Point Search comes into play.
Here is a side-by-side comparison of A* (left) and JPS (right). Expanded/searched nodes are shown in red with walls in black:
Notice that they both find the same path, but JPS easily searched less than a tenth of what A* did.
As of now, I haven't seen an official 3-dimensional implementation, but I've helped another user generalize the algorithm to multiple dimensions.
Simplified Meshes (Graphs)
Another way to get rid of nodes during the search is to remove them before the search. For example, do you really need nodes in wide-open areas where you can trust a much more stupid AI to find its way? If you are building levels that don't change, create a script that parses them into the simplest grid which only contains important nodes.
This is actually called 'offline pathfinding'; basically finding ways to calculate paths before you need to find them. If your level will remain the same, running the script for a few minutes each time you update the level will easily cut 90% of the time you pathfind. After all, you've done most of the work before it became urgent. It's like trying to find your way around a new city compared to one you grew up in; knowing the landmarks means you don't really need a map.
Similar approaches to the 'symmetry-breaking' that Jump Point Search uses were introduced by Daniel Harabor, the creator of the algorithm. They are mentioned in one of his lectures, and allow you to preprocess the level to store only jump-points in your pathfinding mesh.
Clever Heuristics
Many academic papers state that A*'s cost function is f(x) = g(x) + h(x), which doesn't make it obvious that you may use other functions, multiply the weight of the cost functions, and even implement heatmaps of territory or recent deaths as functions. These may create sub-optimal paths, but they greatly improve the intelligence of your search. Who cares about the shortest path when your opponent has a choke point on it and has been easily dispatching anybody travelling through it? Better to be certain the AI can reach the goal safely than to let it be stupid.
For example, you may want to prevent the algorithm from letting enemies access secret areas so that they avoid revealing them to the player, and so that they AI seems to be unaware of them. All you need to achieve this is a uniform cost function for any point within those 'off-limits' regions. In a game like this, enemies would simply give up on hunting the player after the path grew too costly. Another cool option is to 'scent' regions the player has been recently (by temporarily increasing the cost of unvisited locations because many algorithms dislike negative costs).
If you know what places you won't need to search, but can't implement in your algorithm's logic, a simple increase to their cost will prevent unnecessary searching. There's a lot of ways to take advantage of heuristics to simplify and inform your pathfinding, but your biggest gains will come from Jump Point Search.
EDIT: Jump Point Search implicitly selects pathfinding direction using the same heuristics as A*, so you may be able to implement heuristics to a small degree, but their cost function won't be the cost of a node, but rather, the cost of traveling between the two nodes. (A* generally searches adjacent nodes, so the distinction between a node's cost and the cost of traveling to it tends to break down.)
Summary
Although octrees/quad-trees/b-trees can be useful in collision-detection, they aren't as applicable to searches because they section a graph based on its coordinates; not on its connections. Layering your graph (mesh in your vocabulary) into super graphs (regions) is a more effective solution.
Hopefully I've covered anything you'll find useful.
Good luck!
Here is the problem: There is a map which size is anywhere from 200*200 pixels to 1000*1000 pixels. Each pixel is a third of an inch in length/width.
The map has walls coming from it (which can be of any size), and can be pre-processed by any means. However, when the problem starts, a robot (of pixel size 18*18) is placed in an unknown location, along with several obstacles and one goal, all of which are in an unknown location.
If the robot bumps into any wall/object/goal it immediately dies. As such it has a simple laser scanner that perfectly sees an 80*80 pixel square ahead of it,centered on the robot.
I have already solved the problem of localizing the robot and determining its position (within a small error) on the grid. I am having a bit of trouble with making a good algorithm for going across the entire map until the goal is found.
I have the idea of making the robot go to the lower right, and somehow sweeping left to right, avoiding obstacles, and walls, until the goal is found, however I am unsure of a good way to do that.
Are there any decent algorithms for such a thing, or are there better ones for what I am trying to do?
You are looking for Pathfinding Algorithms
Some suggestions include "Flood Fill" algorithm or "Dijkstra’s algorithm" very similar to Lee's algorithm (I might even argue they are the same), but it's just another term to search for
This is probably the most popular simple path finding algorithm: "A*search" (a star Search) this link also showcases a few other path finding algorithms. (Another helpful link).
The key with a*star search is that you must know where you are (localization) and where the goal is. Dijkstra type algorithms are able to find the goal without prior knowledge of its location.
The one and only algorithm that comes to my mind is a simple Lee algorithm. Here's a pretty decent tutorial about what it does and how it works.
Using this algorithm you should be able to find all the obstacles and eventually find the goal, also you will find the shortest path to the goal.
The only big difference is that you have to move an 80x80 object instead of a 1x1 object, but I will let you deal with the way you will implement this.
I have a polygon 2d map of an environment and I want to simplify this map for some planning tests.
For example I want to close areas which can't be reached with the robot model, because the passage is to small.
The second problem is when i have two segments which a nearly parallel i want to set them parallel.
Can anyone tell me some algorithm names for that? That i know where i have to search?
thank you for your help.
Hunk
The first task is usually solved by applying Minkowski difference to your map and robot. This implies you know the profile of your robot.
For the second task common approach is to use 2D Snap Rounding. You can find a lot of papers on that topic at scholar.google.com. However it may also be helpful to take a look at Ramer–Douglas–Peucker algorithm for reducing a number of points in curve. It can not help with solving your problem, but it is useful to know about its existence.
Most likely your work is connected to Motion Planning, so I highly recommend you to read Computational Geometry by Kreweld, De Berg, Overmars and Schwarzkopf. It is classic of computational geometry. There you can find a lot about visibility graphs and motion planning.
Similarly to Mikhail's answer, for your first problem you can convert the map polygon into a binary image and apply a morphological dilation taking the size of the robot into account. Then, the areas separated by narrow paths will be disconnected components in the binary image.
Another approach is to divide the space into a grid and mark cells as empty or full depending on if some map line traverse them. Then thicken the boundaries according to the robot size and look for connected components from the cell where the robot is to find feasible paths.
You can use a delaunay triangulation of the map and travel the edges of the mesh for the shortest route.
I have spent time looking for information on the best algorithm to create a nesting of irregular polygons in 2D using manual and automatic positioning. I need to use such an algorithm in the context of CAD/CAM software. Here are the real possibilities I've found so far:
Separating Axis Theorem: is a fairly quick and simple algorithm to implement, but the drawback I find with it is that it only works with convex polygons. To work with concave polygons, a convex decomposition would need to be done first. This implies an increase in the run-time and the implementation of a new algorithm that decomposes the concave polygon into convex polygons.
Nesting by a power function: calculating the partial derivatives in the X and Y axes, you could get the escape direction you should take a polygon so that there is a collision between the two polygons. This function of energy and I tested and the three major problems that I have encountered are: first obtaining local minima , second nesting when the collision occurs over a piece and finally the execution time is very high.
Using no-fit polygon: use the no-fit polygon to the nesting can be somewhat interesting. I have read several papers on the subject although there are very few online documentation on it. Not sure if it can really be a useful choice. I still have several doubts on the details of this approach.
Any idea which of these algorithms to choose? Or if you know any other options that can be used? I'm a little confused :-) .
Thank you very much.