Physics in
a game serves many purposes, but its primary goal is to create realism. The addition of physics brings along many emerging dynamics; from
complex real-world interactions such as gravity, springs, water, clothing
movement, to explosions, there is much that a physics engine can do to enhance
the overall experience of your game. One vital topic of physics is collision
detection.
In order to
represent objects in our game world, we typically need a collidable entity – or
bounding box, shape to represent it in a “physics world”. The collidable entity
is not visible to the player, but is attached and used to represent objects in
our game world. Implementation wise, as the entities in our physics world is updated,
based of elements such as gravity, and force, the game world will use the
updated collidable entity to transform our game world objects. An example of
this would be having say a basketball in our game world, and creating than attaching
a collidable entity from the physics world. The collidable entity will likely
be a sphere shape and will be given physics properties such as bounciness, mass
and drag. When our physics world updates, the collidable entity will frame by
frame fall to the ground and bounce. To
apply this to our game world, we simple use the updated attributes from the
collidable entity and apply them to our game world’s basketball mesh.
Above, we
see that we used a sphere primitive to represent our basketball in the physics
world, however for more complex shapes there are many other options. The player
object, depending on game complexity will likely be represented with a capsule
in our physics world. Another primitive for
our collidable entities is the box.
When it
comes to actually detecting collision between objects, some of the methods are
:
Axis-aligned
bounding box (AABB) is one of the simplest implementations of collision detection;
it involves creating bounding boxes from the same coordinate system. Collision is detected if any points are inside
another. Essentially for the 2 objects a collision is checked for, it is the
equivalent to drawing a box, with the axis x, y, z to be parallel to one
another. The major problem with this method is if one of the objects is rotated,
in which case the bounding box becomes very inaccurate, with the potential for
having a lot of empty space. This was the case for my previous GDW game, where
fences had bounding boxes that were too big, when rotated or checked against
the character at a non-parallel angle.
The other
method that remedies the above problem is to create an Oriented bounding
box(OBB), essentially the boxes will no longer have parallel axis, but will be
rotated by its local transformation. To detect the actual collision, there are methods
such as using Seperating Axis Theorem(SAT).
The basic idea
behind the SAT algorithm is to create a projection of each edge, perpendicular
to itself (normal). A vector is formed and if, there is no overlap between the projection
formed and the project of the other bounding box, this edge will have no
collision. If there exists a projection where there is no overlap, than the 2
bounding boxes is determined to be not colliding.
Detection
of other primitives is more straightforward. For instance, collision between
spheres can be determined by comparing their respective radii to get the distance from one another.
No comments:
Post a Comment