As I understand it (noob alert), collision events spam when an actor is at rest, whereas overlap events only fire once on begin_overlap and end_overlap.
So is it fair to say that in many cases overlap events can be used in place of collision events to improve efficiency?
At the cost of maybe some accuracy?
I really depends on what you are trying to do. If you are a little more specific about what you want to do I would be able to give you some advice as to which is better.
I would not go as far as to say that overlap is more efficient then collision or blocking as it is called. Blocking runs in O(1) time. this means that it runs in constant time which means it is virtually instant meaning it takes no time for the computer to complete that operation. Blocking will simply check did I hit something? Once it find something it will compute all the necessary things for blocking. Overlap does the same it will check did I hit something? And then it will compute all the necessary things for the overlap.
Thanks for a great reply. Knowing the growth rate for collisions is very useful. The specific example I was thinking of was say we have 2 objects both blocking, a cube at rest on a floor. With collision events on, I assumed the cube would be constantly spamming collision events. Assuming raising these events has computational overhead I thought maybe I would be better off just having overlap events, in which case the cube at rest on the floor wouldn’t be raising any events as long as it is at rest, thus less overhead. especially seen as in a real world example, collision events would usually be triggering some code checking what the collision is and in this case of 2 objects at rest, just ignoring it after a quick evaluation check.
I see where you are coming from now, but its nothing to worry about. When the cube initially comes into existence. It will register that it collided with the floor. So this cube would then say, “Okay, I hit the floor and I can’t fall through the floor, so I will come to rest”, The cube will then do nothing until a new collision happens, this is called an event driven architecture, which is how all game engines work.
It was this statement in unreal docs which lead me to this assumption:
“Further, an object that is reporting rigid collisions, will report them all and spam reports when it is just sitting on something, so it is best to be careful to filter what it is colliding within its blueprint or in code.”