the game object they're attached to

to react to other colliders

provided that one of the game objects

has a rigidbody component attached.

Colliders come in various shapes and types,

and are denoted in the scene view

by a green outline.

They can have the following primitive shapes:

a sphere, a capsule and a box.

For more complex shapes you have two options

You can either combine several of these

primitive shapes together by applying

primitive colliders to different objects.

in our hierarchy.

For example this workbench

has a number of objects which simply

serve to make up it's different colliders

for various areas.

The other option is to use a mesh collider,

which will fit the exact shape of the

mesh that you specify.

The workbench on the right has no hierarchy

but instead uses a mesh collider.

The reason not to use a mesh collider

is that it will fit the exact shape

of the mesh that you specify. So if you

only specify the mesh of your detailed model

then it may be providing too detailed

a collision mesh and effecting performance.

This is the reason why it's often better

to make a compound setup instead.

However it should be noted that a third

option for creating collision geometry

is to use a separate, simpler set of

geometry and still use a mesh collider.

In this example we have this complex

robot arm asset.

It's a very detailed mesh

but we don't want a mesh as complex

as this for the collisions.

So what we've done is built

a secondary set of geometry which we've

then applied to a series of mesh colliders.

For example this part of the claw is more

detailed than the collision mesh

that we've created for it.

And this has been done in two separate

FBX files -The original artwork and

a simplified set of geometry.

We've then gone through each one,

applied a mesh collider and dragged

these meshes over as the

collision meshes to use.

This means that we get the kind of accuracy

that we need in terms of collision

without the performance overhead.

When collisions occur in the game engine

one collider strikes another and an event

called OnCollisionEnter is called.

In this scene our 'prop samoflange' object

has a sphere collider component and a rigidbody component.

The rigidbody provides mass and gravity.

When I play the game, one falls down

and strikes the other.

The power cube has a box collider attached to it.

Also attached to our falling object

is this script.

This script checks for three collision events.

OnCollisionEnter, OnCollisionStay

and OnCollisionExit.

When each of these occurs it writes

to the console using Debug.Log.

It will register when Enter is called,

when Stay is occurring

and when Exit is called.

So if we look at our console you can see

that Enter is called, Stay has occurred

for a while and then Exit is called.

If we pause the game and play we can look

at this example slowly.

As I step through the frames

when the collision occurs you can see

that Enter is called, so OnCollisionEnter

has just occurred.

As I continue OnCollisionStay is occurring.

You can see on the right here that it's

happening several times because these

two colliders are still in contact.

As we continue to step through

eventually OnCollisionExit is called

when the two colliders are no longer

in contact.

Note that for an OnCollision message to

to be sent, one of the two objects colliding

must have a rigidbody component.