- Home /
Detecting enemies - SphereCast or Sphere Collider?
I want to be able to detect enemies within a certain range of my player. To do this, I want to build a hash table of known enemies within range of my player and cast rays to see if they are visible or not.
In order to see any enemies are in range of the player, I have two options:
1) Attach a sphere collider to my player, set it to "trigger" and add any enemies who fall into the trigger to my hash table. So far, the results for this seem variable and I'm getting trigger events when other triggers enter the sphere which is undesirable... I only want to listen for colliders.
2) Use Physics.SphereCast at a set interval. This will likely be more accurate.
Considering my scene could have up to about 20 players at a time all checking for enemies, which of the two methods would be considered the most sensible?
Answer by Bampf · Apr 28, 2011 at 06:23 PM
SphereCast is like raycasting, but instead of casting a single ray it casts a sphere. So this would be more useful for, say, detecting if a thick beam hits something, or if a ball will hit anything as it moves along the direction of the ray.
The sphere collider seems more suited to your task as described, and may be less expensive to check. You will have to skip over collisions with objects you aren't interested in; you can script that, or use Unity's collision layers.
If your player is moving fast enough that it will skip completely over obstacles between frames, then maybe SphereCast is indeed the way to go. You'd be casting between the player's position last frame to the position this frame, and using the distance argument as well. You'd be able to limit the collisions to objects of interest using the layermask argument.
$$anonymous$$y players will never be moving that fast, so it sounds like a sphere collider is the way to go.
I was going to say that Bunny83's suggestion of OverlapSphere might actually be superior to a sphere collider, in that it lets you use layers to screen out objects you aren't interested in. But you can use layers with colliders as well. So either way will work. I'll add a note to my original answer.
If you're doing this often though, you're creating a lot of temporary objects which can lead to GC spikes - bad on mobile!
Answer by Bunny83 · Apr 28, 2011 at 06:18 PM
In such cases i would recommend Physics.OverlapSphere which gives you an array of all colliders within the sphere radius. Note that you can use a seperate layer for your enemies and specify a layermask when you use OverlapSphere. That way you only get colliders that are on this layer. For the visibility check it seems that you can't get around a raycast. For that purpose i'd like to mention Collider.Raycast which tests only against this collider.
I believe OverlapSphere only return colliders at the same height. It will not return enemies on a slope or in similar situation.
What do you mean with at the same height? as long as the bounding box of a collider touches or overlaps the sphere it will be returned.
I've always believe OverlapSphere was more of a 'circle' than an actual 3d sphere, I thought it was the difference with CheckSphere, now that I re-read the Scripting Reference, I wouldn't know. Disregard my first comment :p
Answer by Joshua · Apr 28, 2011 at 06:17 PM
I think a trigger sphere would be less heavy for the machine. And if it also fires when other triggers enter, just check if it's a collider. But instead, could you not use isVisible?
Is Visible refer cameras. Which are not always what the game needs.
You're right isVisible would be a way to check for visibility. But keep in $$anonymous$$d every camera counts! In the editor the sceneview camera is also a camera. http://unity3d.com/support/documentation/ScriptReference/Renderer-isVisible.html
Your answer
Follow this Question
Related Questions
Question about collision and trigger 2 Answers
Get All Renderers inside of GameObejct 0 Answers
Collider that can trip triggers that doesn't affect game physics? 1 Answer
Is there a way to determine if an object is within a trigger, from objects perspective? 2 Answers
Version 3.2 gives no OnTriggerExit when collider is parented 12 Answers