13 replies to this topic

[Assassinbeast]

Hey, i just need some information on how to check collision if theres 1000 objects on the field.
And all 1000 objects are enemies to eachother.

So, do i for example have to make two for loops like this?:

[source lang="cpp"]for(int i = 0; i < objects.size(); ++i) //objects.size is the size of the vector(if i use that) for(int j = 0; j < objects.size(); ++i) collision(objects[i], objects[j]);[/source]
But thats 1000x1000 = a million loops in a single statement

So, i just want to know if thats how you do it... cant see any other way of doing this so far

Edited by Assassinbeast, 02 December 2012 - 04:19 PM.

[ultramailman]

The idea is to seperate the map into several regions. An object in region B cannot possibly be colliding with an object in region C. So if your 1000 objects are evenly distributed in four regions, you only need to do 4 * (1000 / 4)^2 = 250000 checks. Even less if you split the map into more regions.

[C0lumbo]

Broadphase collision detection is the general term you need to be googling.

Common solutions are spatial partitioning and sweep-and-prune.

[Cornstalks]

There are usually two steps in collision detection: broad phase and narrow phase. The first one, broad phase, is basically going through the objects and creating "groups" of objects that might be colliding. In the narrow phase, each group is individually processed and the actual collisions are detected and resolved. The broad phase is really important, as it allows you to avoid N² comparisons.

As for what broad phase algorithm to use... that depends. You could create a spatial hash (works pretty well if you fine tune it and have lots of objects all of about the same size), binary space partitioning (BSP) trees, sweep and prune, axis-aligned bounding box (AABB) trees, etc. Bullet has a nice page on a couple of broad-phase algorithms.

I don't know what's easiest, but I've found dynamic AABB trees seems to work pretty well (which Chipmunk physics uses by default, albeit it's a little tweaked/fine tuned).

[Yrjö P.]

Before doing anything else, you'll probably want to prevent 500000 useless comparisons by switching the "j=0" in your code into "j=i+1"...

[cardinal]

Yep, subdivide the problem!!!

It's a little more complicated that JUST dividing into regions (i.e. players on the boundaries of two different regions might be able to collide, or a bullet/player might cross from one region into another in one time-step). You'll need to handle these edge cases in addition to what ultramailman suggests.

Octrees/quadtrees are common ways to hierarchically subdivide your world although depending on your requirements you can optimize this in different ways.

[Assassinbeast]

ahh ok, thanks for all the help and suggestions

[Burnt_Fyr]

in addition to what was said,ie: using some form of broad phase culling of objects that can't possibly collide, your loops are naive in that they check each item with each other item... twice. Better would be to change the second loop to:

for(int i=0; i< objects.size() ; i++)
{
   for(int j=0; j<i; j++)
   {
	   // check collisions
   }
}

Your implementation results in n^2 tests, the above in a little over 1/2 that.

[Paradigm Shifter]

Stroppy Katamari already said that, and the j = i+1 method saves checking i == j as well.

You can also sort the coordinates in each axis and check 1 dimension at a time, if something is at x = 1 and moving with an x velocity of +2, it's never going to collide with anything that isn't in the interval [1, 3] in the x coordinate (need to account for the width of both objects in the x axis as well, of course). You need to have a system for reoordering the objects when they move which doesn't involve sorting the whole lot though. Space partitioning systems are just more advanced versions of that kind of thing.

[__UFNHGGI_H__]

hehe
1000 * 1000 == BOOOM

The first solution ::

class Object
{
bool receiveCollision;
};
//player.receiveCollision = true;
//block.receiveCollision = false;
//items.receiveCollision = false;
for(int i = 0; i < objects.size(); ++i)
{
Object* obj =  objects[i];
if(obj->receiveCollision)
{
  for(int j = 0; j < objects.size(); ++i)
  {
   collisionCheck(obj, objects[j])
  }
}
}

The second solution ::

enum Tags { TagPlayer, TagEnemy, TagBlock, TagWeapons};
class Object
{
Tags tag;
std::vector<Tags> collisionTags;
};
for(int i = 0; i < objects.size(); ++i)
{
Object* obj =  objects[i];
for(int j = 0; j < obj->collisionTags.size(); ++i)
{
  for(int k = 0; k < objects.size(); ++k)
  {
   if(obj->collisionTags[j] == objects[k].tag )
   {
    collisionCheck(obj, objects[k]);
   }
  }
}
}

[landagen]

Also, I would say that in order for a collision to take place, one of the colliding objects must have moved. No need to test 2 objects together if neither of them moved.

[iMalc]

Also, I would say that in order for a collision to take place, one of the colliding objects must have moved. No need to test 2 objects together if neither of them moved.

Unless of course you have a more advanced physics system where objects can change size.

But yeah, identifying objects that have not changed in any way and skipping those pairs, is a very useful optimisation to use at some stage in the collision detection process. It likely doesn't matter too much at what point you do it.

Edited by iMalc, 04 December 2012 - 01:44 AM.

[pTymN]

In situations where you need to actually update that many objects each and every frame, well tuned spatial hashing will handily beat all other broadphase methods for large amounts (1000s) of uniformly sized objects - where the largest are within 4-8 times the radius of the smallest objects. If you can get away with only updating a subrect of your game world, that's another optimization you should consider.

[Burnt_Fyr]

Stroppy Katamari already said that, and the j = i+1 method saves checking i == j as well.

I was ninja'd! (i was interrupted mid post at work, and didn't get to finish until after many follow up posts)

+1 on the j=i+i solution though.