General:

Collision is:

- Detected and resolved
- More of a geometry problem than a physics problem
- Much
better for a game's performance when as basic and simplistic as
possible.

The higher the frame-rate of the physics, the more realistic it can seem.

Basic Detection:

**Basic collision type:**- Check
if the distance from the bounding sphere centers (of two
objects) is >= the sum of

their radii - Use this equation: distance= sqrt(dx^2+dy^2) <= R1+R2 (slow)
- Or better yet, this version: dx^2+dy^2 <= (R1+R2)^2 (faster since no square root)

(2d or 3d) circles:

- Check
if the distance from the bounding sphere centers (of two
objects) is >= the sum of
**Recommendations:**- Use
simple spherical collision as the base of all collision detection,

doing more advanced collision detection once the insides of the spheres have been penetrated. - Don't
check each object against every other object in the game each frame

(more on this further down in the other recommendation sections).

- Use
simple spherical collision as the base of all collision detection,

**Problem:**

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 another

instead of into one another.**(One) Solution:**

Make 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

of their 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.

Of course there is a performance hit, so only do it if you can get away with it in your game.

**(A second) Solution:**

Check 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

account with line segments given the objects position in the last frame to the current one.

This can be stored or reverse computed using the physics involved.

**Problem:**-
Detecting
collision between rectangles of arbitrary size and orientation.

**(One) Solution:**-
When
using boxes, you can just check the normal vectors on all sides
(parallelopiped

, 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),

and the objects are colliding.

**Problem:**Detecting precise collisions:

You can check if the rectangle made up by the path of an object's bounding sphere has collided**(One) Solution:**

with the rectangular volume of another object's path.

Could check the line-paths of objects in a frame and not the rectangular path volumes.**(Another) Solution:**

Of course, this method is less accurate when it comes to detecting collisions with

the smaller objects.

**Tips:**Determining if arbitrary boxes have collided is very difficult and not advisable in contrast

to sphere collision.

**Key factors to consider:**

- Momentum
- Other
rebound effects, variables, and coefficients involved with the
physics,

like: momentum coefficient, reverb, coefficient of friction, etc. - Discrete time steps with linear movement of objects over each frame

**Problem:**

After a collision between objects is detected, doesn't the order that objects collisions

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 it

should have been.**(One) Solution:**

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).

**Problem:**Can’t let colliding objects be interleaved (occupying some portion of the same space).

**(One) Solution:**Figure out where on an object's path (in a frame) it's bounding sphere collides

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).

**(A second) Solution:**

The 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 is efficient

to achieve this method.**Tips:**- Use
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

the epsilon 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

more fine tuning.

**(A third) Solution:**

Can reverse compute the positions of both object's bounding spheres when they collided to where

they were before. Then you will have a beginning and end point for the object's path in that

frame. Once you have the paths (as line segments) you can encompas the bounding spheres volume

along that path as a rectangular of size correlating to the bounding sphere/path length and at

an arbitrary orientation.

**Tips:**Often times phsics engines are made for the general purpose case and as such don't take

advantage of major shortcuts, so they're not as fast as something you could make.

Could 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.

**Problem:**With 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.

Note that polygons are planes and can be considered as walls depending on your circumstance.**(One) Solution:**If 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.**(A second) Solution:**When 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.

**(A third) Solution:**Could have a 2d (or even 3d) array, partitioning the world into sections (equating

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.