Collision Responses and Trace Responses form the basis for how Unreal Engine 4 handles collision and ray casting during run time. Every object that can collide gets an Object Type and a series of responses that define how it interacts will all other object types. When a collision or overlap event occurs, both (or all) objects involved can be set to affect or be affected by blocking, overlapping, or ignoring each other.
Trace Responses work basically the same way, except the trace (ray cast) itself can be defined as one of the Trace Response types, thusly allowing Actors to either block it or ignore it based on their Trace Responses.
There are a few rules to keep in mind with how collisions are handled:
Blocking will naturally occur between two (or more) Actors set to Block. However, Simulation Generates Hit Events needs to be enabled to execute Event Hit, which is used in Blueprints, Destructible Actors, Triggers, etc...
Setting Actors to Overlap will often look like they Ignore each other, and without Generate Overlap Events, they are essentially the same.
For two or more simulating objects to block each other, they both need to be set to block their respective object types.
For two or more simulating objects: if one is set to overlap an object, and the second object is set to block the other, the overlap will occur but not the block.
Overlap events can be generated even if an object Blocks another, especially if traveling at high speeds.
It is not recommended for an object to have both collision and overlap events. Though possible, there is much that needs manual handling.
If one object is set to ignore and the other is set to overlap, no overlap events will be fired.
For purposes of testing levels and looking around your worlds:
The default Play In Editor camera is a pawn. Thusly can be blocked by anything set to block pawns.
The Simulate in Editor camera, before possessing anything, is not a pawn. It can freely clip through everything and will not create any collision or overlap events.
For the following section, this will be the setup used to explain what is happening:
The sphere is a PhysicsBody and the box is WorldDynamic, and by changing their collision settings we can get a number of behaviors.
By setting both of their collision settings to block each other, you get a collision, great for having objects interact with each other:
|Sphere Collision Setup||Wall Collision Setup|
|In this case, the sphere is a PhysicsBody and it is set to ||The wall is a WorldDynamic and is set to |
In this case, the sphere and the wall will simply collide; no further notifications of the collision will take place.
Just collision is useful and in general, the bare minimum for physics interactions, but if you want something to report it has collided so a Blueprint or section of code can be triggered:
With the sphere set to Simulation Generates Hit Events, the sphere will tell itself that it has had a collision. It will fire off events such asReceiveHit or OnComponentHit in the sphere's blueprint. Now if the box had an event for collision, it would not fire because it will never notify itself it has happened.
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.
For all intents and purposes, Overlap and Ignore work exactly the same assuming Generate Overlap Events is disabled. In this case, the sphere is set to overlap or ignore the box:
Unlike collisions that can fire every frame, the overlap events are ReceiveBeginOverlap and ReceiveEndOverlap, which only fire in those specific cases.