5

I'm a real speed freak if it gets to algorithms, and in the plugins I made for a game.

The speed is.. a bit.. not satisfying. Especially while driving around with a car and you do not follow your path, the path has to be recalculated.. and it takes some time, So the in-game GPS is stacking up many "wrong way" signals (and stacking up the signals means more calculations afterward, for each wrong way move) because I want a fast, live-gps system which updates constantly.

I changed the old algorithm (some simple dijkstra implementation) to boost::dijkstra's to calculate a path from node A to node B

(total node list is around ~15k nodes with ~40k connections, for curious people here is the map: http://gz.pxf24.pl/downloads/prv2.jpg (12 MB), edges in the red lines are the nodes),

but it didn't really increase in speed. (At least not noticeably, maybe 50 ms).

The information that is stored in the Node array is:

The ID of the Node,
The position of the node,
All the connections to the node (and which way it is connected to the other nodes, TO, FROM, or BOTH)
Distance to the connected nodes.

I'm curious if anybody knows some faster alternatives in C/C++? Any suggestions (+ code examples?) are appreciated!

If anyone is interested in the project, here it is (source+binaries):

https://gpb.googlecode.com/files/RouteConnector_177.zip

In this video you can see what the gps-system is like:

http://www.youtu.be/xsIhArstyU8

as you can see the red route is updating slowly (well, for us - gamers - it is slow).

( ByTheWay: the gaps between the red lines have been fixed a long time ago :p )

Kijewski
  • 25,517
  • 12
  • 101
  • 143
  • 4
    Have you tried A*? It's by the most common (certainly the simplest) heuristic-based path-finding algorithm. And in a GPS-like situation the "distance as the crow flies" heuristic usually works quite well. – biziclop Jun 30 '12 at 21:59
  • @biziclop does boost have an A* implementation? I cannot find anything | google = a* boost or a* algorythm boost –  Jun 30 '12 at 22:03
  • 1
    The second optimization possibility comes from the fact that in a GPS-recalculate situation your destination is always the same and your source isn't far from the previous iteration, so if you store the shortest route from the previous calculation, you only need to search until you reach a node that is already on that list. – biziclop Jun 30 '12 at 22:05
  • I don't know what boost is unfortunately. I thought speed freaks wrote their own algorithms :) – biziclop Jun 30 '12 at 22:06
  • @up ofcourse I will also update my GPS but the main bottleneck is the plugin :) And I am a speed freak but not so advanced with C/C++. if you look at my code you know what I mean.. –  Jun 30 '12 at 22:06
  • Dijkstra's algorithm is the fastest general case algorithm for shortest paths, but because you are working with a planar graph, you should be able to prune the set of nodes and edges you use as input. For instance, if I am calculating routes within NYC, I don't want to consider all of the roads within the entire US. – user1149913 Jun 30 '12 at 22:08
  • Have you considered computing, in the background, the minimum path for each node adjacent to the node the player is in right now? It seems to take a bit of time for a player to get from one node to another, and with few adjacent nodes (which there seem to be), this wouldn't take so long, and it would allow you to instantly update the red line. Recomputing the path doesn't seem to slow your game, so this sounds feasible. – IVlad Jun 30 '12 at 22:10
  • I made the title clearer - can we not close this please? It is completely unrelated to the suggested duplicate. – IVlad Jun 30 '12 at 22:12
  • Yes the plugin is threaded, about "pruning" the graph - how would I accomplish that? If I need to create 1 main graph and 500 (max player amount) prune graphs (each for one player) then I think that will also consume much computation (not mentioning calculating the distances between the players and the nodes). @IVlad Also calculating from the adjacent nodes would be much, in a players area (range = 10 units, very litte) there can sometimes be 50-60 nodes, sometimes 0. –  Jun 30 '12 at 22:13
  • @IVlad - Accepted the change :) Thanks –  Jun 30 '12 at 22:14
  • Also, how much do you care about having the absolute shortest route? Would close enough also be good? – IVlad Jun 30 '12 at 22:17
  • close enough would be just the same as perfect, also I forgot to add - not everyone is looking at the source - so.. I also need to be able to retrieve the list of all nodes in the path :] –  Jun 30 '12 at 22:18
  • 2
    By the way, here's the description of A*, it really is pretty simple: http://en.wikipedia.org/wiki/A* I'm sure there are hundreds of ready-made implementations in any language. – biziclop Jun 30 '12 at 22:20
  • I've looked at the video and it made me think: seeing as the travelling object is a car, shouldn't corners and turning around add cost to a route? – biziclop Jun 30 '12 at 22:25
  • @biziclop If you look at the map they're all covered :) corners are also nodes, just nodes connected to more than 2 nodes. and straight ways have nodes which are connected only to two other nodes. –  Jun 30 '12 at 22:27
  • also, if there are a* implementations, there would be C and/or C++ implementations, fast and slower implementations, implementations that fit my project without rewritign too much, and implementations that would require me to rewrite my whole plugin.. I prefer to have the fastest implementation, so it doesn't matter if in C or C++, it needs to compile, and i don't care if I need to rewrite my plugin. So which do you guys recomend? –  Jun 30 '12 at 22:37

2 Answers2

5

Since this is a GPS, it must have a fixed destination. Instead of computing the path from your current node to the destination each time you change the current node, you can instead find the shortest paths from your destination to all the nodes: just run Dijkstra once starting from the destination. This will take about as long as an update takes right now.

Then, in each node, keep prev = the node previous to this on the shortest path to this node (from your destination). You update this as you compute the shortest paths. Or you can use a prev[] array outside of the nodes - basically whatever method you are using to reconstruct the path now should still work.

When moving your car, your path is given by currentNode.prev -> currentNode.prev.prev -> ....

This will solve the update lag and keep your path optimal, but you'll still have a slight lag when entering your destination.

You should consider this approach even if you plan on using A* or other heuristics that do not always give the optimal answer, at least if you still get lag with those approaches.

For example, if you have this graph:

1 - 2 cost 3
1 - 3 cost 4
2 - 4 cost 1
3 - 4 cost 2
3 - 5 cost 5

The prev array would look like this (computed when you compute the distances d[]):

       1 2 3 4 5
prev = 1 1 1 2 3

Meaning:

shortest path FROM TO 
                 1  2 = prev[2], 2 = 1, 3
                 1  3 = prev[3], 3 = 1, 3
                 1  4 = prev[ prev[4] ], prev[4], 4 = 1, 2, 4 (fill in right to left)
                 1  5 = prev[ prev[5] ], prev[5], 5 = 1, 3, 5 
                 etc.
IVlad
  • 43,099
  • 13
  • 111
  • 179
  • Did I undestand it correctly?; I have to calculate from the destination, to all nodes, a path, save the paths, then use them? Woudln't require this huge amounts of memory... offtopic: I once tried to initialize a vector which required 64 GB of RAM, I failed XD –  Jun 30 '12 at 22:44
  • @anyonewhoclosedthistopic, I have a scenario here, that question does not! this is no duplicate : ( (at least not an exact duplicate), please unclose.. –  Jun 30 '12 at 22:55
  • @GamErix - No: you just need a `prev` array of size `number of nodes`. Run dijkstra once from the destination, and populate that prev array such that `prev[i] = node previous to i on the shortest path from the start node to node i`. You do not save the actual paths, as they will contain a lot of the same nodes. This information lets you construct any path when you need it. – IVlad Jun 30 '12 at 22:56
  • you mean, that if the returned path is the following NODE ID's: 0,5,34,753,85,1,24 , then I should create a variable like int array[7] = {0,5,34,754,85,1,24}; ? I think I did that in one of my scripts but I think I didn't use it correctly : P –  Jun 30 '12 at 23:08
  • 1
    No. Imagine you've found the shortest path from point A to point Z. Let's say that the path is A,B,C...,Z (we were lucky :)). So what's the shortest path from B to Z? It has to be B,C,D...,Z. What's the shortest from Q to Z? Q,R,S,T...,Z And so on. So if you've got an array with one element for every node in the graph, and that element tells you what is the next node on the path to Z, you can hop across them one by one. In your case this will mean an array with 15k elements, so a very small structure. – biziclop Jun 30 '12 at 23:14
  • @GamErix - I added an example, hope that helps clear it up. Write if you want more details - although I will only answer in the morning (for me) - about 8-9 hours from now. – IVlad Jun 30 '12 at 23:16
  • @IVlad It's a bit messy in my head, can you replace the 'node names' by characters instead of numbers, please? :) I will go to sleep probly too now, it's 1.30 am. SO I can't think clear xD –  Jun 30 '12 at 23:24
  • @GamErix What you need to recognize if the shortest path from Destination to Node X visits Node Y, then the shortest path from Destination to Node Y is a subset of the path from Node X. So for any node you just need to store the "Next point" in the shortest path to the Dest, and then continue. So for a fixed destination you need to store just the next node. So space complexity is number of nodes. – VSOverFlow Jul 01 '12 at 00:18
2

To make the start instant, you can cheat in the following way.

Have a fairly small set of "major thoroughfare nodes". For each node define its "neighborhood" (all nodes within a certain distance). Store the shortest routes from every major thoroughfare node to every other one. Store the shortest routes to/from each node to its major thoroughfares.

If the two nodes are in the same neighborhood you can calculate the best answer on the fly. Else consider only routes of the form, "here to major thoroughfare node near me to major thoroughfare near it to it". Since you've already precalculated those, and have a limited number of combinations, you should very quickly be able to calculate a route on the fly.

Then the challenge becomes picking a set of major thoroughfare nodes. It should be a fairly small set of nodes that most good routes should go through - so pick a node every so often along major streets. A list of a couple of hundred should be more than good enough for your map.

btilly
  • 43,296
  • 3
  • 59
  • 88
  • each 'thoroughfare' (street?) can have many nodes, even straight lines are made of multiple nodes :) So how to tackle this? –  Jul 01 '12 at 11:42
  • @GamErix Just pick a node every so often on your streets. You don't want every promising node. You're fine as long as you have enough that any best route that goes a long distance will almost certainly go through several of them. – btilly Jul 01 '12 at 14:33
  • thank you all for your input, this one is solved, now I'm going to post another question about arthimetrics. Something is not working right xD –  Jul 01 '12 at 16:47