of a geometry problem than a physics problem
better for a game's performance when as basic and simplistic as
The higher the frame-rate of the physics, the more
realistic it can seem.
or 3d) circles:
if the distance from the bounding sphere centers (of two
objects) is >= the sum of
this equation: distance= sqrt(dx^2+dy^2) <= R1+R2 (slow)
better yet, this version: dx^2+dy^2 <= (R1+R2)^2 (faster
since no square root)
simple spherical collision as the base of all collision detection,
doing more advanced collision detection once the insides of the
spheres have been penetrated.
check each object against every other object in the game each frame
(more on this further down in the other recommendation sections).
Dealing with movement: With discrete time, you are “teleporting”
objects, moving them in a
linear fashion (along a straight-linepath) each frame. You need to take into account when objects
should collide (when they cross paths in a
frame/time step), but
it is skipped by the step. This, because the objects went past one
instead of into one another.
sure that objects never “teleport” over one another to
avoid the problem altogether.
For example, you could make it such
that objects can never move more than double the radius
bounding sphere in any given time-step. Where if you capped the
speed so that a
bounding sphere could not move more than twice
it's radius, for a 0.1 sec. time-step,
you would simply multiply
that by the frame rate to determine the max velocity
of the object
in terms of your game's distance units.
For smaller objects (with smaller bounding
sphere radii) that you want
to go fast (e.g.: bullets), you can make the time step smaller.
course there is a performance hit, so only do it if you can get
away with it in your game.
if the center of one object’s bounding box is intersecting
with the rectangular path of
another object over the current frame.
The rectangular path of objects should be taken into
line segments given the objects position in the last frame to the
This can be stored or reverse computed using the
collision between rectangles of arbitrary size and orientation.
using boxes, you can just check the normal vectors on all sides
, six orthogonal planes) in regard to the center
point of the line-path that the object
passed through this frame.
You can take all the normals (of the cube) and say: if I’m on
the “in”-side of each line as it passes through the
planes of the rectangular path. Then
you can detect whether or not
you’re inside the box (with respect to a current vertex),
the objects are colliding.
Detecting precise collisions:
can check if the rectangle made up by the path of an object's
bounding sphere has collided
with the rectangular volume of another
check the line-paths of objects in a frame and not the rectangular
Of course, this method is less accurate when it comes
to detecting collisions with
the smaller objects.
rebound effects, variables, and coefficients involved with the
like: momentum coefficient, reverb, coefficient of
time steps with linear movement of objects over each frame
a collision between objects is detected, doesn't the order that
are resolved in matter? For example a collision
between two objects can get resolved before
a third object that was
supposed to be involved with the collision could also be resolved as
should have been.
If you have the velocities of your game objects capped, so that they can
only move a given distance
each frame and the faster objects are
updated first (before collision detection/resolution).
let colliding objects be interleaved (occupying some portion of the
out where on an object's path (in a frame) it's bounding sphere
with the edge of the other object's bounding sphere, then
place the object just before it.
That is close enough to "collide"
(Have objects close enough to look like it).
moment you detect an object collided, move it back half the distance
that it traveled, you
either are colliding or not. Continue moving
objects back and forward to make them "collide"
at near the
exact place and time that they (actually) collided. A binary search
to achieve this method.
an epsilon value to determine when objects are close enough to be
in contact (This is done
mainly for speed purposes but accuracy is
also a factor). Think of it like this: How big can
value be made and you can get away with it. In 2d you’d want
the epsilon value to be
something like one pixel (simple right?).
But with 3d you can fudge it more and it may take some
do complex polygon collisions, but they are very hard. Convex
polygons are much easier
to do collision for than concave ones.
Even if there are concave polygons being used, they
can be broken
up into multiple (connected) convex polygons.
discrete time steps there is a problem with collisions on walls, if
something goes fast enough
then it could be ambiguous as to where it
will be at the end of the frame in the provided time step.
polygons are planes and can be considered as walls depending on your
something collides with a wall so fast that it appears far away from
the wall such that it’s
noticeable. Then the object should be
put right next to the wall so that it looks like it collided.
processing one object at a time, objects can get interleaved within
one another. You can sort
each of the objects from the slower to the
faster moving ones so that no slow-moving object could
get into a
faster moving one. You may want to put a hack into the game to take
into account when
objects are colliding and have the same velocity.
have a 2d (or even 3d) array, partitioning the world into sections
to cells in the array) where only the objects in each
section would be processed for collision with
other objects in that
and perhaps subsequent sections.