Collision Detection -- Once again...

Started by
18 comments, last by SippyCup 18 years, 8 months ago
Quote:Can the methods you've described work (easily) with pixel perfect collision?
As you probably already know, there are some difficulties with pixel-based collision detection, such as taking the sprite rotation into account, and generating collision info such as contact normals.

I haven't done any pixel-based coldet, so I know little about the subject; it may be that there are standard solutions to the above problems. That said, I would probably still prefer a geometric approach. If you can approximate your sprites with a simple bounding volume (sort of accurate), a convex hull (more accurate) or a series of line segments (very accurate), you can then express the collision detection problem in terms of these primitives, which I think would be more flexible and easier to work with.

Just IMO.
Advertisement
Just a side note for those people who read this and have more advanced knowledge, I do believe that per-polygon collision is possible with this method (however it would be very processor intensive).
Nice point, jamesbf.

I just figured out that while my collision works perfectly now (thanks guys!! :-)). I cannot really do what I thought I could with it: I have my ball hitting a solid object and now I need a means to "somehow" figure out which normal vector of the object to use.

As an easy example, consider a box. A box has 8 normal vectors: One for each side and one for each corner. Now I must "somehow" figure out, which normal vector to use; right now I can determine, if a side has been hit, thanks to the algorithms described here (circle/line intersection), and I could probably say that if the circle collides with two lines it has hit the edge... Hmm... Aha... Yeah. That should actually work!! Oh -- then I won't need the pixel perfect collision detection after all...

Sorry for this post, but writing down my confusion seems to have helped... Maybe someone will find the information valuable :) And maybe the idea doesn't work?? ==> Will test it now.

Thanks,
Beren
Quote:A box has 8 normal vectors: One for each side and one for each corner.
For collision detection with a circle it's actually a little more complicated than that. In general, with the circle just touching the box, the collision normal is the vector from the closest point on the box to the circle center, to the circle center. In some cases this will be a box edge normal, but in general it can point in any direction, depending on the position of the circle.
Hey everyone. I'm totally new to this type of programming. I have no experience in it. I can follow the math well enough (luckily), but can anyone tell me what exactly the term "sweep" means? :P
Quote:but can anyone tell me what exactly the term "sweep" means?
It just means to take the motion of the objects into account, that is, to 'sweep' them against each other. Other terms for swept collision detection are 'continuous' and 'dynamic'.

Swept tests usually return the time at which the objects first come into contact, as well as the colliding features and the normal at the point of contact. Testing for intersection between two objects irrespective of motion is usually refered to as static collision detection, and commonly returns information about the overlap, if any, between the objects (such as a penetration vector).
Hey again,

I wasnt really sure if i should post again...as its not strictly on topic...but i wanted to ask jyk about some of his comments. (plus it sorta relates to what beren77 mentioned about normals...which i assume was to decide which way the ball should bounce)

Quote:As you probably already know, there are some difficulties with pixel-perfect collision detection, such as taking the sprite rotation into account, and generating collision info such as contact normals.


I had thought about this. My sprite classes take the sprite pic as input (single frame) and generate all necessary rotations on initialisation, and stores them in an array.

When i add an object to the game (a ship/obstacle/bullet) I send a command to the colldet class telling it to add the object to its check list, and which function it can call to get the objects current sprite/location. I was hoping that in this way I could pull off pixel perfect collision without having to worry about rotations etc.

Since the colldet class has the pos (and old pos/displacement vector etc i guess) and image of every object it needs to check...it should be able to perform pixel perfect collision ok, and even return roughly where each collision occurred....right?

or am i going about this the wrong way?

Quote:Swept tests usually return the time at which the objects first come into contact, as well as the colliding features and the normal at the point of contact. Testing for intersection between two objects irrespective of motion is usually refered to as static collision detection, and commonly returns information about the overlap, if any, between the objects (such as a penetration vector).


That's what I figured, but I wasn't entirely sure. Thanks for the explanation. :)
There are a number of good articles (with better solutions than mine) in the book Mathematics for 3D Game Programming & Computer Graphics, written by Eric Lengyel.
Excellent, thanks. I've been looking for a bunch of books on different topics in game programming. That will definitely be a big help.

This topic is closed to new replies.

Advertisement