koobas.hobune.stream
Collision Detection Randomly Ignores Hits
The Problem:
I Instantiate special affects & projectiles that use a collider to detect whether it has hit a unit. If it hits the unit it does damage. Units are not being hit by the special affects despite the fact that they are clearly within it's collider. Units that are more recently created have a higher chance to ignore the collision.
Video
http://www.youtube.com/watch?v=EJAWFzkJ5XY&feature=plcp
The Details:
The units have Rigid Bodies, and they are detected about 30% of the time. When paused it is clear that the colliders overlap. The collision is detected by using the OnEnter Trigger. I have also tried On Stay, and the only change is that when it actually detects a collision it triggers every frame instead of once(As it should), but still detects nothing more often.
It seems that the chance of a collision being detected is increased if the Unit has moved or been acted upon in some way. (Such as moving to a new location) I have tried increasing the Collision Detection field on the Rigid Body. No matter the setting, the results don't seem to change.
The code for this is very standard. I check send the collider to another function which deals the damage or spawns effects. The _Attacker is the attacking unit and _EffectAttack & _SpecialAttack are classes that contain the amount of damage or effect to spawn. The code does not even hit the Debug lines which tells me that it is flat out not colliding.
void OnTriggerEnter (Collider collisionObject)
{
Debug.Log("Attacker: " + _Attacker);
Debug.Log("Hit: " + collisionObject.gameObject);
if(_EffectAttack != null)
InitiateAttack(_EffectAttack, collisionObject.gameObject);
else if(_SpecialAttack != null)
InitiateAttack(_SpecialAttack, collisionObject.gameObject);
}
I updated to the latest version of unity a few days before I noticed the issue, so I'm thinking it might be a bug in Unity, but I'm not sure.
Could the problem be associated with using an Instantiated Collider to detect an Instantiated Rigid Body?
Has anyone else experienced similar issues and what steps were taken to fix it?
Does it happen if you don't use trigger colliders? Are you using continuous or discrete collision? I remember a bug where continuous collision objects were not calling OnCollisionEnter properly though I am not sure whether or not that problem was fixed.
The video link you have in the question is broken. (it is a shortened link with ... in it, ins$$anonymous$$d of a proper link)
I have fixed the video link. I have tried changing their detection between all 3 options with no change. Right now they are all set to discrete.
Hmm, that does look odd. It could be any number of things. For now, a work around might be to use Physics.OverlapSphere which would give you the same functionality via different means. Here is an example:
Collider[] colliders = Physics.OverlapSphere(transform.position, 10);
for(int i = 0; i < colliders.Length; ++i)
{
if(colliders[i].rigidbody != null)
//do stuff to object
}
Could you let me know if that works? If not, I would seriously lean towards the issue being a unity bug.
$$anonymous$$y scripts that use Physics.Overlap haven't had any problems. In the video you can see it working when I double click a unit to select all of them. That script is similar to yours, except I don't check for a rigid body. I can add that in tonight.
Attach a rigidbody to the thing with the sphere collider and it will wake up the units presuming it is itself awake. See here for details.
You could also set the rigidbody sleep velocity on the thing with the sphere collider to 0 so that it never sleeps.
After reading more about the sleeping colliders and how rigid bodies interact with them I've used $$anonymous$$inematic rigid bodies to interact with the units. Now the colliders now wake up the units and everything works great.
The problem is that you instantiate a collider/trigger. This is not a problem per se, but colliders(especially sleeping ones) that are in its range will not trigger any of the events until they are moved/woken up. And even then the enter might not fire because they are already in the collider, not entering it.
Now, for a proper solution you shouldn't do the check by creating a collider, but by using one of the various checks that physx provides. For example: http://docs.unity3d.com/Documentation/ScriptReference/Physics.OverlapSphere.html
Is there a way to "wake up" a sleeping collider? I can't seem to find anything about this other than changing the detection setting so that the rigid body checks more often.
I have also tried changing the triggers to OnStay and found that the same issue presents itself; Some objects just seem to be completely ignored.
In places where I use OverlapSphere it has worked without problems, but I don't think OverlapSphere should completely replace all of my Collision triggers. It's nice to have a fall back plan, but removing all of my Colliders is not my preferred fix.
I didn't see that zerot has proposed using OverlapSphere (apologies). You would only be removing colliders from the aoe-skill-effect-prefab. All your unity would need to retain their colliders either way.
Yes, you can wake up rigidbodies using http://docs.unity3d.com/Documentation/ScriptReference/Rigidbody.WakeUp.html
But why do you want to use colliders? the whole instantiating them, waking up rigidbodies, etc. are really expensive operations that are not guaranteed to work properly the way you are using them. overlapsphere however, is a quite cheap solution that is guaranteed to work.
I just want to be aware of all my options, I'm not shooting anything down right now at all; and I'm very grateful for all the help you guys are giving.
Projectiles that use Colliders are also affected. How does calling Overlap Sphere on update or through a repeated function stack up performance wise?
You can give the OverlapSphere a layer argument to ensure you're only checking against the appropriate objects etc. Sphere collision is as cheap as it gets and it's what you're doing with the current system anyway. I wouldn't expect to see any noticeable chance in performance, though the profiler could prove me wrong.
