Collision Handling

Sage
Posts: 1,066
Joined: 2004.07
Post: #1
When you are making collisions in your games, do you make each item handle its own collisions with other objects (a class function that handles collisions) or a global collision code that you use for all objects? I currently use a global collision code but I feel as I add more items to the world, it will become less and less useful unless I make class functions to specifically handle the collisions.
Quote this message in a reply
Wheatie
Unregistered
 
Post: #2
While I haven't done a lot of collision handling, the way I have done it in the past is as a class method with a parameter of the other object (preferably defined as virtual in the super class of all objects) so that each object only has to deal with how it responds. The other object can take care of itself. Then, you can have a more "global" function that does the actual checking and sends the message to the specific objects. In the global function, this is where you can quickly eliminate checks that don't need to be made.

This is how I would do it, but I'd be interested in hearing how others would do it.

And if that description didn't make much sense as I'm rather tired right now, I can always try it again for you.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #3
Lately I've been rethinking SPK. This was one of the same things I thought of, and heres what I came up with:

1. If you have different ways objects can collide, then you'd need to have a class method to collide the object with every other kind. This leads to redundant code.
2. What arbitrates the collisions? Does the object simply collide itself with all others? That would lead to redundant collisions.
3. Colliding objects both modify each other. In an OOP sense, it should be arbitrated from a higher level. Unless it's colliding with a part of something that the object owns.

Here's what I think I'm going to do:
1. Wrap the collisions up into "collision objects". These collision objects are initialized to collide certain objects or groups of objects of the same type with another group. This way you'd only need to make a collision routine once for each two kinds of objects you want to collide, not once in every class of object you'll have in your world.
2. Create an environment class that owns all of the objects and collision objects in the world, and let it manage their simulation and collision.
Quote this message in a reply
Sage
Posts: 1,066
Joined: 2004.07
Post: #4
If I used derived classes can the collision checking have the ability to not only take the classes but know which kind it is?

For example:
I have a class CObject.
Then derived classes CItem and CBuilding and CCharacter.

Can I create a function like:
void function(CObject newObject)
{
collision checking....
if type is _____
{}
if type is _____
{}
}
Quote this message in a reply
Member
Posts: 304
Joined: 2002.04
Post: #5
typeid() returns a type_info object, so you can:

if (typeid(CMyClass)==typeid(newObject)) {...
Quote this message in a reply
Sage
Posts: 1,066
Joined: 2004.07
Post: #6
oh cool. So, I would type something like:
CMyClass object1;

if (typeid(object1)==typeid(CMyClass))

Just making sure I know what to put in there.
Quote this message in a reply
Sage
Posts: 1,066
Joined: 2004.07
Post: #7
Nevermind. At a second look I realize that that is exactly what you posted.
Quote this message in a reply
Sage
Posts: 1,066
Joined: 2004.07
Post: #8
I'm having some trouble. These are pieces of my class CCharacter. If anybody can see why the code will compile warning and error free yet my character falls through the building. The variable aBuilding is a CBuilding defined as a private variable of the class CCharacter specifically and exclusively for this one line of code.

Code:
#include "Building.h"

Code:
CBuilding aBuilding;

Code:
void CCharacter::CheckCollision(CObject &object)
{
  .......

Code:
if (typeid(object) == typeid(aBuilding))
Quote this message in a reply
Sage
Posts: 1,066
Joined: 2004.07
Post: #9
I found a better method using a dynamic_cast function. Collisions are working as perfect as I can code the inequalities.
Quote this message in a reply
Moderator
Posts: 365
Joined: 2002.04
Post: #10
If you can avoid using RTTI features (typeid and dynamic_cast) then do so, because they can have quite a lot of overhead, especially if you call dynamic_cast a lot. The presence of these features in your code usually means you've messed up the design of your class hierarchy.

A better solution is to simply include virtual methods for collision detection near the bottom of your class hierarchy, and have different derived classes override those methods in whatever way is most appropriate to them.

Neil Carter
Nether - Mac games and comic art
Quote this message in a reply
Sage
Posts: 1,066
Joined: 2004.07
Post: #11
The problem comes in that the class that is determining the collision must know what it is colliding with (what class) in order to properly respond.
Quote this message in a reply
Wheatie
Unregistered
 
Post: #12
It isn't the greatest solution, but you could always have some sort of member variable that keeps track of the broad type of an object, i.e., a building, another player, etc. that you could check. It would eliminate use of the runtime features and still give you the same functionality, even if it took a little work in the constructors and hierarchy to get it right.
Quote this message in a reply
Moderator
Posts: 365
Joined: 2002.04
Post: #13
It's still better to generalise the collision interface by making base class virtual methods which are applicable for all kinds of objects, and overriding them to provide specific functionality. There's almost always some way of reorganising the design to accommodate this.

How about this: make an overall collision engine which detects possible collisions by looking for intersecting bounding spheres. When it detects a collision between a pair of objects, it calls the same method (void Object::Collision(Object *otherObject)) on both objects to tell each one about the other, and each object simply examines the other one to determine whether they really collided and how they should react to the collision.

Neil Carter
Nether - Mac games and comic art
Quote this message in a reply
Wheatie
Unregistered
 
Post: #14
NCarter Wrote:When it detects a collision between a pair of objects, it calls the same method (void Object::Collision(Object *otherObject)) on both objects to tell each one about the other, and each object simply examines the other one to determine whether they really collided and how they should react to the collision.

That's basically what I meant in my first suggestion for his collision handling code, but worded much better. Ninja
Quote this message in a reply
Sage
Posts: 1,066
Joined: 2004.07
Post: #15
I changed from the dynamic cast code to simply putting a variable in the base class that sets the type using some enumerated constants. That much works rather well. The problem is my actual collision code. I used to only have collisions on the left, right, and top faces of the cubes. Now there are collisions on the front face as well. I'm not sure how to code this. I've tried a few different things but I get very undesireable results. Does anybody have some code for checking the collision between a) two cubes or b) a cube and a quad?
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Verlet integration - Collision Handling - C++ utdiscant 2 3,519 Dec 21, 2007 09:02 PM
Last Post: utdiscant
  What collision handling code to use Tasnu Arakun 5 3,131 Sep 25, 2004 08:59 AM
Last Post: FCCovett
  CB Key handling skyhawk 6 3,448 Aug 12, 2003 10:13 AM
Last Post: kelvin