Some questions about colllision detection
Author
I'm trying to figure out where / how I should handle collisions.
I've got a few guesses. Correct me where I'm wrong?
The game may have a physics subsystem that takes care of gravity, collisions, etc.
Collisions should be checked after player (and AI) have made their inputs.
A collision occurs if the boundaries of two objects are touching or have started crossing over.
The physics subsystem looks at all movable game objects and updates them based on velocity, etc.
It moves them before checking for collisions?
What did I get wrong?
You're right sofar. To handle movement/collision there're several approaches.
Most often all objects are moved first and then checked for collision. If a collision occurred a penalty force is applied to resolve overlapping objects. This works quite fine as long as you don't have small fast moving objects. In this case a fast moving object could penetrate a thin obstancle in a single frame without detecting any collision.
An other way to handle movement/collision is to check, at what time an object will collide with an obstancle if it keeps moving on with the given velocity. This is "quite" simple for point (=ray-cast) or spheres, but getting more complex and much slower for other collision shapes.
If you plan to write your own physic subsystem I would suggest to start with a penalty force approach. But my advice would be to use one of the free physics libs like physX,newton,bullet,ode, because writing your own physic lib is really a pain in the ... (I gave up after 2-3 years and use the bullet lib now).
--
Ashaman
Most often all objects are moved first and then checked for collision. If a collision occurred a penalty force is applied to resolve overlapping objects. This works quite fine as long as you don't have small fast moving objects. In this case a fast moving object could penetrate a thin obstancle in a single frame without detecting any collision.
An other way to handle movement/collision is to check, at what time an object will collide with an obstancle if it keeps moving on with the given velocity. This is "quite" simple for point (=ray-cast) or spheres, but getting more complex and much slower for other collision shapes.
If you plan to write your own physic subsystem I would suggest to start with a penalty force approach. But my advice would be to use one of the free physics libs like physX,newton,bullet,ode, because writing your own physic lib is really a pain in the ... (I gave up after 2-3 years and use the bullet lib now).
--
Ashaman
Maybe you also want to have a look into the book "Game Physics Engine Development" from Ian Millington. It describes the techniques used for physics simulation and also develops a small physics engine in the course of the book.
Basically you have three parts in your physics engine. One part simulates the motion of objects, calculates forces and applies them etc. The second part performs collision detection to find objects that collided. The third part is doing collision resolution.
Collision detection can be performed in two ways. One way is to move all objects at once and then perform collision checks afterwards. This is good enough in most cases, but maybe not good enough for a billard simulator. The second way would be to search for the next collision event, handle the collision, then continue the simulation. But this is very time consuming compared to the other method.
Collision resolution takes the information obtained from the collision detection phase to separate objects that penetrated each other or apply some constraints.
Basically you have three parts in your physics engine. One part simulates the motion of objects, calculates forces and applies them etc. The second part performs collision detection to find objects that collided. The third part is doing collision resolution.
Collision detection can be performed in two ways. One way is to move all objects at once and then perform collision checks afterwards. This is good enough in most cases, but maybe not good enough for a billard simulator. The second way would be to search for the next collision event, handle the collision, then continue the simulation. But this is very time consuming compared to the other method.
Collision resolution takes the information obtained from the collision detection phase to separate objects that penetrated each other or apply some constraints.
Author
Thanks for the replies guys :)
The collision resolution part confuses me a little.
Say there's a ball in the game that hits the ground.
The game detects a collision:
the edge of the ball has entered the ground slightly.
So now, would a collision resolution mean just calculating the
velocity (including direction) at which the ball will bounce,
and setting the ball's velocity to that?
Or is there more to it?
(Do you have to remove the edge of the ball from the ground,
and then setting its velocity?)
As for using PhysX, I'm doing pretty simple stuff so far (Mario-like game),
so I'll wait on that.
On a side note, I'm not sure how to check for collisions in the game yet...
Is it based on the image of the level? Or are there objects in the code that
model the floor, water, etc.?
The collision resolution part confuses me a little.
Say there's a ball in the game that hits the ground.
The game detects a collision:
the edge of the ball has entered the ground slightly.
So now, would a collision resolution mean just calculating the
velocity (including direction) at which the ball will bounce,
and setting the ball's velocity to that?
Or is there more to it?
(Do you have to remove the edge of the ball from the ground,
and then setting its velocity?)
As for using PhysX, I'm doing pretty simple stuff so far (Mario-like game),
so I'll wait on that.
On a side note, I'm not sure how to check for collisions in the game yet...
Is it based on the image of the level? Or are there objects in the code that
model the floor, water, etc.?
Well, collision resolution can be much more complicated than you might think.
For instance take you example with the ball. Maybe the ball was moving (too much) and penetrated the wall. The correct resolution for letting the bounce off the wall would be to calculate the point where the ball would have hit the wall, calculate the bounce, and move the ball to the location where it should be (also consider that the wall might not be hit in a straight way).
But the ball might also have penetrated the ground because of gravity. Inverting the movement speed of the ball might cause the ball to suddenly jump up from the ground instead of resting on it. So the correct handling for this case would be to reposition the ball with distance zero to the ground and without any (vertical at least) speed.
And what happens if the ground is not horizontal ? If the ball is moved out of the ground in the direction of the ground normal, then it would slowly move down the ground plane although static friction would prevent this.
And its more complex if you also consider constraints and interaction between objects.
So even for simple physics it might be worth using one of the physics engines available.
For instance take you example with the ball. Maybe the ball was moving (too much) and penetrated the wall. The correct resolution for letting the bounce off the wall would be to calculate the point where the ball would have hit the wall, calculate the bounce, and move the ball to the location where it should be (also consider that the wall might not be hit in a straight way).
But the ball might also have penetrated the ground because of gravity. Inverting the movement speed of the ball might cause the ball to suddenly jump up from the ground instead of resting on it. So the correct handling for this case would be to reposition the ball with distance zero to the ground and without any (vertical at least) speed.
And what happens if the ground is not horizontal ? If the ball is moved out of the ground in the direction of the ground normal, then it would slowly move down the ground plane although static friction would prevent this.
And its more complex if you also consider constraints and interaction between objects.
So even for simple physics it might be worth using one of the physics engines available.
Author
Oh wow, that does get a bit complicated...
Guess I'll start looking into some physics engines.
Any advice on the collision detection in a platformer?
Do you use the image itself to check for collisions?
(Sounds complicated, and inflexible. You'd have to hardcode a
floor color and a character color... everything's a lot harder
when you move away from using square tiles.)
Or do the platforms have collidable objects in the code that
represent them and are used for checks?
(And if so, do you hardcode their locations
based on the image you're using for the level?)
Sorry for all these questions, but I can't seem to find any good
online resources for game architecture.
[Edited by - meteorstorm42 on June 10, 2009 8:19:45 PM]
Guess I'll start looking into some physics engines.
Any advice on the collision detection in a platformer?
Do you use the image itself to check for collisions?
(Sounds complicated, and inflexible. You'd have to hardcode a
floor color and a character color... everything's a lot harder
when you move away from using square tiles.)
Or do the platforms have collidable objects in the code that
represent them and are used for checks?
(And if so, do you hardcode their locations
based on the image you're using for the level?)
Sorry for all these questions, but I can't seem to find any good
online resources for game architecture.
[Edited by - meteorstorm42 on June 10, 2009 8:19:45 PM]
I can't imagine any platformers use the image directly to calculate collisions, that's a task humans are better at than computers for now. The static geometry would be stored in your level file. The idea would be to create the level file in an editing tool in which you set up your background tiles and create you collidable entities together so it's easy for the designers to keep the two in sync.
Author
So you're saying that a level editor could serialize Platform objects as well as save the image?
So I guess the platforms available in the editor would be hardcoded with a specific shape. Makes sense.
The image and serialized Platforms file would have to be separate but in the same folder, right?
Not necessarily, it's perfectly possible to wrap up image data with other types in one archive. For example if you look at the first total war games they use a "bif" file format for their sprite sheets which contain several images (actually one per frame) and also some meta data associated with the animations I think. A binary archive like that makes efficient use of space and keeps relevant things together, but aren't human readable outside of your tool/game which may make debugging more difficult.
Author
Quote:Original post by Somnia
Not necessarily, it's perfectly possible to wrap up image data with other types in one archive. For example if you look at the first total war games they use a "bif" file format for their sprite sheets which contain several images (actually one per frame) and also some meta data associated with the animations I think. A binary archive like that makes efficient use of space and keeps relevant things together, but aren't human readable outside of your tool/game which may make debugging more difficult.
Huh, that's pretty cool :)
Sounds tricky though. Maybe I should stick to separate files for a little while longer.
I think I've decided to make a level editor before I get into the actual game too much.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
