Question Collision Detection without Physics Interaction

Hi. I've run into an issue with the Unity Colliders/Physic systems that I've been unable to find a clean solution to. The issue is this - there are 2 Game Objects; one player and one enemy. (The player is attacking the enemy).

There is code to select an enemy to attack (unimportant for this issue) and, upon pressing a key, the player flies towards the Enemy via the following function, where the delta is the new Vector3 from the player to the Enemy:

rb.addForce( delta, ForceMode.VelocityChange );

Once the Player and Enemy collide, we add another force ( via another rb.AddForce() function ) to propel the player forward and away from the enemy. However, with the way the Colliders interact, there are currently 2 scenarios that occur, instead of the desired behavior (show below with the green check):

- The first scenario (the issue displayed below, with the red X), where the player deflects off the enemy vertically.
- The second scenario ( which occurs far more frequently and isn't shown below) is the speed at which the player collides with the Enemy causes them to get stuck inside it, resulting in complete mobility loss and violent shaking of the Player.​

I'm trying to determine if a solution exists that does NOT use any of the following:

• Does not use an additional trigger collider on the Player or Enemy.
• Does not rely on an 'Enemy' layer in the built- in Unity Collision Matrix ( I don't want to deactivate collisions between all enemies and the player during the course of calculating the collisions with a singular one ).

The current implementation being used fixes the 'getting stuck inside the enemy' issue but requires a TriggerCapsuleCollider on the Player that is set to 'enabled = false' in the start method of the PlayerMovement MonoBehavior and then...

• The PhysicsCapsuleCollider is set to 'enabled = false' & the TriggerCapsuleCollider is set to 'enabled = true' when the attack is initiated.
• The first AddForce() is applied in the 'performAttack' function.
• Then, the 'exitAttack' function executes once we've either collided with or are projected to overshoot into the inside of the Enemy and both the PhysicsCapsuleCollider & TriggerCapsuleCollider's enabled state is reverted back to the initial values at the end of the call.

(**Note: Both the 'PhysicsCapsuleCollider' & TriggerCapsuleCollider are just regular CapsuleColliders and so I'm using the prefix of Physics/Trigger to denote them, as they are indistinguishable from each other in the editor, beyond having the 'Trigger' checkbox ticked.)

I've also tried a variation of doing the following, but it simply replicated the undesired functionality detailed above:

1. Tell the physics engine to ignore collisions between the player and the attackTarget, via

   Physics.IgnoreCollisions( PlayerCollider, AttackTargetCollider, true);

   
   
2. Apply Force to Player Rigidbody, in the direction of the enemy, via AddForce().
   
3. Check if the bounds of the Players Rigidbody intersect with the attackTarget, via

   rb.bounds.Intersects(AttackTargetCollider)

   .
4. Tell the Physics engine to un-ignore collisions between the Player and the Attack target, via

   Physics.IgnoreCollisions( PlayerCollider, AttackTargetCollider, true);

   .

This entire process just seems like it's overly involved and there should be a less intensive way to implement this functionality. If there doesn't seem to be any other solution, I suppose I'll just keep this implementation and make it work but any thoughts, suggestions, or solutions are appreciated. Thank you.

 

Just bounce...

 

Thank you for the input, Zulo3d. Sadly, unless I'm completely misunderstanding how the bounce material works, the implementation you suggested wouldn't work for the mechanics/functionality I'm attempting to implement. As an example, if the player attacks the enemy from below, they would bounce downward, instead of 'up and off of' the enemy, as shown below. I'm still searching for a viable solution that resolves the above issue, for anyone else that may have some constructive input. Thank you.
(Addendum: These are views from the side of a theoretical Unity3d scene.)