Is it normal for OnCollisionEnter() to not register sometimes? I have my objects change color and output debug text when the OnCollisionEnter() function is called and I have noticed that the system misses about 25-50% of the calls. It is never called even though I can see the objects react to the collisions (they are knocking around via physics.)
Is there anything I can do to have the event work 100% of the time?
I believe the physics engine does collisions at a certain time in each frame. IF one object moves thru another in the time between frames, then it will not be detected. So, when the collider or objects are too small, relative to their speed, they wont collide because one frame they haven’t met yet and the next frame they have passed each other.
Here’s the thing though, the physics engine is working, it’s just that my game isn’t receiving the OnCollisionEnter() events. I can see the objects collide and react accordingly on-screen, but my event isn’t getting executed. Is that to be expected?
is the object set to be a trigger?
is the performance high enough? I guess otherwise the event could be removed from the queue again if it falls “too far behind” until it would be executed.
It’s not a trigger. I will try more solver iterations and see if that helps. The odd thing is that the physics system seeme to be working fine, it’s just the event pushing that is missing calls or not sending them. That’s what it seems like though.
No, I’ve never seen that happen. It would make games using physics basically impossible if that were true.
–Eric
Hmm, I wonder if its another problem of Snow Leopard…I’ve seen quite a few issues so far so it wouldn’t suprise me.
Do you move the colliders around without adding a rigidbody?
Sure don’t. Nothing changes on the objects except internal vars I have (such as score.) I do have a FixedUpdate() routine present as well.
Could the collisions be registering in there maybe? So far it’s very annoying. My game is supposed to be over for example when the objects hit a certain collider but right now it registers about 50% of the time. The objects collide properly visually but no event is triggered.
I’ve moved the solver iterations around (up and down) to no avail.
And the object that hit the colliders has a rigidbody attached right?
I’m using OnCollisionEnter and OnTriggerEnter all the time and I’m not experiencing any problems. Maybe you should create a small test project showing the bug and submit it with a bug report.
Yeah, there is a rigidbody. Like I said before, it works about half of the time. I would assume it would work 0% of the time if I didn’t have it set up properly?
One thing I did was change the Physics FPS rate. Trying that now.
How fast are the rigidbodies moving? As discussed on another thread here, there are velocities beyond which collisions will not be detected. You can see this by setting up simple scene where you bounce a ball off a wall. Things work fine up to a point, but there is a velocity threshold beyond which the ball will go right through the wall every time. This can be moderated a bit more by using a cube for the wall rather than a plane, but the problem occurs at some point just the same and just as consistently.
The good news is that the problem only occurs at unrealistic velocity levels. I have found that you can stay well below this threshold and still have things look good. The thread where this was discussed was, if I recall, started by someone who was making a baseball game and was running into problems where home run balls hitting a collider were not having their collisions registered. You should take a look at that discussion.
My suspicion as to the cause is that there is a time based threshold in the physics engine for collisions and that if a collision is not registered for at least that much time, it is ignored. At high velocities, I suspect that the collisions are failing to meet that threshold requirement. Either that or it is just a bug 
Things are moving quite slowly actually. They “look” fine and are reacting to the collisions. I’m just not receiving an OnCollisionEvent() call.
Have you tried varying the size of the Box Collider?
According to FPS-tutorial 2 the Box Collider needs to be bigger than the actual object itself - otherwise this exact behaviour youre describing can emerge.
For instance, when I set the z-value to a too low number on a projectile used by a weapon, it will penetrate any object. Raise the value, and it will bounce.
…but as you say, stuff reacts the way they should, so this is probably not your issue.
I know this thread is SUPER old but I’m seeing this same behavior in Unity 5.4.1p1. My setup is complex but essentially I see the same issue. I see the bounce happen fine (physics works) but OnCollisionEnter is not called sometimes. This happens randomly like 1 in 50 times. @Lostlogic did you ever figure this out? I’ve been googling around have not seen any other helpful threads or blogs.
I believe I set the physics sample rate up to get it to work. That was a long time ago though and unfortunately I’m not exactly sure what ended up happening.
Cool. I ended up increasing “Default Contact Offset” by a factor of 10 (to 0.1), since my world is scaled up by 10 for other physics reasons. It “feels” like things are better now. I think I’ve still seen a missed collision but can’t be 100% sure since my game is pretty active. Thanks for the response!
I’ve been fighting with this same bug for awhile now, through 5.3 and now into the latest release of 5.5. It only happens with continuous dynamic collisions, never discrete ones (though unfortunately I can’t reliably use discrete collisions with high-velocity projectiles). Maybe once in every 20 or 30 collisions, a collision will happen without actually calling the OnCollisionEnter event. I’ve got a laundry list of potential fixes to try tomorrow, I’ll report back if I can get any of them to work.
I have exactly same issue with continuous dynamic collisions. I am truly looking forward your report!
Unfortunately I don’t have any good news to report. I fiddled with absolutely every collider, rigidbody, and physics setting I could think of, and the problem still persisted. I ended up rolling my own solution using raycasting to detect when a collision should have occurred but didn’t, and then handling it from there based on an approximation of what the collision data should have been.