C# Collision Detection

Unity Engine
1

Hi,

I’m getting very frustrated with myself for not understanding from all the tutorials on this how to do simple collision detection with a string output to log.

I’m struggling to find a tutorial that does just this, and the documentation for this area is rather difficult and bewildering.

Does anyone know of any way to just have the custom character hit a trigger, be it rigid body or box triggers etc… (preferably box because I’ve read rigid bodies can be a bit of a hassle) and output some debug text or something similar?

If you don’t know a tutorial but have a quick sample of code for me to look at that would be great too.

Thanks for any help

2

Create a new C# script, and add these methods:

	void OnCollisionEnter(Collision collision) {
		GameObject otherObj = collision.gameObject;
		Debug.Log("Collided with: " + otherObj);
    }

	void OnTriggerEnter(Collider collider) {
		GameObject otherObj = collider.gameObject;
		Debug.Log("Triggered with: " + otherObj);
    }

Now, make sure your objects have colliders or triggers on them, and bang them together somehow. You should see the messages in the log. I can’t go do this now myself in order to give you step-by-step instructions, but try this and if it you get stuck, post back and we’ll try to help some more!

3

Hi thanks for the code. I couldn’t get it to work though (although it all compiled fine).
You said “Make sure your objects have colliders…” I forgot to mention i’m not using any physical object like a mesh, so far i’ve just been placing an empty, then adding a box collider component in the hopes I can reference that in script (kind of how it’s done in UDK).

Truthfully that scripts confused me a little, in the functions parameters are you defining a Collider object named ‘collider’? or is collider something already predefined?

Sorry for amateur hour over here, I really didn’t think something like this would be this taxing.

4

No problem, I’ve got a moment to run Unity now so let me be more specific. Try this procedure first — we’ll worry about empty GameObjects later:

  • Start a new scene.
  • Create a Cube (GameObject → Create Other → Cube). Name it Cube1 and put it at 0,0,0.
  • Create a second Cube. Call in Cube2, and position it a meter or two over the first one.
  • Now, with that second Cube selected, add a Rigidbody (Component → Physics → Rigidbody). (This is just to make it fall without requiring any code.)
  • Run the scene. You should see the second cube fall down and land on the first.
  • Now attach the collision script you made above to Cube2.
  • Run again. You should see “Collided with: Cube1 (UnityEngine.GameObject)” in the console.

If you attached the script to Cube1 instead, then the console message would point out the collision with Cube2.

Now, if you like, delete Cube1, and create an empty GameObject. Name it EmptyCollider, position it at 0,0,0, and add a Box Collider component to it. Run again. You should see “Collided with: EmptyCollider” in the console. So you can see that it works just as well with anything that has a collider, but when starting out, it’s much easier to work with objects you can see.

As for the OnColliderEnter and OnTriggerEnter methods, these are magic methods defined on MonoBehaviour. As long as they’re named exactly that way, they will get invoked at the appropriate times. (It doesn’t actually matter what the parameter is called, though.)

Cheers,

  • Joe
1 Like
5

Thank you for that great reply!

That did work, really interestingly too. With ‘is trigger’ selected I can use it, just as an invisible trigger as it has no physics of the box, which is really cool and what I was after. And weather it is a trigger or not depends weather it’s a collision or a trigger, which also helps clear up the need for two separate functions.

I think I understand the code more now too, that when the script runs from the object itself its calling for any collision to it, and ‘collision’ is just a way of referencing it, and then ‘collision.gameobject’ is the touched object? so setting that to ‘otherobj’ is just a way of making it nicer for the debug line? where otherobj = collision.gameobject?

Cheers for putting so much time into explaining this for me, it’s been an amazing help!

6

Yes, I think you’ve got it exactly. The Collision object contains all sorts of information about the collision event, but usually what I care about is what object was hit — which you get to via the gameObject property. But look at the other properties in the docs; relativeVelocity, for example, is really helpful for determining how hard the objects hit, and from what direction, so you can respond appropriately.

7

Yeah that’s brilliant!
I tend to rely on the documentation because of how easy they are to find what you need, although with the trigger I was having some trouble as the first paragraph hit me like a riddle.

Thank you for clearing it all up for me though.