I've shared my tutorial "Using Grids For Collisions" on Google+ and there I've got a comment.

Quote

I use a different, very fast algorithm: First, sort all objects by their x-coordinate. Then calculate abs(x(n)-x(n-1)) to filter out those objects, which are nearby each other on x (can be done during sort), and only those you have to insert into a list, sort again by their y-coordinate. And if those left are also nearby on y, you have sorted out then all candidates for a more intense collision detection. The advantage is, if you use a sort algorithm, which likes pre-sorted data, its incredibly fast. Works for several hundred thousands of object coordinates (means polygons) in near real-time. No need to differentiate between unmovable and moving objects! And - because of the simplicity of the algorithm, it is typically translated into very fast machine code, avoiding cache - misses. And if you need to detect z-axis collisions, just add one more sorter. Works perfectly in fully dynamic worlds, where all objects move. Have fun!﻿

I wanna try it but I don't understand it. Can anybody help me understanding it so that I can implement?

(1) Sort all objects by their x-coordinate(2) Take only all objects that have other objects with "nearby" x-coordinates(3) Sort that list from #2 by their y-coordinate(4) Take only all objects that have other objects with "nearby" y-coordinates

Thus, you have a list of objects that have potentially collided, and you work only with that filtered list of objects.

Sounds like a Sweep and prune. You check all AABBs for overlaps on first the x axis and then the y axis. Basically you check all points one dimension at a time. Then, if two objects overlap on both axes, there´s an intersection. Then you can keep an almost sorted list since an objects position change very little frame... It´s the basic idea, but google "Sweep and prune" and you will find a lot of better explanations.

ps1. I actually came up with something like this idea a couple of months ago when thinking about how to solve collisions. "How come no one has come up with this idea before?", I tought. Of course someone already did: David Baraff in 1992! I guess I wasn´t that groundbreaking after all...

Sweep-and-prune can be in any direction and number of dimensions, so a 2D systems can use 1 or 2. As I said in that other thread, nobody can tell you what's fast without knowing (probably more information you can provide) information about your data set. It'll be pretty common that a uniform grid will out-perform sweep-and-prune alone however and if your cells can contain a largest number of entities then sweep-and-prune inside the grid cells can be a win (there's a closely related technique called SAP-trees). SAP can reduce the n(n-1)/2 by limiting how far forward your looking. A uniform grid can be viewed as SAP where your sorting along the axises and only sorting in discrete chunks.

EDIT: No AABB requirement...but if your using the coordinate frame as sort directions then you effectively using an AABB. Also note that for an arbitrary direction D, then choosing -D will be faster or slower.

This thread is about collision detection. To find all collisions you'd have to call your method for every pair of objects in your game.e.g. if you have 1000 objects you need to call that method 1,000.000 times. With 10l,000 objects 100,000,000 times. And that 60 times per second. So for a large number of objects it's simply too slow. The sorting technique is orders of magnitude faster.

Well, the next step up from the naive n2 is n(n-1)/2 (still n2 in Big-O, but we don't care). Collision detection is inherently an n2 problem. The worst case of SAP is still n(n-1)/2 checks plus the cost of whatever sorting scheme.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org