
JPS+ pathfinding – faster than A* [video] - babuskov
http://www.gdcvault.com/play/1022094/JPS-Over-100x-Faster-than
======
idunning
Allowing precomputation seems a little suspect, or at least difficult to
incorporate into a comparison. I could offline precompute all pairs shortest
path, then I'll be 10^6 faster than Astar, for example. Where do you draw the
line? In the Q&A someone asks this, and points out that the precomputation in
the video has a lot/all of the shortest paths stored. The speaker says that
requires too much memory to store - so basically, arbitrary line here (what is
too much?)

Another problem is with heuristics in general: if you are not guaranteed to
find an optimal path (which is possible with Astar variants), then you have a
two-dimensional way to understand heuristics: run time, and solution quality.
e.g. I can give you a bad path very fast.

Finally, implementation data structures and language. Two people implementing
the same algorithm in different languages are going to have different
performance.

Here is a preprint that addresses these questions for heuristics for two NP-
hard problems (MAXCUT and QUBO): [http://www.optimization-
online.org/DB_FILE/2015/05/4895.pdf](http://www.optimization-
online.org/DB_FILE/2015/05/4895.pdf)

~~~
bjterry
This isn't a heuristic search, it's guaranteed to find an optimal path the
same as A*. More generally, this isn't a talk for theoreticians, this is
another tool in the toolbox for game AI engineers, and personally I find it
very clever. Whether you can afford the memory cost for the precomputed data
is a question that must be answered in the specific context of your
application.

~~~
idunning
Agree that everything must be contextualized. My point is, you saw this
presentation and liked it because it seems like a good idea, and the
performance is apparently good _relative_ to something else. For an engineer
(or a theoretician) to reason about that claim of improved performance there
needs to be a systematic way to understand it. All I'm saying is that way this
was done doesn't allow us to understand it very well - precomputation being a
big part of that.

------
lorenzhs
On road networks (Google Maps style routing) much much bigger gains have been
achieved. Taking things to an extreme, Hub Labelling achieves sub-microsecond
query times on continental-scale road networks [1]. More flexible algorithms
(e.g. Multi-Layer Dijkstra aka Customizable Route Planning, which Bing Maps
supposedly uses) achieve sub-millisecond query times, with preprocessing times
for new metrics less than a few minutes. This allows full timely integration
of traffic information etc.

On a 2D grid, there are a few differences, but even modeling it as a graph and
applying road network algorithms (even simple ones like Landmark Routing)
sounds like it would yield similar, if not better speedups.

[1]
[http://research.microsoft.com/apps/pubs/default.aspx?id=1456...](http://research.microsoft.com/apps/pubs/default.aspx?id=145689)

~~~
lnanek2
It would be nice if Google Maps started doing a decent job, though. I lived
for years in NJ and I would typically require 3 roads and 20 minutes to get
anywhere I needed to go shopping because I would drive to the highway, hop on,
get off on the road to my destination, then be there. Even if I avoided the
highway I would get there in 30 minutes with smaller roads, taking the minimum
needed to go the right direction toward the destination.

Google Maps? It was a disaster. It would take the small roads since it
couldn't bear to drive 2 blocks the wrong direction to get on the highway,
then every small road it would alternate taking a left and a right and end up
with dozens of turns when a human only needed 3 or 4. I actually met the ex-
Googler who bragged about writing that algorithm that alternates left and
right, I think he must be responsible for millions of hours of lost time for
drivers just because he didn't realize turning has a cost and was trying to
draw a diagonal as best he could.

Does it really make sense to brag about fast calculation speed when the
calculation is a disaster? I'd rather wait a minute for a calculation and get
the right one, than have the wrong one back in 3 seconds. I think the Google
Maps engineers don't understand this.

~~~
lorenzhs
Actually, the algorithms used are provably optimal _in regard to whatever
metric is plugged into them_. This means that no matter which of these
algorithms you use (including Dijkstra or A*), you will get the exact same
result. The difference is in the time and space required for precomputation vs
at query time. That includes Contraction Hierarchies, which Google Maps uses
(or used?). But if they screw up the optimization metric, then the algorithm
can't save them either.

------
justinhj
It's a bit misleading to call this faster than A* since it is still using A*
under the hood. Most optimizations to path finding with A* involve changing
the world representation somehow. Most do not use a simple grid, with
navigation meshes being more common.

Very clever though, I like it.

~~~
andor
It's also misleading because nothing optimal is faster than A* . Quote from
AIMA:

" _A∗ is optimally efficient for any given consistent heuristic. That is, no
other optimal algorithm is guaranteed to expand fewer nodes than A∗ (except
possibly through tie-breaking among nodes with f(n) = C∗). This is because any
algorithm that does not expand all nodes with f(n) < C∗ runs the risk of
missing the optimal solution."_

~~~
_delirium
In the general setting A-star is optimal. JPS (and JPS+) can speed it up if
you have additional information about the topology of the search space: 1)
search is on a rectangular grid, and 2) movement between adjacent grid squares
has uniform cost. In that case, you can take advantage of certain
properties/symmetries of a rectangular grid to safely "skip" parts of the
expansion that A-star would normally do, while still being guaranteed to find
the optimal solution.

The JPS paper from a few years ago explains in more detail:
[http://users.cecs.anu.edu.au/~dharabor/data/papers/harabor-g...](http://users.cecs.anu.edu.au/~dharabor/data/papers/harabor-
grastien-aaai11.pdf)

------
jessaustin
[https://github.com/SteveRabin/JPSPlusWithGoalBounding](https://github.com/SteveRabin/JPSPlusWithGoalBounding)

------
ingenter
[http://mikolalysenko.github.io/l1-path-
finder/www/](http://mikolalysenko.github.io/l1-path-finder/www/)

------
kbwt
But how does it compare to A* on a reduced[1] visibility graph?

[1]
[http://kovan.ceng.metu.edu.tr/~kadir/academia/courses/grad/c...](http://kovan.ceng.metu.edu.tr/~kadir/academia/courses/grad/cs548/hmws/hw3/vg/node3.html)

~~~
obstinate
That page claims it's about 40% faster than A*. Multiply through the ratios
and you'll have your answer. (1000x faster is a lot more than .4x faster, so I
guess it compares quite favorably.)

~~~
kbwt
That's for A* on a complete visibility graph, which is much faster than on a
uniform grid. I only added the link so that the reduced terminology is clear
to everyone.

------
opcvx
Precomputation takes O(n^2) complexity so this is great for static
environments like Starcraft maps where the units don't evaluate units in their
path finding.

~~~
imaginenore
Starcraft maps aren't static, as buildings and characters can block paths.

~~~
opcvx
Maps themselves are static.

------
andrepd
As a side note, I love the index on the left hand side of the player, that
lets me quickly jump to any section of talk, instead of having to fish for the
part when he starts talking about the algorithm, for instance. An awesome
feature I wish other websites had too.

~~~
h1fra
Same note, at first I was like "another video I won't watch watch because I'm
only curious about one point of the talking" then I saw the menu. Very cool
feature, greatly optimize user experience in a simple way

------
mathgenius
I love the connections to the continuum case where these problems show up
looking like ways of solving path integrals, Huygens principle, etc. In
particular, some of these jump point rules look alot like diffraction (of a
wave) around a boundary.

~~~
mathgenius
Ah, and it seems to be connected to ray marching also, as demonstrated so well
by the fractal lab guy: [http://sub.blue/fractal-lab](http://sub.blue/fractal-
lab)

~~~
willvarfar
How is it connected to ray marching?

I'm curious; my own playing with the area:
[http://williamedwardscoder.tumblr.com/post/26628848007/rod-m...](http://williamedwardscoder.tumblr.com/post/26628848007/rod-
marching)
[http://williamedwardscoder.tumblr.com/post/28935319219/rod-m...](http://williamedwardscoder.tumblr.com/post/28935319219/rod-
marching-on-the-gpu)

Would like to make it faster :)

~~~
mathgenius
I just think it is interesting to consider all these path finding algorithms,
and compare/contrast them. So with ray marching, we already have access to a
"distance" function. And it's not one but many targets we are looking for. It
does seem to me like JPS tries to do something similar, the cacheing of jump
points looks alot like the distance function, and now we are going to cast
rays out looking for the target point, and let rays "bend" around corners,
etc.

------
bsdetector
On a side note, you can increase performance of presentations by 25% by not
leaving time for questions. I find Q&A is often the best part and I wish the
conferences left more time for it.

~~~
wesleyy
Did you mean by leaving time rather than "by not leaving time"?

------
beefsack
I believe JPS only works for unweighted graphs, so you can only compare it to
A* for that particular case.

~~~
_delirium
More specifically, JPS works on unweighted _grids_ (not arbitrary graphs).
That allows it to use properties of a grid topology to figure out where it can
safely "jump" without sacrificing optimality.

------
striking
> uniform cost grids

There are very many grids that do not fit this in real (not theoretical)
applications. I honestly can't think of when I'd use this algorithm.

~~~
mathgenius
Well, yeah, but the whole question of extending this algorithm to arbitrary
(weighted) graphs is still very interesting: it seems to rely on some kind of
discrete [1] version of parallel transport.

[1] [http://ddg.cs.columbia.edu/](http://ddg.cs.columbia.edu/)

------
jokoon
seems like optimizing something always involves precalculations.

